Supere la torpeza al escribir el código

7

Creo que esto está un poco relacionado con esta pregunta: Cómo ser un programador de cero errores? . Pero creo que esto tiene más que ver con la torpeza en la programación porque sé que es imposible convertirse en un programador de cero errores.

A menudo, escribo un código muy defectuoso causado por mi propia torpeza. Por ejemplo, al escribir una función de conversión de tasa de cambio, una función trivial. Puedo codificar la función que funciona bien dado el valor correcto. Pero en algún momento me olvidé de validar algunos valores inesperados pero razonables.

Entonces, ¿hay alguna manera para que un programador torpe como yo escriba y pruebe el código más a fondo?

Adicional Veo a mucha gente que sugiere escribir una prueba unitaria o usar el método TDD. Pero escribir la prueba de unidad no siempre va bien debido a la torpeza, ¿no es así? No lo hago porque una vez intenté escribir una prueba de unidad, pero aún así a menudo me topé con errores.

    
pregunta junxiong 03.01.2012 - 15:48

10 respuestas

18

Pruebe un enfoque de desarrollo diferente: Desarrollo guiado por pruebas (TDD).

  

un proceso de desarrollo de software que se basa en la repetición de un ciclo de desarrollo muy corto: primero el desarrollador escribe un (inicialmente Fallo) automatizado caso de prueba que define una mejora deseada o una nueva función, luego produce la cantidad mínima de código para pasar esa prueba, y finalmente refactors el nuevo código para estándares aceptables ...

     

El desarrollo basado en pruebas se relaciona con los conceptos de programación de primera prueba de programación extrema , que comenzó en 1999, pero más Recientemente ha creado un interés más general por derecho propio.

     

Los programadores también aplican el concepto para mejorar y depuración código heredado desarrollado con técnicas más antiguas ...

Escriba casos de prueba y use pruebas unitarias para evitar que los errores se materialicen.

    
respondido por el Bernard 03.01.2012 - 15:54
7

Pase un poco de tiempo como evaluador: le enseñará a entrar en la mentalidad de "caso extremo"

Luego ponga todos sus casos de borde en pruebas unitarias para un enfoque TDD ..

Además de TDD, creo que leer sobre Programación Defensiva también sería útil. Aprendiendo a hacer valer sus condiciones previas y Las condiciones posteriores en todos los métodos son una buena práctica, ¡y sea estricto! :)

    
respondido por el MattDavey 03.01.2012 - 15:57
5

Piensa más sobre los requisitos. Pocas personas son realmente torpes o incapaces de pensar en errores; la mayoría simplemente no se toma el tiempo para pensar en los aspectos apropiados. Si se toma un poco de tiempo y solo piensa en los requisitos de una función, descubrirá la mayoría de los aspectos necesarios.

El desarrollo guiado por pruebas es un enfoque moderno y bien documentado para enfocarte primero en pensar en los requisitos de bajo nivel.

    
respondido por el thiton 03.01.2012 - 15:52
5

Además de TDD, le recomiendo que regrese al código uno o dos días después de haberlo escrito, y mire lo que verifican sus pruebas y lo que la función verifica. Al codificar, puede tener una idea muy específica de cómo se llamará la función, que puede volverse más vaga si se toma algún tiempo. Además de esto, esta es una gran oportunidad para ver cuán bien documentada está la función y agregar comentarios si no entiende por qué funciona.

También puede intentar codificar con un marco Design by Contract , que puede ayudar a detectar algunos errores, en su ejemplo , tal vez verificando que el signo del resultado sea igual al signo de la entrada, y que el resultado (si es un flotador) no sea NaN o infinito.

    
respondido por el Anton Golov 03.01.2012 - 17:01
4

Aprenda otros idiomas, preferiblemente de diferentes paradigmas.

Por ejemplo, si ha estado usando un lenguaje imperativo / OOP como Java / C # / C ++, pruebe un lenguaje funcional como Scala / Haskell / F # . (Sugiero a Haskell para tu propósito, ya que es el más fiel al paradigma.)

La ventaja de aprender un nuevo idioma o un nuevo paradigma es que comenzará a ver patrones conceptuales que estos otros idiomas habrían definido de manera rigurosa, y luego, cuando vuelva a trabajar en el idioma de su elección, puede aplicar estos patrones a su código y, por lo tanto, evite errores que solían ser comunes de otra manera.

TDD no es lo mismo que las pruebas unitarias. De hecho, muchos profesionales de TDD insistirán en que TDD debería no debe usarse para detectar errores o regresiones , y si está escribiendo pruebas TDD para detectar errores, está perdiendo los beneficios de diseño de TDD.

Si desea realizar pruebas para mejorar la calidad del código, realice pruebas unitarias y pruebas de integración, no TDD. Seguro que con TDD desarrollarás el hábito de detectar errores por adelantado, pero ese aspecto de TDD realmente no es muy diferente de las pruebas unitarias normales.

    
respondido por el Rei Miyasaka 04.01.2012 - 02:25
3

Las pruebas son importantes, pero las pruebas en sí requerirán paciencia y atención a los detalles, por lo que, para empezar, no van bien con la torpeza. Prefiero sugerir el uso de idiomas con sistemas de tipo más estricto (además de las pruebas, no en lugar de hacerlo).

Los errores de codificación estúpidos son muy raros incluso en lenguajes como Haskell. Si se compila, es probable que se ejecute como se espera. Y tales errores son casi imposibles para los idiomas con sistemas de tipo más estricto, como Agda o Coq.

    
respondido por el SK-logic 03.01.2012 - 16:09
3

Deténgase y lea su código con mucho cuidado incluso antes de compilarlo. Piense como el compilador: encuentre cualquier error de sintaxis (una vez que se haya recuperado, el compilador nunca debería encontrar un error de sintaxis). También trabaja a través del código en tu cabeza muy a fondo, juega la computadora. Míralo como si solo tuvieras una oportunidad de compilar, y todo funcionará mejor (en otras palabras, ten mucho cuidado con lo que haces, no trates el comando de compilación y luego corriges lo que salga). Esta es una técnica simple que es sorprendentemente efectiva.

    
respondido por el anon 04.01.2012 - 01:26
1

Muy pocas personas pueden escribir el código libre de errores desde cero. Personalmente, siempre me siento incómodo si una parte bastante larga de mi código se compila y ejecuta inmediatamente y mi intuición falla rara vez.

Siempre que acepte estos, no puede escribir el código libre de errores directamente, es más fácil encontrar un compromiso entre los esfuerzos que invierte en su código y la frecuencia (potencial) de errores en él.

Un muy buen enfoque para minimizar los errores en su código es el ya mencionado Desarrollo dirigido por pruebas . Lo uso a menudo cuando hablo en público adaptándolo de la siguiente manera.

Cada pieza de código independiente se escribe y se vuelve a escribir en varias iteraciones que consisten en lo siguiente:

  1. Diseñe la idea principal de lo que debe hacer el código.
  2. Escriba la representación esquemática de su algoritmo.
  3. Vuelva a escribir la representación esquemática para que sea sintácticamente correcta.
  4. Escriba algunas de las pruebas unitarias más importantes para su código ( prueba de humo , por ejemplo).
  5. Implemente el algoritmo para satisfacer sus pruebas existentes.
  6. Refactoriza tu código para mejorarlo.
  7. Repita desde 1-4 (dependiendo de la madurez del código) para cada iteración y cada nueva función.

Aquí hay algunos ejemplos.

(1) Comienzo con algo como

  

Quiero calcular pi, así que simularé que un objetivo es un círculo   con diámetro d y usa números aleatorios para lanzarle flechas. voy a   luego use la proporción del área del círculo al tamaño total del objetivo para   calcular pi.

(2) Luego me muevo a

  

Tamaño de solicitud del objetivo.
  Solicitar número de flechas.   Lanza flechas al azar al objetivo.
  Calcula las flechas que alcanzaron el objetivo.
  Calcula el valor pi.

(3) Lo reescribo en C # (solo un ejemplo):

var Radius = RequestFromUser<double>("Radius of Target");
var NumberOfShots = RequestFromUser<long>("Number of shots");
long GoodShots = 0; long TotalShots = NumberOfShots;
while (--NumberofShots > 0)
{
  if (ShootTarget(Radius)) GoodShots++;
}
Output(CalculatePi(GoodShots, TotalShots));

(4) Creo todos los apéndices de métodos en IDE (automáticamente). Esto me permite escribir mis pruebas unitarias de forma semiautomática (obtener algunas plantillas creadas automáticamente para ellas)
(5) Diseño la prueba de humo:

var computed = ComputerPi(Radius: 10.0, NumberOfShots: 10000);
Assert.IsTrue(computed > 3.0 && computed < 3.5);

(6) Rápidamente (es decir, sin pulir el código) implemento todos los apéndices para comenzar las pruebas.
(7) Mientras mis pruebas muestren verde, reformulo mi implementación intentando hacerla "más agradable".
(8) Repito desde (5) si mi implementación no está completa, o desde un paso anterior si quiero extenderla.

Esto me ayuda a mantener mi código bastante limpio, y las pruebas unitarias que surgen lentamente sirven como pruebas de regresión si lo hago cambios demasiado dramáticos en mi código.

    
respondido por el Alexander Galkin 04.01.2012 - 01:20
0

Aquí hay algunas buenas prácticas:

  1. Salir del sistema
  2. Enumerar todas las alternativas
  3. Encuentra el borde del sistema
  4. Considera todo el espacio estatal
  5. Precisión en los tipos de decisión: solo permite exactamente lo que se requería
  6. Considere la ruta desde la entrada hasta la salida, no rompa la ruta.
respondido por el tp1 03.01.2012 - 16:51
0

La respuesta real es muy simple y aburrida y no implica toneladas de listas e instrucciones.

Codifique todos los días durante 10 años y lo hará muy bien. Eso es. Terminarás resolviendo todo a lo largo del camino y refactorizarte y refinarte. Es la naturaleza del cerebro humano.

Bruce Lee terminó por darse cuenta de que no hay un solo estilo de lucha, tienes que adaptarte a tu oponente.

En la programación, no hay un estilo único, te adaptas a tu problema. Pero tienes que haberlo hecho durante mucho tiempo para ser un maestro en ello.

Eso es todo.

    
respondido por el Jason Sebring 04.01.2012 - 09:10

Lea otras preguntas en las etiquetas