Cuando la calidad es inversamente proporcional al número de lineas a mantener

Cada nueva funcionalidad en un entorno complejo requiere la comprobación en multitud de situaciones diferentes, se puede tardar horas e incluso días en probar todos los caminos posibles. De este punto se derivan dos cosas, primero mantén el sistema lo más sencillo posible, cuantas más cosas se hagan más probabilidad de error y más checks tendrá tu plan de pruebas. Segundo, se un obseso de la reutilización y minimización de elementos (código fuente por ejemplo) que forman parte de tu sistema. Elimina todo lo superfluo, optimiza al máximo.

Tu calidad de vida profesional es inversamente proporcional al número de líneas de código fuente que tendrás que mantener.

Artículo extraído de del blog de Ramón Arnau. 

Nota: noticia enviada por @ramonchu

Comments

[Juan Luis]

El problema es que no es asi de simple, en el tiempo que llevo desarrollando y dando mantenimiento siempre hay que regirnos a las políticas del cliente, he visto como los analistas y diseñadores temen modificar el código y te dicen copia y pega!!! no toques el otro código, por más que sea el mismo método, no lo quieren usar porque puede entrar en conflicto con lo que ya hay(por más que le digas que no), y terminan habiendo grandes clases con 5 a 20 métodos iguales o que se diferencian en minucias.

Otro punto es que varias veces también me he encontrado con bugs, pero como se dice, si no te han dicho que lo modifiques no lo toques, una vez encontré un código del 2006 en java creo que validaba que "era un número cuando no tenía letras", recorría los caracteres preguntando si es una letra, algo como: !letter.matches("[a-z]").. y no me querían dejarlo cambiar por que no era parte del requerimiento, al final necesitaba el método y les dije que no pasaría las pruebas de validación y lo cambié, pero es toda una odisea hacer desarrollo y mantenimientos para terceros cuando estos tienen políticas absurdas.

Otro caso con que me topé es que desarrollos antiguos tienen un aire a estructurado, nada de herencia ni polimorfismo, y ese es el estándar, si tu quieres desarrollar, incluso algo nuevo tienes que hacerlo como ellos lo hacen, cuando recién me dieron los proyectos, me dieron unos con servlets, luego me entregaron otros proyectos "modernos" con spring mvc, lo que me encontré en spring mvc fue lo mismo que en servlets solo que más revuelto que la patada, un solo controlador con muchos(como si fueran todos los servlets del sistema) métodos con los parámetros httpRequest y httpResponse, y claro.. tienes que seguir la misma estructura, agregar nuevos métodos ahí, de la misma forma que ellos lo hacen.

Es fácil hablar de calidad de nuestro código, pero cuando se trata de mantenimiento, el código sigue un proceso de desgastado, ya sea por que el programador no tiene estándares para programar, o porque tienen una política de NADA SE BORRA o porque todos tienen miedo a tocar algo y terminan copiando y pegando código en vez de generalizar y abstraer, he visto comentarios como "Esto dice que funciona, pero no puedo dar fe de eso!"..

Aunque claro lo correcto sería tener todo el proyecto con pruebas unitarias y eliminar las políticas de que no puedes tocar el código siempre y cuando pase las pruebas. Pero estamos hablando de sistemas heredados y quienes crean los "estándares" de programación de la empresa son programadores que aún piensan como hace 10 años, Aún me pregunto a dónde llegarán esos sistemas viejos y heredados, supongo que los actualizarán pero harán algo como lo que te expliqué más arriba, el paso de servlets a spring mvc. Al final los malos patrones se heredan y nadie puede cambiar eso.

[luis]

Juan estoy totalmente deacuerdo

Ahora la gran pregunta filosófica para responder es: "Como lidiar con políticas estúpidas muy arraigadas"

la otra pregunta es a que hora levantaran su voz de protesta los defensores de esas políticas estúpidas

alguno de ustedes a estado en la estúpida situación cuando un cliente te obliga a usar su "magnifico" framework echo a mano

y como lidian las grandes empresas con la reutilisacion de código lo digo por que mientras mas grande la empresa ponen tremendas barreras para la comunicacion y ademas se esfuerzan lo máximo posible para que todo se haga con burocracia

[jmarranz]

El software que evoluciona mal acaba colapsándose, acaba muriendo, si no tienes el coraje de refactorizar, si es necesario a fondo, tu sistema, para albergar nuevas funcionalidades, podrás vivir "feliz" durante un tiempo más... hasta que todo colapse, entonces se querrá rehacer "en tres días" por las prisas, creando de nuevo otro monstruo...

Refactorizar no se trata de introducir la última tecnología, se trata de MEJORAR si es posible a fondo lo que hay, aunque haya que aceptar ciertas herencias del pasado, pero aceptarlas porque el rehacer a fondo no va a traer grandes mejoras, es aceptar cosas que están "bien" pero podrían hacerse de otra manera, no es aceptar que ***la basura*** merece que conservarse, discernir entre la basura y las herencias razonables forma parte del arte de la refactorización.

Respecto a lo nuevo o viejo, no hay que obsesionarse en exceso, hay cosas viejunas muy dignas y muy bien hechas, aunque tecnologías más modernas podrían mejorar algunos aspectos (por ej reducir código), pero aquí mismo se ha llegado a leer historias de sistemas con XMLs de "configuración" de miles de líneas de código "super modernas", una forma moderna de basura.

Yo siempre diré, hasta que la realidad me diga lo contrario, que el que no exista un mercado de personas y proyectos especializados en refactorización de sistemas, es un signo de lo que habláis más arriba, es un signo de miedo (agonizar en vez tratar la enfermedad asumiendo el riesgo del tratamiento) pero también la sensación de un eterno amateurismo en la profesión (en donde todo parece que vale y todo da igual).