programming & spanish Franchu on 05 Aug 2008 12:50 pm
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.
on 06 Aug 2008 at 21:33 1.Martín said …
Franchu, supongo que me toca responder a este post aunque sea por alusiones, porque supongo que el enlace que has puesto es una crítica indirecta a mi post acerca de patrones, aunque tampoco estoy seguro a que parte, así que asumiré que es a todo
El artículo que mencionas es realmente interesante, así como tu post. De hecho, en efecto tanto la sobreingeniería, como el desconocimiento de los patrones básicos (léase GOF), como la falta de estudio del problema que se está tratando, como el desconocimiento de patrones aplicados en escenarios concretos (por ej. patrones de mensajería para programación asíncrona) y que no son tan conocidos, son algunos de los puntos que critico en el artículo original, y son algunas de las principales causas de código que Philip denomina “ugly code”.
Un código demasiado elaborado (ej. enlazar patrones a lo loco o utilizarlos sin que sea necesario) añadiendo código que nunca se utilizará, implementar patrones sin pararte a estudiar como funcionan o tu plataforma simplemente porque te parece más bonito (ej. singletons), creerse que con leerte un par de libros está todo hecho y dormirte en los laureles ignorando que el software es aprendizaje continuo y reinventando patrones/frameworks ya existentes por falta de análisis o ganas, etc. son causas de código que puede parecer bonito, pero está podrido por dentro ya que genera una carga enorme de esfuerzo en cuanto a testing, se convierte en difícil de mantener, casi siempre resultará incomprensible salvo para el que lo ha escrito, y en resumen: ¡es código feo!
Volviendo a la frase de la polémica, pragmatismo sería ese justo punto de arte que hace que el código sea bonito al tiempo que optimiza el proceso de desarrollo. Yo no quiero un código mega-bonito si va a hacer que mi equipo de testers tenga que pasarse un mes extra creando test cases que jamás se usarán y que al final seguramente sólo me cubrirán el 50% de los posibles casos, o tragarme un nuevo patrón DAO espectacular (como hace unos meses) + un sistema de gestión de dependencias también espectacular, pero de calidad más que dudable sólo porque al Arquitecto jefe no le apetecía aprender Spring y Hibernate y consideraba que su capacidad de programador/artista era igualable a la de sus autores; asimismo, tampoco quiero un código chapucero que me soluciona el problema en este momento pero que a la larga me creará muchísimos más problemas en cuanto a mentenimiento, testing, etc.
Bueno, creo que esto me ha quedado bastante largo. Disculpas por semejante comentario, pero este es un tema realmente apasionante.
Un saludo!
Martín
on 06 Aug 2008 at 21:43 2.Franchu said …
Hola Martín,
antes de nada agradecerte el comentario
La referencia a tu artículo no era una crítica, ni mucho menos! Simplemente, me pareció muy acertada tu frase de que en una empresa lo que importa es el pragmatismo y es un detalle que no siempre se tiene claro cuando eres joven y te incorporas al mundo laboral
De hecho compartí tu post con los compañeros del trabajo y la frase ha calado hondo porque sintetiza en pocas palabras algo que es bastante más complejo de explicar
Un saludo!
Franchu
on 06 Aug 2008 at 23:26 3.Martín said …
Ah, pues perdona por el malentendido entonces, pero es que por la frase había entendido otra cosa (”algo como si trabajas donde este que no les gustan los patrones”)…
on 14 Aug 2008 at 15:31 4.Luix said …
El principal problema del código ofuscado y “feo” no es la belleza del asunto, sino fundamentalmente la mantenibilidad y la extensibilidad, que puede ser una auténtica pesadilla, sobre todo cuando la documentación disponible de ese código es más bien escasa.
Aparte de esto podemos citar otros problemas como la fiabilidad o la robustez, pero esto ya no tiene tanto que ver; un código puede ser ofuscado (de hecho existen programas que cogen código C y lo ofuscan… si acaso C ya no era de por sí ofuscado) y funcionar perfectamente.
Al final todos sabemos cómo funcionan las cosas en el entorno laboral y que por culpa de unos y otros no se comprende la dificultad que entraña el desarrollo de software de calidad y que las labores de ingeniería son necesarias y complejas, puesto que la implementación puede llevarse a cabo de una u otra manera, pero el diseño es mucho más crucial; dado un problema existen numerosas soluciones (diseños) posibles, y la mayoría de los problemas del software están relacionados con el diseño, y no con la implementación o la habilidad de las personas para implementar.