Hay muchísimas prácticas que podemos adoptar para mejorar la calidad de nuestro código. ¿Por dónde empezar? ¿Existe una lista única y completa? En este artículo veremos un pequeño listado de buenas prácticas, que nos pueden ayudar a comenzar ese largo camino que implica trabajar con más profesionalismo, mejorando los productos que desarrollamos.
Desarrollo Guiado por Pruebas (TDD)
TDD debe ser la práctica que más contribuye a mejorar la calidad de código y a generar menos bugs. Y además puede usarse en cualquier tipo de proyecto: Ágil, Cascada, u otros. Tiene su origen hace ya muchos años, pero recién Extreme Programming la trajo a escena. Alcanza su máximo potencial cuando se utiliza en conjunto con ciclos de Integración Continua y construcciones automátizadas.
Sin embargo, TDD no es algo que ocurre por desearlo. La mayoría de los desarrolladores no saben cómo implementarla, necesitan capacitación y ayuda (coaching) para practicarla. E incluso entonces será una experiencia de aprendizaje continuo, no esperen ser expertos en TDD en 15 días.
Desarrollo Guiado por Pruebas de Aceptación (ATDD)
ATDD es el siguiente nivel a TDD. Quienes realizan los requerimientos de desarrollo no sólo especifican su criterio de aceptación, sino que lo hacen antes de que ocurra el desarrollo, y lo hacen de manera que pueda ejecutarse automáticamente. En muchos casos se necesita a testers profesionales que trabajen junto al Cliente para crear estos casos.
Integración Continua
Esta es una práctica valiosa por si misma: asegurarnos que el código nuevo no rompa al código existente. Cuando se junta con TDD y ATDD para crear suites de pruebas automatizadas y repetibles, aumenta exponencialmente su valor.
Programación de a pares
La programación de a pares es una revisión instantánea de código, con dos cabezas pensando en el problema (¡dos es mejor que uno! Piensen en los pilotos de aviones comerciales, o los equipos quirúrgicos). También le permite a los desarrolladores enfocarse intensivamente en el trabajo - menos distracciones del teléfono, emails, SMS y otros medios que nos distraen.
Además, la programación de a pares ayuda a formar una cultura colaborativa en el equipo, lo cual genera un impacto positivo invaluable.
Revisiones de código
Es la siguiente alternativa a la programación de a pares: si no trabajan de a pares, al menos hagan revisiones de código. Implementen un proceso liviano que ocurra lo antes de posible después de escribir el código.
Herramientas de análisis estático
En el pasado las herramientas de análisis estático de código se ganaron mala reputación. La generación actual es muy buena y, aunque no son un sustituto a las revisiones de código "humanas" (porque aprenden tanto quien revisa y quien es revisado), son muy baratas de usar.
Automatización
Por si todavía no se dieron cuenta, la mayoría de las sugerencias hasta ahora pueden (y deben!) ser automatizadas. Si no las automatizamos perderemos mucho tiempo realizando estas tareas, pudiendo incluso caer en la tentación de dejarlas de lado. La automatización puede tener un costo a muy corto plazo, que se recupera con creces rápidamente a medida que el proyecto avanza.
Refactor
El objetivo del refactor es mejorar la calidad del código y, más importante, el diseño general. Se pueden hacer refactors sin pruebas unitarias automatizadas, pero es el equivalente a hacer acrobacias en altura sin red. Teniendo las pruebas como red de contención, el refactor debería convertirse en una actividad frecuente que no nos consuma mucho tiempo.
Mostrar y explicar (temprano)
Quizás no resulte obvio porqué esta práctica mejora la calidad del código. Cuando los desarrolladores le muestran al cliente el software que están construyendo de manera regular, se obligan a mantener el código con calidad productiva, funcionando. Esto fomenta un desarrollo de a partes más pequeñas, integrando más seguido.
El segundo objetivo de esta práctica es obtener feedback más frecuente. Esto brinda una guía invaluable sobre lo que se está haciendo bien, o cuando la dirección no es la deseada por el cliente.
Por último, si lo desarrolladores tienen miedo de mostrar su trabajo en progreso a los usuarios, entonces es el momento adecuado para levantar un alerta y empezar a buscar dónde está el problema.
Las pruebas de usuario extienden este razonamiento, y brinda otra línea de pruebas que ayuda a detectar problemas de forma temprana.
Por último, es importante la Cohesión de Equipo porque sino el equipo estaría trabajando en diferentes direcciones y haciendo cosas diferentes al código. Parte de la cohesión de equipo tiene que ser una visión compartida en los objetivos de desarrollo, las ideas de diseño en el código, y qué significa "buen código" para el equipo.
Obviamente esta no es una lista completa, sino un primer paso para empezar a pensar sobre cómo desarrollamos software. ¿Tienen más ideas?
