Calidad … superficial
Como me estoy retrasando con la continuación sobre mi productividad personal, quiero compartir con vosotros una reflexión sobre calidad. Hablemos de vender chapa y pintura.
Hubo un tiempo en que me encontré con una funcionalidad que llevaba años en producción sin ser modificada, que estaba cubierta con la implementación de 18 métodos test diferentes. A priori para una persona que llegase nueva al proyecto, podría ser una funcionalidad confiable, podría ser un código tranquilamente refactorizable ya que si el nuevo código supera los 18 test seguirá siendo confiable.
Cuando me puse a rascar…
Esta funcionalidad estaba implementada en un método de unas 60 líneas en una capa errónea (service, cuando se trataba de un proceso batch), en una clase con unas 4.200 líneas. Tras rascarla un poco la dejé en 3.200 líneas, y aún quedaban métodos duplicados, métodos que había que sacar a otras clases (como éste), y bloques de código que había que encapsular en nuevos métodos. Calculo que el tamaño adecuado serían unas 750 líneas. De las más de 14mil líneas de código de su clase de test, ni hablamos.
Lo bueno, si breve, dos veces bueno. Y si está en su sito, tres veces. Y si se entiende a la primera, cuatro veces. Y si hace lo que debe y no hace lo que no debe, 10 veces.
La implementación tenía un return dentro de un bucle anidado dentro de otro bucle, lo que provocaba un fallo ya que lo que realmente se quería era un break (salir del bucle anidado, no del método). Dentro del primer bucle había 5 estructuras if anidadas, luego venía el segundo bucle que contenía otro if que contenía el erróneo return. Por supuesto, 0 trazas para garantizar que un método con esta estructura sea entendible y certero.
Niños, ojo al utilizar sentencias de control del flujo del programa, cada método debe tener 0 breaks, 0 returns (si es un void) o 1 return.
Por si no fueran pocos los errores que ya introducía ese return, se comprobaba la integridad de los datos desde el punto de vista del negocio, pero no se hacía nada en caso de no superarse lo que ocurría en el 12% de los casos, por lo cual el 12% de los casos llevaba fallando desde el principio de los tiempos en esta funcionalidad, pero apostaría sobre seguro que ese mismo 12% de casos estaría fallando desde el principio de los tiempos en otras funcionalidades. Y después de comprobarlo, al menos encontré otras 2 funcionalidades en las que fallaban.
No te fíes aunque baje Dios y te diga que funciona, compruébalo tú mismo.
El proyecto cuenta con literalmente cientos de líneas de código y pruebas (aunque extrapolando este caso al proyecto, seguro que podríamos apañarnos con 20mil líneas de código), y los WAR generados con su “arquitectura” (indocumentada) pesan más de 80 megas (el proyecto más complejo tecnológicamente en el que he estado, struts, spring, hibernate, ibatis, jasperReports, 2 drivers de bbdd, servicios web, encajado en un Single Sign On, jquery y me dejo algo, pesaba 20 megas).
Los proyectos Java se deberían basar en dos conceptos : Modularidad y Reusabilidad.
Finalmente, el código fue proporcionado por un proveedor externo, y al comunicarle que me disponía a limpiar su código me respondió que si modificaba el código perdería la garantía. Tenían notificados errores sin resolver desde hace un año.
Las convenciones de código y las buenas prácticas, sirven para que tu garantía tenga valor.
Qué pensarías de este proveedor? Qué valor le daríais a su garantía? Vosotros confiaríais el arreglo de ese embolao al mismo que lo creó?
PD, esperas que nos saquen de la crisis los mismos que nos metieron? Qué haces para impedirlo?
