Calidad en el Código – Parte II

En el post anterior nos empezamos a dar una idea vaga de lo que la calidad en el código significa. 

Digamos que  algo siempre tiene calidad, en mayor o menor medida. Algo de paupérrima calidad es un código mal escrito, pegado y hardcodeado de acuerdo a las demandas a satisfacer. Algó con mucha calidad es un código bien formado, que hace lo que dice y nada, que pasa pruebas determinadas y que se ajusta a las métricas definidas.

Verificar lo propio

Tengo un hábito molesto. Cuando termino de escribir las últimas líneas de código para una tarea, compruebo mentalmente que la tarea está completa.

Si tuviera que escuchar esa voz impaciente en mi cabeza, enviaría todo así como está. Pero ese código probablemente contendría muchos, o todos, de los siguientes inconvenientes:

  • Requisitos perdidos.
  • Faltan casos de prueba.
  • Código superfluo, no utilizado o borrador.
  • No hay suficientes comentarios de código.
  • Errores visuales en algunos navegadores / dispositivos.

Si alguna de estas cosas es cierta acerca del código, entonces no está completo. Si alguna de esas cosas termina en la rama principal, entonces se ha degradado la calidad del proyecto por completo.

El punto principal aquí es este: la calidad del código comienza con el autor del código. No se debe confiar en tareas automáticas, una revisión del código da garantía de calidad y las  pruebas de aceptación del usuario para detectar sus errores.

El trabajo de verificación doble para la integridad es un primer paso esencial hacia la calidad del código. Es el paso más fácil de tomar, pero también el más fácil de ignorar.

Siempre me sorprende la cantidad de problemas u oportunidades para refinar una solución que puedo encontrar en mi propio código. Problemas y oportunidades que solo se vuelven visibles para mí cuando doy un paso atrás y veo mis cambios de forma aislada (para ser honesto, cuando lo dejo tirado, frustrado y vuelvo luego).

Puedo revisar trabajo y aplicar mis propios comentarios antes de asignar a un miembro del equipo para que lo revise. Por supuesto antes de hacer un pull.

Tomarse el tiempo para garantizar que el trabajo esté completo, corregir errores obvios o evaluar su solución mejorará la calidad del código. También reduce el esfuerzo requerido para revisarlo.

También podría ahorrar algo de vergüenza… 

Oportuncrisis: Cambios para Mejorar

Seguro estarás pensando que este enfoque agrega tiempo a la duración de una tarea. Y tienes razón, lo hace. Pero eso no es malo.

La eficiencia es importante, pero la pereza y la apatía son dañinas. La apatía lleva a un código sucio e inconsistente. La pereza crea una acumulación creciente de malas prácticas técnicas. No podemos ser pasivos y mantener la calidad del código. Requiere tiempo y esfuerzo.

Cambiar la cultura en torno a la calidad del código puede ser difícil. Los gerentes de proyecto y los propietarios de los productos en general no están preocupados por la calidad del código; tienen sus propias preocupaciones. Solicitar tiempo extra para procesos de calidad de código puede caer en oídos sordos. Sin embargo, mantener la calidad del código no debe considerarse como algo adicional; debe ser un requisito inherente de cada tarea.

Como desarrolladores, si no cambiamos la manera en que pensamos sobre la calidad del código, no podemos esperar que nadie más lo haga.

Nada de lo que he hablado aquí es particularmente revolucionario, ni es preceptivo. No todos los equipos, lugares de trabajo o proyectos son iguales, y parte de lo anterior quizás nos ea aplicable.

Creo que a menudo existe una brecha entre la forma en que los desarrolladores piensan sobre la calidad del código y las acciones que realmente se toman para abordarla. 

La experiencia marca que la gran mayoría de los programadores del mercado argentino están abviando cualquier o casi cualquier sistema de comprobación de la calidad… Una lástima.

Dejá un comentario