miércoles, 12 de enero de 2011

Cuando nos olvidamos del “Test vacío”

El nivel de trabajo ha vuelto a la normalidad después de una entrega en producción bastante menos limpia de lo que hubiera querido o, aún peor, esperado. Se ha cumplido a rajatabla el lema de que el código tiene la calidad de los miembros del equipo. Con tres noveles, aunque uno de ellos tenga bastante talento, la cosa ha salido como ha salido y aún así ha salido bastante bien.

Por lo cual he tenido tiempo de ver mil blogs que no había tenido tiempo para leer, y acceder al código de dos pseudogurus y un compañero de alt.net que, puedo estar seguro,  tienen un nivel como desarrolladores mucho mayor que el mío. Al menos en la teoría.

Dicho código es la nueva moda en el mundo del desarrollo “güay” que son la Katas, abanderadas por Uncle Bob (creo), y que a mi no me termina de dar confianza la llamada conexión entre ellas y la mejora en la calidad del código que hacemos. ¿Practicando muchísimos saques terminamos jugando mejor al tenis?¿Haciendo muchas veces escalas cromáticas podemos componer mejor?

Y en los tres casos me encuentro que tres profesionales (más bien cuatro ya que uno es un equipo de dos) con mucha experiencia han caído en el error de novato de no hacer el “test de vacío”. Es decir, hago una clase sencillita, me centro en TDD, me centro en un código fluido, autoexplicativo, en una refactorización super chula, ajustado a SOLID y DRY… y se me olvida gestionar si el parámetro de entrada llega nulo. Y todo el trabajo realizado se queda en un bonita rotura de la aplicación con una excepción de objeto nulo.

Vamos, me digo, pero si es un error de novato. Es lo primero que aprendí, justo después de apretar el botón de enviar de un formulario con todos los campos vacíos. Y la siguiente pregunta es más preocupante, ¿estamos perdiendo en la comunidad de desarrollo el foco? ¿Nos centramos en las cosas de “alto nivel” y olvidamos lo realmente importante, “hacer software que funciona”. ?

Moraleja, trabajar con novatos te hace volver la mirada a las cosas que los clientes quieren, que es que las cosas funcionen.

3 comentarios:

Julio dijo...

De acuerdo en casi todo, pero no en que los errores sean de novato (que muchos lo son). La mayoría de errores son por pereza mental, incluso física, por no pararse a pensar (10 segundos un no novato, igual dos minutos un novato) o por no querer hacer copiar-(pararme a pensar)cambiar-pegar. La de veces que le tengo que decir a la gente... ¿y si este es objeto es Nothing, qué? Lo corrigen y al día siguiente, de nuevo el mismo error.

En todo caso, el problema no es el error, del que no estamos a savlo nadie, sino la economía de pensamiento (más grave aún en gente). Un desarrollador no es un tipo que (sólo) tira líneas, sino que alguien que tiene un objetivo, unas herramientas para conseguirlo y una guerra que ganar. En las guerras, en 9 de cada 10 batallas se usan las mismas armas, estrategias y tácticas. Y por desgracia, en muchos desarrolladores una guerra de 10 batallas se convierte en 10 guerras disitintas.

Julio dijo...

Quería decir "más grave aún en gente inteligente". De un cazurro poco puedes esperar y exigir.

Juan Quijano dijo...

Indudablemente y totalmente de acuerdo contigo.