Cambio en el código:

En un proyecto que estamos trabajando ha llegado el punto que cada cambio en el sistema, cada nuevo requisito; implica la repercusión de otra funcionalidad o de otra parte del desarrollo. Hemos tenido que testear la aplicación minuciosamente en desarrollo y calidad antes de pasar a producción ya que un error en esa parte puede ocasionar el mal funcionamiento de otras.  

Leyendo hoy el libro de “Código limpio” relata bien la problemática a la que nos estamos enfrentando:

... los equipos que avancen rápidamente al inicio de un proyecto pueden acabar a paso de tortuga. Cada cambio en el código afecta a dos o tres partes del mismo. Ningún cambio es trivial. Para ampliar o modificar un sistema es necesario comprender todos los detalles, efectos y consecuencias, para de ese modo poder añadir nuevos detalles, efectos y consecuencias. Con el tiempo, el desastre aumenta de tal modo que no se puede remediar. Es imposible.

Al aumentar el desastre, la productividad del equipo disminuye y acaba por desaparecer. Al reducir la productividad, el director hace lo único que puede: ampliar la plantilla del proyecto con la esperanza de aumentar la productividad. Pero esa nueva plantilla no conoce el diseño del sistema. No conocen la diferencia entre un cambio adecuado al objetivo de diseño y otro que lo destroce.  

 Así que por lo tanto hay que testear mucho, conocer las implicaciones de cada cambio, codificar de forma entendible no solo para uno sino para los que nos siguen puedan añadir, corregir funcionalidades rápidamente. Tal como lo dice en el libro “debemos tratar de que el código se explique por si solo”.

Añadir nuevo comentario