Proceso para pasar del problema al código. ¿Como aprendiste?

Question

Estoy enseñando / ayudando a un estudiante a programar.

Recuerdo que el siguiente proceso siempre me ayudó cuando empecé; Parece bastante intuitivo y me pregunto si alguien más ha tenido un enfoque similar.

1. Lea el problema y entiéndalo (por supuesto).
2. Identificar posibles " funciones " y variables.
3. Escriba cómo lo haría paso a paso (algoritmo)
4. Conviértalo en código, si hay algo que no puede hacer, cree una función que lo haga por usted y siga moviéndose.

Parece que con el tiempo y la práctica me he olvidado de lo difícil que fue pasar de la descripción del problema a una solución de codificación, pero al aplicar este método, logré aprender cómo programar.

Entonces, para una descripción de proyecto como:

  

Un sistema debe calcular el precio de un Artículo según las siguientes reglas (una descripción de las reglas ... cliente, descuentos, disponibilidad, etc., etc.)

El primer paso es entender cuál es el problema.

Luego identifica el artículo, las reglas, las variables, etc.

pseudo código algo como:

function getPrice( itemPrice, quantity , clientAge, hourOfDay ) : int 
   if( hourOfDay > 18 ) then
      discount = 5%

   if( quantity > 10 ) then
      discount = 5%

   if( clientAge > 60 or < 18 ) then
      discount = 5%


        return item_price - discounts...
end

Y luego pásalo al lenguaje de programación ...

public class Problem1{
    public int getPrice( int itemPrice, int quantity,hourOdDay ) {
        int discount = 0;
        if( hourOfDay > 10 ) {
             // uh uh.. U don't know how to calculate percentage... 
             // create a function and move on.
            discount += percentOf( 5, itemPriece );
            .
            .
            .
            you get the idea..

        }
     }
    public int percentOf( int percent, int i ) {
             // .... 
    }


}

¿Tuviste un enfoque similar? ... ¿Alguien te enseñó un enfoque similar o descubriste a ti mismo (como lo hice :()

Answer 1

Hice algo similar.

• Averiguar las reglas / lógica.
• Averiguar las matemáticas.
• Luego intenta codificarlo.

Después de hacer eso por un par de meses, simplemente se internaliza. No te das cuenta de que lo estás haciendo hasta que te encuentras con un problema complejo que requiere que lo descompongas.

Answer 2

Voy a través del enfoque basado en pruebas.

1. Escribo (en papel o editor de texto plano) una lista de pruebas o especificaciones que satisfagan las necesidades del problema.

- simple calculations (no discounts and concessions) with:
    - single item
    - two items
    - maximum number of items that doesn't have a discount
- calculate for discounts based on number of items
    - buying 10 items gives you a 5% discount
    - buying 15 items gives you a 7% discount
    - etc.
- calculate based on hourly rates
    - calculate morning rates
    - calculate afternoon rates
    - calculate evening rates
    - calculate midnight rates
- calculate based on buyer's age
    - children
    - adults
    - seniors
- calculate based on combinations
    - buying 10 items in the afternoon

2. Busque los elementos que creo que serían los más fáciles de implementar y escriba una prueba para ello. Por ejemplo, los artículos individuales parecen fáciles

La muestra usando Nunit y C #.

[Test] public void SingleItems()
{
    Assert.AreEqual(5, GetPrice(5, 1));
}

Implemente eso usando:

public decimal GetPrice(decimal amount, int quantity)
{
    return amount * quantity; // easy!
}

Luego continúe con los dos elementos.

[Test]
public void TwoItemsItems()
{
    Assert.AreEqual(10, GetPrice(5, 2));
}

La implementación aún pasa la prueba, así que pase a la siguiente prueba.

3. Esté siempre atento a la duplicación y elimínelo. Ha terminado cuando todas las pruebas pasan y ya no puede pensar en ninguna prueba.

Esto no garantiza que creará el algoritmo más eficiente, pero siempre que sepa para qué probar y todo pasa, garantizará que obtenga las respuestas correctas.

Answer 3

el modo OO de la vieja escuela:

• escriba una descripción del problema y su solución
• circunde los nombres, estos son objetos candidatos
• dibuja cajas alrededor de los verbos, estos son mensajes candidatos
• agrupa los verbos con los sustantivos que 'harían' la acción; enumere cualquier otro nombre que se requiera para ayudar
• vea si puede reformular la solución utilizando la forma noun.verb (otros sustantivos)
• codifícalo

[este método precede a las tarjetas CRC, pero ha pasado tanto tiempo (más de 20 años) que no recuerdo dónde lo aprendí]

Answer 4

al aprender programación no creo que TDD sea útil. TDD es bueno más adelante cuando tienes algún concepto de lo que es la programación, pero para empezar, lo más importante es tener un entorno donde escribir código y ver los resultados en el tiempo de respuesta más rápido posible.

Pasaría de la declaración del problema al código al instante. Hackearlo alrededor. Ayude al estudiante a ver diferentes formas de componer software / estructurar algoritmos. Enseñar al alumno a cambiar de opinión y volver a trabajar el código. Intenta enseñar un poco sobre la estética del código.

Una vez que puedan piratear el código ... luego presenten la idea de una reestructuración formal en términos de refactorización. Luego, presente la idea de TDD como una manera de hacer que el proceso sea un poco más sólido. Pero solo una vez se sienten cómodos manipulando el código para hacer lo que quieren. Ser capaz de especificar pruebas es algo más fácil en esa etapa. La razón es que TDD es sobre diseño. Cuando aprendes, realmente no te importa tanto el diseño como lo que puedes hacer, con qué juguetes tienes que jugar, cómo funcionan, cómo combinarlos. Una vez que tenga una idea de eso, entonces querrá pensar en el diseño y eso es cuando TDD realmente se activa.

A partir de ahí empezaría a introducir micro patrones que conducen a patrones de diseño

Answer 5

Empiezo por la parte superior y camino hacia abajo. Básicamente, comenzaré por escribir un procedimiento de alto nivel, esbozar los detalles dentro de él y luego comenzar a completar los detalles.

Supongamos que tuve este problema (se vinculó a euler del proyecto)

  

La suma de los cuadrados de la primera   diez números naturales es, 1 ^ 2 + 2 ^ 2 +   ... + 10 ^ 2 = 385

     

El cuadrado de la suma de los diez primeros.   Los números naturales son, (1 + 2 + ... +   10) ^ 2 = 55 ^ 2 = 3025

     

De ahí la diferencia entre la suma   De los cuadrados de los diez primeros.   Los números naturales y la plaza de la   la suma es 3025 385 = 2640.

     

Encuentra la diferencia entre la suma de   los cuadrados de los primeros cien   Los números naturales y la plaza de la   suma.

Así que empiezo así:

(display (- (sum-of-squares (list-to 10))
            (square-of-sums (list-to 10))))

Ahora, en Esquema, no hay suma de cuadrados, cuadrado de sumas o funciones de lista a. Entonces el siguiente paso sería construir cada uno de esos. Al desarrollar cada una de esas funciones, puedo encontrar que necesito abstraerme más. Intento mantener las cosas simples para que cada función solo haga una cosa. Cuando construyo una pieza de funcionalidad que se puede probar, escribo una prueba de unidad para ello. Cuando empiezo a notar una agrupación lógica para algunos datos y las funciones que actúan sobre ellos, puedo insertarlos en un objeto.

Answer 6

He disfrutado de TDD desde que me lo presentaron. Me ayuda a planificar mi código, y me tranquiliza tener que todas mis pruebas vuelvan con " éxito " ¡Cada vez que modifico mi código, hágame saber que me voy a casa a tiempo hoy!

Answer 7

La ilusión es probablemente la herramienta más importante para resolver problemas complejos. En caso de duda, suponga que existe una función para resolver su problema (al principio, cree un código auxiliar). Volverás más adelante para expandirlo.

Answer 8

Un buen libro para principiantes que buscan un proceso: Desarrollo guiado por pruebas: por ejemplo

Answer 9

Mi papá tenía un montón de plantillas de diagrama de flujo que usaba para hacerme usar cuando me enseñó por primera vez acerca de la programación. hasta el día de hoy dibujé cuadrados y diamantes para construir un proceso lógico de cómo analizar un problema.

Answer 10

Creo que hay alrededor de una docena de heurísticas diferentes que conozco en lo que respecta a la programación, por lo que tiendo a revisar la lista a veces con lo que estoy tratando de hacer. Al comienzo, es importante saber cuál es el resultado final deseado y luego tratar de trabajar hacia atrás para encontrarlo.

Recuerdo una clase de Algoritmos que cubría algunas de estas formas como:

• Reducirlo a un problema conocido o problema trivial
• Divide y conquista (MergeSort es un ejemplo clásico aquí)
• Use estructuras de datos que tengan las funciones correctas (HeapSort es un ejemplo aquí)
• Recursión (Conocer soluciones triviales y poder reducirlas)
• Programación dinámica

Organizar una solución y probarla en situaciones extrañas, p. ej. Si alguien piensa que L debería ser un número, es lo que usualmente usaría para probar la idea en un pseudo código antes de escribirla.

Los patrones de diseño pueden ser un conjunto útil de herramientas para usar en casos específicos, como cuando se necesita un adaptador u organizar las cosas en una solución de estado o estrategia.

Answer 11

Sí ... bueno, TDD no existía (o no era tan popular) cuando comencé. ¿Sería TDD el camino a seguir para pasar de la descripción del problema al código? ... ¿No es eso un poco avanzado? Quiero decir, cuando un " futuro " El desarrollador apenas entiende qué es un lenguaje de programación, ¿no sería contraproducente?

¿Qué pasa con Hamcrest? Haz la transición del algoritmo al código.

Answer 12

Creo que hay una mejor manera de exponer tu problema.

En lugar de definirlo como 'un sistema', define lo que se espera en términos de entradas y salidas del usuario.

" En una ventana, un usuario debe seleccionar un elemento de una lista, y un cuadro debe mostrarle cuánto cuesta. "

Luego, puede darle algunos de los factores que determinan los costos, incluidos los elementos de muestra y cuáles deberían ser sus costos.

(esto también es una idea parecida a TDD)

Answer 13

Tenga en cuenta que si obtiene un 5% de descuento y otro 5% de descuento, no obtendrá un 10% de descuento. Más bien, usted paga el 95% del 95%, que es el 90.25%, o el 9.75% de descuento. Por lo tanto, no debes agregar el porcentaje.