process - traduccion - Proceso para pasar de problema a código. ¿Como aprendiste?
process translate (13)
Comienzo en la parte superior y sigo hacia abajo. Básicamente, comenzaré escribiendo un procedimiento de alto nivel, bosquejaré los detalles dentro de él y luego comenzaré a completar los detalles.
Digamos que tuve este problema (del proyecto euler)
La suma de los cuadrados de los primeros diez números naturales es, 1 ^ 2 + 2 ^ 2 + ... + 10 ^ 2 = 385
El cuadrado de la suma de los primeros diez números naturales es, (1 + 2 + ... + 10) ^ 2 = 55 ^ 2 = 3025
Por lo tanto, la diferencia entre la suma de los cuadrados de los primeros diez números naturales y el cuadrado de la suma es 3025 385 = 2640.
Encuentra la diferencia entre la suma de los cuadrados de los primeros cien números naturales y el cuadrado de la suma.
Entonces empiezo así:
(display (- (sum-of-squares (list-to 10))
(square-of-sums (list-to 10))))
Ahora, en Scheme, no hay suma de cuadrados, cuadrados de sumas o funciones list-to. Entonces, el próximo paso sería construir cada uno de ellos. Al construir cada una de esas funciones, puedo encontrar que necesito abstraer más. Intento mantener las cosas simples para que cada función realmente solo haga una cosa. Cuando construyo una pieza de funcionalidad comprobable, escribo una prueba de unidad para ella. 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.
Enseño / ayudo a un alumno a programar.
Recuerdo que el siguiente proceso siempre me ayudó cuando comencé; Parece bastante intuitivo y me pregunto si alguien más ha tenido un enfoque similar.
- Lee el problema y entiéndelo (por supuesto).
- Identificar posibles "funciones" y variables.
- Escribir cómo lo haría paso a paso (algoritmo)
- Traduzca el código, si hay algo que no puede hacer, cree una función que lo haga por usted y siga moviéndose.
Con el tiempo y la práctica, parece que olvidé lo difícil que era pasar de la descripción del problema a una solución de codificación, pero al aplicar este método logré aprender a programar.
Entonces para una descripción del proyecto como:
Un sistema tiene que calcular el precio de un artículo basándose en las siguientes reglas (una descripción de las reglas ... cliente, descuentos, disponibilidad, etc., 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 así 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 pasarlo 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 ) {
// ....
}
}
¿Fuiste en un enfoque similar? ¿Alguien te enseñó un enfoque similar o descubriste tu ser (como yo lo hice :()
Hice algo similar.
- Descubre las reglas / lógica.
- Calcula las matemáticas.
- Luego intenta codificarlo.
Después de hacer eso por un par de meses, se internaliza. No te das cuenta de que lo estás haciendo hasta que te encuentres con un problema complejo que requiere que lo desgloses.
Las ilusiones son probablemente la herramienta más importante para resolver problemas complejos. En caso de duda, suponga que existe una función para resolver su problema (cree un stub, al principio). Volverás más tarde para expandirlo.
Mi padre tenía un montón de patrones de diagrama de flujo que solía usar cuando me enseñaba sobre programación. hasta el día de hoy dibujo cuadros y diamantes para construir un proceso lógico de cómo analizar un problema.
Sí ... bueno, TDD no existía (o no era tan popular) cuando comencé. ¿Sería TDD la forma de pasar de la descripción del problema al código? ... ¿No es un poco avanzado? Quiero decir, cuando un desarrollador "futuro" apenas entiende lo que es un lenguaje de programación, ¿no sería contraproducente?
¿Qué pasa con Hamcrest hacer la transición de algoritmo a código.
Tenga en cuenta que si obtiene un 5% de descuento y otro 5% de descuento, no obtiene un 10% de descuento. En cambio, paga el 95% del 95%, que es el 90.25% o el 9.75% de descuento. Entonces, no deberías agregar el porcentaje.
Un buen libro para principiantes que buscan un proceso: Desarrollo impulsado por prueba: por ejemplo
Voy a través del enfoque impulsado por la prueba.
1. Escribo (en papel o editor de texto sin formato) una lista de pruebas o especificaciones que satisfarían 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 artículos 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));
}
Implementar eso usando:
public decimal GetPrice(decimal amount, int quantity)
{
return amount * quantity; // easy!
}
Luego pasa a 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ínela. Ya terminaste cuando pasaron todas las pruebas y ya no puedes pensar en ninguna prueba.
Esto no garantiza que creará el algoritmo más eficiente, pero siempre que sepa qué probar y todo pasa, le garantizará que está obteniendo las respuestas correctas.
al aprender a programar, no creo que TDD sea útil. El TDD es bueno más adelante cuando tienes algún concepto sobre de qué se trata la programación, pero para empezar, tener un entorno donde escribir código y ver los resultados en el menor tiempo posible es lo más importante.
Pasaría del enunciado del problema al código instantáneamente. Hack alrededor. Ayude al alumno a ver diferentes formas de componer software / algoritmos de estructuración. Enseñe al alumno a cambiar de opinión y a modificar el código. Intenta enseñar un poco acerca de la estética del código.
Una vez que puedan hackear el código ... entonces introduzca la idea de la reestructuración formal en términos de refactorización. Luego, introduce la idea de TDD como una forma de hacer que el proceso sea un poco más robusto. Pero solo una vez que se sientan cómodos manipulando el código para hacer lo que quieran. Ser capaz de especificar pruebas es más fácil en esa etapa. La razón es que TDD se trata de diseño. Cuando aprendes, realmente no te importa tanto el diseño, sino lo que puedes hacer, con qué juguetes tienes que jugar, cómo funcionan, cómo los combinas. Una vez que tienes una idea de eso, entonces quieres pensar en el diseño y eso es cuando TDD realmente entra en acción.
A partir de ahí comenzaría a introducir micro patrones que conducen a patrones de diseño
la vieja manera OO de la escuela:
- escriba una descripción del problema y su solución
- encierra en un círculo los sustantivos, estos son objetos candidatos
- dibujar cuadros alrededor de los verbos, estos son mensajes candidatos
- agrupe los verbos con los sustantivos que ''harían'' la acción; enumere otros nombres que se requerirían para ayudar
- ver si puede replantear la solución usando la forma nombre.verbio (otros sustantivos)
- codificarlo
[este método precede a las tarjetas CRC, pero ha sido tan largo (más de 20 años) que no recuerdo dónde lo aprendí]
Creo que hay alrededor de una docena de heurísticas diferentes que conozco cuando se trata de programación, por lo que tiendo a revisar la lista a veces con lo que estoy tratando de hacer. Al principio, 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 abarca algunas de estas formas, como:
- Reducirlo a un problema conocido o problema trivial
- Divide y conquista (MergeSort es un ejemplo clásico aquí)
- Utilice estructuras de datos que tengan las funciones correctas (HeapSort es un ejemplo aquí)
- Recursividad (Conocer soluciones triviales y poder reducirlas)
- Programación dinámica
Organizar una solución y probarla para situaciones extrañas, por ejemplo, si alguien cree que L debería ser un número, es lo que generalmente usaría para probar la idea en un pseudo código antes de escribirlo.
Los patrones de diseño pueden ser un útil conjunto de herramientas para usar en casos específicos, como dónde se necesita un Adaptador u organizar cosas en una solución de estado o estrategia.
He disfrutado de TDD desde que me lo presentaron. Me ayuda a planificar mi código, y me tranquiliza que todas mis pruebas regresen con "éxito" cada vez que modifico mi código, ¡haciéndome saber que me voy a casa a tiempo hoy!
Creo que hay una mejor manera de expresar tu problema.
En lugar de definirlo como "un sistema", defina lo que se espera en términos de entradas y salidas de los usuarios.
"En una ventana, un usuario debe seleccionar un elemento de una lista, y un cuadro debe mostrar cuánto cuesta".
Luego, puede darle algunos de los factores que determinan los costos, incluidos los elementos de muestra y cuáles serán sus costos.
(Esta también es una idea parecida a TDD)