Odiar a algien es darle demasiada importancia
:)

Maven – Convenciones – Estructura de carpetas

Maven es configurable, es decir podríamos utilizar nuestra propia estructura de carpetas.

Pero es altamente recomendable seguir las convenciones Maven ya que cambiarlas no nos aporta ningún beneficio en el 99,99% de los casos y sin embargo cuesta tiempo de desarrollo (cambiarlas y que funcione) y de mantenimiento (la aplicación tendrá una curva de aprendizaje más alta y será más propensa a bugs).

La estructura de carpetas que nos sugieren desde el proyecto de Maven es la siguiente:

|- pom.xml

|- target, aquí el compilador situará los recursos compilados.

|- src

|- main

|- assambly, configuración para el empaquetado de la aplicación.

|- config, configuración para los diferentes profiles.

|- java, código fuente de la aplicación.

|- filters, ficheros de recursos de filtros.

|- resources, ficheros auxiliares de la aplicación (mensajes y properties).

|- sql

|- webapp, recursos del WEB-INF: jsp, imágenes, css.

|- site

|- docs, documentación del proyecto.

|- test

|- java, código fuente de los tests de la aplicación.

|- resources, recursos utilizados en los tests.

Image seen on mkyong.com.

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, cuya implementación estaba cubierta por 18 métodos diferentes de test. A priori para una persona que llegase nueva al proyecto, podría ser una funcionalidad confiable y un código tranquilamente refactorizable.

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. Estimo que el tamaño adecuado serían unas 750 líneas, otro indicador de que esta clase debería ser rediseñada.

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 miles de líneas de código y pruebas (aunque probablemente podríamos apañarnos con 20mil líneas de código), los WAR generados con su “arquitectura” (indocumentada) pesan más de 80 megas (con mucho sudor después lo dejamos en 20 megas), y tardaba unos 3minutos y medio en arrancar (lo dejamos finalmente en medio minuto).

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?

Escribir código por párrafos

Cuando empecé a programar profesionalmente, yo pensaba que escribir código por párrafos era de cajón y que todo el mundo lo daría por supuesto por las enormes ventajas que aporta a la hora de mantener un sistema, pero para mi sorpresa me encontré que no es asi.

Cuando leo una novela y veo un párrafo de varias páginas, tiemblo porque el autor no ha sabido / querido  ordenar suficientemente bien sus ideas y te lo suelta todo ahí de sopetón. Como si fueses a un restaurante y pidieses una entrada, un plato, un postre, un café y una bebida y el camarero te lo sirviese todo junto pasado por la batidora.

Y a la hora de escribir código ? No importa si es HTML, XML, C, Pascal, Java… Es importante escribir por párrafos para que la persona que no conoce el código lo lea y entienda rápidamente. Yo lo aprendí en Pascal, todos mis programas tenían únicamente 3 funciones : inicializar, procesar y finalizar.

Pongamos un ejemplo, un bean POJO en Java. Normalmente el contenido del bean lo podemos estructurar en 2 párrafos : declaración de las variables locales y declaración de los métodos públicos get y set de cada variable. A veces podemos tener 3, si declaramos constructores para ese bean. O 4 si sobreescribimos métodos get o set. O 5 si declaramos otros métodos (como sobreescribir el toString())… Pero si el bean está organizado por párrafos de un vistazo lo vemos, cualquiera tardaría 5 segundos en leer y entender la clase por muy grande que sea sin necesidad de leer cada letra.

Comenta