Parchar código o rehacer código.

Este sin duda es un tema muy polémico y quisiera aclarar que mi objetivo no es ofender a nadie, si no proporcionar un punto de vista de lo que ocurre en algunas consultoras de software.

Sin duda,  cuando nos dan un sistema heredado para corregir un bug, lo primero que hacemos es encontrar  el error y corregirlo, pero que pasa realmente con ese parcheo, realmente era solo un bug o una señal de que hay vicios ocultos en la aplicación.

Hace un año corregir bugs era el peor de mis miedos en el trabajo, sin duda era por que tenia que enfrentarme a código que no era mio, incluso en varias ocasiones (en la mayoría) era código que no estaba identado, no estaba comentado, no tenia buena nomenclatura, no tenia buena lógica e incluso en algunos casos estaba mas parchado que una llanta de bicicleta, incluso sistemas que se volvían en el antipatrón Stovepipe system, su traducción al español seria sistema parchado.

En mi antiguo trabajo cuando se presentaba un modulo tipo Stovepipe, me presentaba a proponer rehacer el código y codificarlo de acuerdo al proceso de la aplicación. Era increíble que su respuesta fuera que no había tiempo y que solo lo parchara.

Era increíble el desgaste que deja el navegar por un sistema Stovepipe , estar revisando el código y checando la secuencia de su flujo, y lo triste era darte cuenta que ya habían pasado otros desarrolladores y el sistema también se había convertido en un fabuloso y estupendo código espagueti (otro antipatron de diseño).

En conclusión, es más tardado parchar que rehacer código, por que en mi nuevo trabajo, me a tocado corregir módulos, y se a optado en rehacerlos, y el tiempo casi es el mismo solo que ya queda mucho mas estructurado el código y sobre todo, que cumple con el requerimiento.

Cuando se trata de corregir bugs en un sistema bien estructurado, a lo mucho hay que validar objetos nulos, variables mal asignadas, operaciones de mas, manejo de componentes, entre otras cosas.

En conclusión, si el sistema esta asquerosamente mal, hay que pensar en rehacer partes principales acordes al requerimiento. Y si el sistema esta bien hecho, solo hay que corregir esos bugs.