Cómo mejorar probando su propio código [cerrado]

12

Hoy verifiqué un cambio en un código que resultó no funcionar en absoluto debido a algo bastante estúpido pero muy crucial. Me siento muy mal por eso y espero finalmente aprender algo de ello. Lo estúpido es que he hecho estas cosas antes y siempre me digo a mí mismo que la próxima vez no seré tan estúpido ... Luego vuelve a pasar y me siento peor.

Sé que debes mantener el ritmo alto y aprender de tus errores, pero este es el problema: trato de mejorar, no veo cómo puedo evitar que sucedan estas cosas.

Entonces, ahora les pregunto: ¿tienen ciertas reglas básicas cuando prueban su código?

    
pregunta Peter 16.02.2011 - 12:49

6 respuestas

17

Escriba las pruebas antes de realizar cambios en el código.

Si su cambio propuesto es corregir un error, haga que la prueba falle al principio demostrando el error. Luego asegúrate de que pasa después de que hayas corregido el error. Si escribe la prueba después y solo la ha visto pasar, no puede estar seguro de que haya probado correctamente el error en primer lugar.

Si su cambio propuesto es cambiar la funcionalidad existente o agregar una característica, escriba algunas pruebas para asegurar una buena cobertura del área de código que cambiará. Asegúrate de que estas pruebas se aprueben antes de comenzar a cambiar el código, y de todas formas pasa cuando termines.

    
respondido por el Alb 16.02.2011 - 12:56
3

¡No te olvides de probar los casos de borde! Muchos de los errores se deben a que se probó la acción más común, pero no las menos comunes.

    
respondido por el HLGEM 16.02.2011 - 17:19
2

Siga los consejos técnicos en las respuestas de orientación técnica; son buenas cosas Mi respuesta es más sobre la actitud.

Sentirse mal por cometer el tipo de error que cada desarrollador hace ocasionalmente es simplemente absurdo, y no te ayuda a no cometer ese tipo de error en el futuro. Mientras te sientas allí sintiéndote mal, la estructura todavía está rota, ¿sabes? Y luego, su trabajo consiste en evitar errores, lo que sé hace que salir de la cama por la mañana sea una aventura emocionante todos los días, ¿no?

He oído hablar de compañías en las que la verificación de códigos dañados es motivo de vergüenza pública. Ni siquiera puedo entender el tipo de pensamiento retorcido, frat-boy, junior-level que llevaría a tal comportamiento. Difícilmente podría haber algo más contraproducente para que lo haga un jefe de equipo o gerente.

Así que no te castigues. Todos lo hemos hecho. Probablemente me costó medio día a la semana en errores tontos, y he estado haciendo esto por (tos) durante mucho tiempo. Eso es lo que parece escribir código: estás constantemente luchando contra lo que parecen ser tus propias deficiencias. Lo que convierte a un profesional en profesional no es la cualidad mítica de no cometer nunca errores (incluso los grandes a veces), sino cómo responden a los errores que cometen.

Si hay un mantra que podría inculcar en cada desarrollador con el que trabajo, es este: Tú no eres tu código . Usted escribe el código. Lo escribes tan bien y eficientemente como puedas. Entonces te vas a casa. Si iguala su valor o autoestima como persona con la calidad de su código, simplemente está perdiendo el bote de quién es usted realmente.

    
respondido por el Dan Ray 16.02.2011 - 15:43
2

Otra práctica de prueba importante es escribir la prueba y asegurarse de que falla al menos una vez ANTES de escribir el código. Es muy fácil arruinar y escribir una prueba de tautología que accidentalmente no prueba la condición que está verificando. Las falsas garantías son casi (y en ocasiones peores) que ninguna garantía.

    
respondido por el Uri 16.02.2011 - 16:49
0

Una idea que he usado de vez en cuando es esta,

cree una rama y rompa su código, ejecute la prueba y asegúrese de que la prueba detecte el error.

    
respondido por el Zachary K 16.02.2011 - 12:53
0
  

¿Tiene ciertas reglas básicas cuando prueba su código?

  • Siempre pruebe en unidad su código e intente alcanzar la mayor cobertura posible.

Algunos puntos generales adicionales:

  • invierta algo de tiempo en diseño y planificación antes de comenzar a codificar
  • ¡refactoriza tu código!
respondido por el BЈовић 23.03.2012 - 08:51

Lea otras preguntas en las etiquetas