programming & spanish Franchu on 05 Aug 2008
La economía de testear código malo
El otro día encontré un post en el que explican la economía de testear código malo y la verdad es que merece la pena echarle un vistazo sobre todo para darnos cuenta de que a veces las cosas son como son y si trabajamos en una empresa lo que importa es el pragmatismo y nos tocará sacar adelante proyectos en los que el código que heredemos no sea todo lo bueno que sería deseable.
En algún momento a todos nos han entrado ganas de tirar a la basura el código que hay y empezar de cero, y aunque como desarrolladores sea la mejor opción, para una empresa que se rige por criterios económicos no es una solución aceptable.
En el artículo explican muy bien como para la mayoría de la gente que no tiene que ver el código fuente de una aplicación, el valor no es función de la calidad del código sino de que la aplicación esté probada o en producción.
Cuando una versión del código ha sido testeada y/o ha llegado a producción, su valor aumenta instantáneamente y cualquier cambio de código hará que pierda valor porque carecerá de la seguridad de que en la nueva versión todo funcione correctamente. El famoso, si funciona no lo toques
Sin embargo, lo que ve el programador es que un mejor código aumenta el valor del mismo:
Para el desarrollador que quiera tomar una decisión de mejorar el código le quedan dos opciones:
- Moverse a la derecha hasta un punto en el cual las mejoras del código hagan que tenga más valor por si mismo que el código actual que ya ha sido probado, con el riesgo de que esto solo se pudiese producir con tecnologías y/o técnicas de programación inexistentes
- Desarrollar un sistema de pruebas automático que permita testear los cambios de código con el fin de ir aplanando el pico creado por el testeo o la puesta en producción de la aplicación. Si el proceso es automatizable, se logrará evolucionar el código sin demasiadas reticencias en la empresa
Para una explicación más detallada os recomiendo que leais el artículo original.




