Calidad en el Código – Parte I

¿Qué pensamos cuando pensamos en la calidad del código?

¿Es consistencia? ¿Es implementar un conjunto de estándares y mejores prácticas al código a través de las reglas y definiciones de negocio? ¿Hay que asegurarse de que el código tenga pruebas que se ejecutan automáticamente durante su proceso de compilación? ¿Qué pasa con las solicitudes de extracción y las revisiones de códigos? ¿Podemos ompartirlo de forma segura? 

Son algunas de las cosas que me vienen a la mente. Procesos automatizados y verificaciones manuales. Inteligencia y eficiencia. Sin embargo, si bien todos son útiles, solo abordan la mitad del problema.

No podemos automatizar todo

La automatización es crucial para mantener la calidad del código. El análisis estático de sintaxis y las pruebas automatizadas deberían ser obligatorias. Pero puedo escribir código que pase todos los procesos automatizados sin ninguna garantía a su calidad real, que un código esté bien formado es un inicio pero nunca garantizará que tenga aunque sea un poco de calidad.

¿El código sigue patrones establecidos? ¿Utiliza módulos existentes o duplica código? ¿Está el código en el lugar correcto? ¿Si lo cambio tendrá implicaciones más amplias e involuntarias? ¿Este código realmente aborda / resuelve lo que pretende? ¿Funciona?

Los procesos automatizados no pueden responder esas preguntas (todavía). Si yo como programador (u otro ser humano) no hace estas preguntas sobre su código, probablemente no esté enviando código de calidad. Es por eso que tenemos revisiones de código.

Una buena revisión de código debe ser más que el código. Sinergia pura.

Por supuesto, una revisión del código debe ser sobre el código (está ahí en el nombre, después de todo). Pero también debería tratarse de las preguntas más generales planteadas anteriormente y también del producto final.

He notado una tendencia de los desarrolladores a tratar las revisiones de códigos como superficiales. Un control rudimentario del código modificado. Un comentario sobre cualquier error obvio (o simplemente elegir uno o dos para parecer ocupado).

Cinco minutos, trabajo hecho. Me parece bien.

Pero el código que no aborda los requisitos de la tarea no es un código de calidad. El código que produce errores de consola o errores visuales en el dispositivo / navegador no es un código de calidad. Ninguna de esas cosas se puede recoger en una revisión del código superficial. No puede revisar el código adecuadamente a menos que realmente lo ejecute.

Una buena revisión del código implique como mínimo:

  • Tirando de la branch hacia un entorno local. (Siempre es mejor trabajar de manera local)
  • Construyendo el proyecto (y verificando que el linter y las pruebas pasen).
  • Comprobando que el código se ejecuta sin errores en los navegadores / dispositivos móbiles.
  • Verificando que el trabajo completado coincida con los requisitos de la tarea.

Si hay algún problema con alguno de esos pasos, se debe rechazar la solicitud. No pasa. No hagas merge con la branch principal.

Los revisores también deben usarla como una oportunidad para hacer preguntas. Si no se comprende el código, no se debe aprobar.

El revisor tiene la misma responsabilidad con el autor por la calidad del código. Esta es una mentalidad esencial para mantener la calidad del código.

Las revisiones integrales de los códigos contribuyen en gran medida a garantizar la calidad del código. Pero hay pasos que se pueden seguir antes de haer un pull. Son las pequeñas cosas que se pueden hacer las que  ayudarán  a mejorar la calidad de su código y reducirán el esfuerzo requerido para revisarlo.

Seguimos la próxima semana….

Dejá un comentario