RE: Writing good code requires you to perform experiments
Ago 17, 2009 Articulos, Respuestas
Acabo de leer el articulo Writing good code requires you to perform experiments. El titulo me llamo bastante la atencion, siempre “experimento” con pequeños snippets de código cuando estoy programando, de hecho tengo un shortcut (”Control Mod1 P :ExecCommand aterm -tint green -e python” en el .fluxbox/keys) para iniciar una terminal de Python ni bien tengo una pequeña duda o quiero “experimentar”. Pero para mi asombro, detrás de un titulo prometedor encontré un par de malos consejos.
Primero los dos puntos que rescato del articulo como ciertos (al menos en mi experiencia):
Es poco probable, casi imposible, que un poco de código recién escrito funcione como esperamos: Esto es especialmente cierto con los ejemplos que da de consultas a la base de datos y expresiones regulares. Siempre una tarea, por mas insignificante o banal que parezca puede contener errores.
Probar una funcionalidad o un poco de código dentro de una aplicación es ineficiente: Existen tiempos muertos entre que arranca el programa y el flujo del mismo llega hasta donde esta nuestro nuevo segmento de código. Hay que agregar que esta tarea es iterativa: tenemos que repetir el proceso hasta tener el resultado que queremos (o todos los resultados que queramos si son varias opciones). Y a esto tenemos que sumarle el tiempo de compilación (Si el lenguaje que utilizamos lo requiere).
Habiendo leído esto mi conclusión es ese código debe estar en un test case del proyecto. Pero esta es la respuesta del autor a esta idea:
Some of you may now be thinking that the obvious solution is to write a proper unit test and run that unit test after every modification, until the code passes the test. I agree that goes a long way, but usually the test is part of a larger number of classes and running all those tests takes times, especially if it bootstraps an entire Spring-Hibernate application or something of the like.
Y ahí mi horror, respondo por partes:
but usually the test is part of a larger number of classes
Una funcionalidad básica de la mayoría de las librerías para correr test cases es elegir correr un solo test de la test suite. Para mi eso es muy importante justamente por este caso que esta nombrando, y siempre me fijo (cuando elijo una librería al menos) que cuenta con esta funcionalidad, se me vienen a la mente la librería de unittest de Python y CppUnit.
especially if it bootstraps an entire Spring-Hibernate application or something of the like
Voy a evitar el chiste fácil de decir que mi segundo horror es que usan Java y referirme a lo que importa: ¿Por que debería hacer falta iniciar toda una aplicación para probar un pequeño pedazo de esta? Eso me suena a mucho coupling:
Si tenes un código lo suficientemente no trivial como para que lo hallas tenido que probar antes, merece al menos su propia función con su propio test case. Es una simple premisa de manejar la complejidad del código que estas desarrollando. Un nombre de la función va a describir mejor lo que pretendes hacer que tener que parsear con la mente la expresión regular que estas escribiendo. Y si tiene su propia función: ¿Para que vas a levantar todo el programa para probar solamente esa función? El test case debería limitarse a probar esa, y solamente esa, función, a lo sumo mockear (del ingles mock, “imitar”) sus dependencias.
En conclusión: Experimentar es bueno, sirve para sacarse dudas de como funciona una librería, que hace con cada parámetro, etc. Pero una ves que empezamos a escribir un código que es probable que llegue a producción, tiene que ser probado por su correspondiente test case y ser versionado en el SCM que utilicemos.