En general nadie crea código inmantenible de forma intencional (ignorando los casos de algunos consultores que escriben mal código para forzar a quedarse con el contrato). Sin embargo, el mal código va creciendo de forma lenta y segura a lo largo del ciclo de vida del producto.
Vamos a ver dos formas de pensar (de "jefe" y "desarrollador") que llevan a la aparición del mal código en nuestras aplicaciones.
Lo que piensa el jefe
Escribamos código rápido. No tenemos mucho tiempo para la próxima entrega. Y si no hacemos la entrega, el proyecto podría morir. Dejemos la mantenibilidad a largo plazo como una prioridad secuendaria, que vamos a ir mejorando después de la entrega cuando tengamos tiempo. Además, andá a saber si voy a estar trabajando en este proyecto en un año.
- Desafortunadamente, si la entrega es exitosa, el próximo ciclo de entrega va a tener una planificación todavía más ajustada.
- El código se "escribe una vez" y se "lee cientos de veces" durante todo el ciclo de vida. El costo de mantenimiento subsecuente es cientos de veces más alto que la ganancia que se obtuvo en la entrega inicial.
No puedo justificar el gasto de ningún recurso en hacer un refector porque no agrega ninguna característica a la próxima entrega. El código ya está funcionando. Ustedes mencionan que se mejora la mantenibilidad del código y yo no sé como cuantificar eso.
- Así es como se retiene y acumula el mal código. Una vez que alcanza cierto punto, todos aceptan que el mal código está tan mal que ya no existe motivación para mejorar.
Dejemos que los desarrolladores se concentren en escribir el código. La gente de QA se ocupa del testing. De esta manera, ambos pueden avanzar a toda velocidad en paralelo.
Lo que piensa el desarrollador
Hay una lógica similar que está funcionando en otro lugar, pero no es exactamente lo que necesito. No tiene todas las características de mi requerimiento y también tiene otras características que no necesito. No vale la pena que gaste tiempo en leer y comprender cómo funciona, mejor reimplemento mi propia versión desde cero.
- Así es como aparece la lógica duplicada en los sistemas: muchas formas de hacer lo mismo.
Hay una lógica similar funcionando en otro lado. No vale la pena gastar mi tiempo reinventando la rueda. Mejor la copio acá y la modifico según mis necesidades.
- Esta es otra forma de duplicar código. Cuando cambiamos el código en un lugar, necesitamos hacer los arreglos correspondientes en los otros lugares donde hicimos copias, sino alguna de las copias puede dejar de funcionar correctamente.
Este código funciona, por favor no hacerle ningún cambio.
- Así es como se retiene y acumula el mal código. Una vez que alcanza cierto punto, todos aceptan que el mal código está tan mal que ya no existe motivación para mejorar.
Por supuesto que el código es dificil de leer, porque está resolviendo un problema complejo. Si el código fuera facil de leer, seguro que no está haciendo nada importante. Necesitás ser más inteligente cuando lees el código.
No estoy convencido que esta sea la forma correcta de hacer estas cosas. Por lo tanto, no voy a seguir la convención aunque se esté usando en otros lados. Lo voy a hacer a mi forma.
No sé porqué lo tengo que hace3r así. Pero como esta es la forma en al que está hecho en otros lugares, voy a seguir la convención. La "consistencia" no es un problema, ¿no?
