Reduciendo el tamaño del código de un proyecto Java.

En la siguiente gráfica podemos observar la evolución del número de clases, métodos y lineas de código en el proyecto en el que me encuentro actualmente.

reduciendo_lineas_de_codigo

Donde:

  • La linea azul indica el número de clases.
  • La linea naranja indica el número de métodos.
  • Y la linea verde indica el número de lineas.

Como podemos observar no han hecho más que reducirse desde el mes de Junio. Es decir, con menos lineas de código, menos clases y menos métodos estamos en estos momentos implementando más funcionalidad que hace 6 meses (la implementación de nuevas funcionalidades ha continuado durante estos meses). Es sin duda, uno de los logros de los que más contento estoy en este proyecto.

Y me gusta, porque que más se puede pedir: que hacer más y mejor con menos lineas de códigos. Si recordamos el principio KISS ( siglas de Keep It Simple, Stupid):

“La perfección se alcanza, no cuando no hay nada más que añadir, sino cuando ya no queda nada más que quitar.”

El trabajo no ha sido fácil. El principal problema es cambiar la inercia en un proyecto y los programadores. Es muy dificíl en proyectos en los que:

  • Lo importante es desarrollar, desarrollar, desarrollar y sacar nuevas funcionalidades al precio que sea.
  • Y sobre todo, donde la filosofía que se impone es: “para que voy a cambiar algo que ya funciona“.

En este punto hay que tener claro un par de cosas:

  • El concepto de “funciona”. Por ejemplo ¿consideráis que funciona una funcionalidad que esta repetida n veces a lo largo del código? Yo estoy convencido de que terminara generando alguna incidencia. ¿Funciona? si, ¿pero durante cuanto tiempo?. ¿En que momento dejaremos de actualizar esa funcionalidad en algunos de los sitios que se repite?.
  • No estamos haciendo calidad. Maldigo el significado que se le suele dar a esta palabra, y es que en muchos casos se suele entender por calidad una tarea adicional y por tanto como excusa para evitar los cambios. Estamos hablando de corregir nuestros errores, nuestras limitaciones no de mejorar el código. Calidad es lo que haremos después de esto.

Por eso hay que hay y darse cuenta de que el tamaño si importa y comprender como repercute en nuestro desarrollo:

  • Cuando más código, más grande es lo que estamos construyendo y por tanto más difícil de manejar por las herramientas que lo gestionan: el servidor de aplicaciones, el entorno de desarrollo, el entorno de integración continua, etc. Todo va cada vez más lento y es más pesado. Por ejemplo,  si utilizas Spring cuantas más clases más tardara en cargarse el contexto.
  • Tener nuestro código “bueno” entre miles de lineas de código duplicado o que no se utiliza es una locura para el mantenimiento.
  • Y que pasa cuando tenemos que refactorizar. Cambias cosas en sitios en los que no hace falta porque no se esta utilizando (código que no se utiliza). Cambias la misma cosa en varios sitios (código duplicado).

Por tanto, el principal problema para abordar este problema es el cambio de mentalidad. Es lo que más vamos a tener que trabajar. Hay que tener en cuenta este aspecto desde el principio del proyecto y gestionarlo más durante todo el proceso de desarrollo.

A continuación paso a explicar las herramientas que hemos utilizado y me permito ofrecer algunos consejos que nos han resultado útiles.

Para controlar el tamaño de nuestro código hemos trabajado los siguientes puntos:

  • Reducir el código que no se utiliza.
  • Reducir el código duplicado.
  • Y sobre todo, reducir las funcionalidades duplicadas, tanto a nivel de negocio como elementos de la arquitectura.

Para ello nos hemos basado en las siguientes herramientas:

El Sonar.

http://www.sonarsource.org/

Desde el panel de control nos permite:

  • Tener identificadas las partes del código donde se producen las malas prácticas que anteriormente hemos mencionado.
  • Y nos permite ver la evolución de estas métricas a lo largo de la vida del proyecto.

Esto lo podemos hacer mediante los siguiente widgets:

  • Size metrics, nos proporciona información sobre el tamaño del proyecto.
  • Timeline, información sobre la evolución de estas métricas.
  • Comments & Duplications, código duplicado.
  • Useless Code Traker, código que no se utiliza.

widges_sonar

Mediante el Size Metrics y el Timeline podemos estar al día de las cifras y de su evolución a lo largo del tiempo.

Bueno, el Timeline es un widget más genérico que se puede configurar para ver la evolución de las tres métricas que nosotros deseamos. En nuestro ejemplo esta configurado para mostrar el número de clases, métodos y lineas.

Mediante Comments & Duplications (¿porque irán juntos comentarios y duplicaciones?) podemos encontrar donde se encuentran los duplicados. En la siguiente imagen se puede observar como nos ofrece la información:

duplicate_code

Por defecto, siempre he utilizado la configuración por defecto, aunque parece que se configurar. Para más información sobre el tema: Manage Duplicated Code with Sonar.

Y mediante plugin Useles Code Tracker el código que no se utiliza.

Que si no me equivoco es una mezcla de información que ya tenemos: ofrece la información del código duplicado que se podría eliminar y algunas reglas que vienen con el PMD y  SQUID: PMD:UnusedPrivateMethodSQUID:UnusedPrivateMethodSQUID:UnusedProtectedMethod.

Para más información os remito a la documentación Useless Code Tracker Plugin.

Plugin PMD/CPD para eclipse.

http://pmd.sourceforge.net/eclipse/

El  PMD  nos proporciona otra herramienta: CPD que busca código duplicado. Para poder utilizarlo podemos utilizar el PMD  como plugin de eclipse y seguir los pasos que indicamos a continuación.

Para ejecutarlo, pulsamos botón derecho sobre un proyecto y seleccionamos la opción PMD | Find Suspect Cut and Paste tal y como podemos ver en la siguiente imagen.

cpd-eclipse

el cual nos crea en un directorio “report” de nuestro proyecto un informe con el nombre de cpd.txt.

cpd-report

Recomiendo ir por partes y dividir el trabajo de eliminar código duplicado en fases. El código duplicado puede estar:

  • En la misma clase.
  • En clases del mismo paquete o entidades de negocio.
  • En paquetes que no tienen nada que ver unos con otros.

Recomiendo empezar por las dos primeras que son relativamente fáciles y que normalmente se resuelve con un refactor que permite extraer el código a un nuevo método o clase.

nuevo_metodo

En cambio el código duplicado entre diferentes paquetes puede implicar cambios más importantes:

  • La creación de nuevos paquetes a un nivel alto.
  • O delegar parte de la lógica a otros servicios que ya están funcionando y que son los que realmente tienen esa responsabilidad.

Aunque sin duda la mejor técnica para evitar el código duplicado es evitar o tener mucho cuidado con el Copiar y Pegar.

Plugin UCDetector para eclipse.

http://www.ucdetector.org/

Es un plugin para eclipse que nos permite encontrar código muerto. Es decir, clases, métodos y propiedades que no se utilizan.

Se instala como cualquier otro plugin desde la dirección http://ucdetector.sourceforge.net/update.

Y para utilizarlo, botón derecho sobre un proyecto y seleccionar las opción UCDetector | Detect Unnecesarie Code.

popup

Mostrándonos los resultados en las clases afectadas y la vista de problemas de eclipse.

markers

Aunque ojo, porque cuando intentamos detectar código que no se utiliza hay que tener en cuenta que en algunas circunstancias ya que si que se puede estar utilizando:

  • Si utilizas Spring recuerda que las implementaciones no se llaman desde el código: son las interfaces.
  • Si utilizas reflection evidentemente habrá parte del código que no se referencie.
  • Ten cuidado con las clases que ofreces como APIs a terceros. Estas clases como puntos de entrada no tendrán ninguna referencia dentro de nuestro código.
  • Etc.

En eclipse la combinación de teclas CONTROL + SIFTH + G.

La cual dada una clase, método o propiedad te indica si esta siendo referenciado o no desde el espacio de trabajo.

Configurar el formateador de código de eclipse para que la guardar elimine código que no se utiliza.

Es sin duda la opción que menos esfuerzo nos requiere. Configuramos el eclipse para que cada vez que guarde el código fuente de una clase elimine los elementos que no se utilicen en dicha clase.

Buscamos en el Eclipse en Preferencias | Java | Editor |Save Actions:

formateador_save_actions

Y configuramos la pestaña de Unnecesary Code:

formateador_eclipse

Ojo con esta configuración, porque puede causar problemillas ya que cada vez que guardas te elimina lo que no estés utilizando en ese momento, aunque lo vayas a utilizar a continuación. Por eso, normalmente los métodos privados no solemos marcarlos.

Otras herramientas que pueden ayudarnos

Antes os he indicado 3 herramientas que nos pueden servir en esta labor y yo creo que son más que suficientes. En cualquier caso aquí os dejo otras que también he probado:

  • CheckStyle, al igual que PMD viene con su herramienta para la detección de duplicados.
  • Atomiq, que me encanta. Me gusta mucho la representación gráfica en la que muestra el código duplicado. La cuestión es que es de pago pero tiene una versión de evaluación de unos días.

getatomiq

  • CodePro AnalytiX, plugin Eclipse de Goolge para analizar código Java que entre otras virtudes tiene la de detectar código duplicado o similar.
  • Proguard, es una herramienta para optimizar y ofuscar código java. Entre sus tareas esta la de eliminar clases, métodos, etc, que no se utilicen. Yo no lo he probado y la verdad es que no se como funciona, ya que entiendo que la acción de eliminar código que no se utiliza, forma parte del proceso completo. Pero lo pongo en la lista porque ya he visto a varios autores que lo recomiendan.
  • Structure101, es una aplicación de pago que también nos permiten detectar lo que ellos llaman clases huerfanas (“Orphans”).

Bueno, ya esta, supongo que aquí faltaría ahora hablar de técnicas de programación o de algunos patrones que nos ayudan a no repetir código. Bueno, para otro artículo!!! en cualquier caso la mejor técnica es la de no copiar y pegar. Y sobre el código que no se utiliza pues no tengamos miedo a eliminarlo lo tenemos en el control de versiones. Ya nos resulta complicado manejar un código relativamente limpio como para que debamos manejarlo acompañado de código que no se utiliza y código duplicado.

Reduciendo el tamaño del código de un proyecto Java.

¿Que dos cosas le pediría a un programador?


Bueno dos cosas, entre otras muchas cosas. Pero sin duda les pediría y preguntaría:

  1. ¿Si en su carrera profesional han llegado a implantar un proyecto?. Es decir, han llegado a ponerlo en producción y liberarlo con éxito para que los usuarios los utilicen en su vida diaria.
  2. ¿Si han desarrollado algún proyecto para usuarios que lo van a utilizar porque les gusta o interesa y no por obligación?. Es decir, no un proyecto para un usuario de intranet de empresa que tienen la obligación de utilizarla si o si.

Y en ambos casos: ¿cual ha sido el resultado?. Aunque este es un aspecto un poco menos importante.

Si una persona en su vida profesional me responde afirmativamente a las dos preguntas anteriores me generara mucha más confianza como profesional que otros.

Liberar un proyecto no es una tarea fácil. El que crea que ya ha terminado un proyecto cuando los usuarios todavía no lo están utilizando de forma habitual se equivoca. El objetivo del proyecto es precisamente ponerlo en producción y que el usuario lo utilice.

Que las personas que trabajan en el proyecto sean capaces de tener esto claro no es una tarea sencilla. Y no lo digo por decir, estoy actualmente en un proyecto en el que prácticamente nadie a puesto un proyecto en producción. Y algunos de ellos son gente que ya llevan 6 años o más trabajando. Pero son personas que en sus 6 o más años de vida laboral no han hecho más que saltar de proyecto en proyecto y de empresa en empresa y nunca han terminado nada. Les falta por tanto ese “toque”, esa “mentalidad” que te permite “terminar” el proyecto. Son personas para las cuales termina el proyecto cuando se van o los cambian, no cuando lo entregan. Y esto termina suponiendo un montón de problemas.

La respuesta afirmativa a la segunda pregunta me garantiza calidad y preocupación por lo que estas haciendo. Me garantiza que has tenido que pensar en el usuario y que te lo estas intentando ganar con la aplicación: porque es usable, porque va rápida, porque esta llena de funcionalidades que te agradan, etc.

!! Que diferentes serían muchos proyectos en los que he trabajado!! para intranets de algunas empresas, si no viésemos al usuario de la aplicación como un empleado que tiene que usarla si o si. Que parece que le puedes colocar cualquier cosa. Los usuarios de aplicaciones de Internet no se andan con tonterías: si no funciona no la utilizan y ya esta. Te dejan ahí con dos palmos de narices. Los tienes que cuidar y ofrecer lo mejor de lo mejor.

En resumen, me gustaría trabajar con gente:

  • Que sepa que el objetivo del proyecto es un “producto” puesto en producción y funcionando.
  • Que debemos hacer la aplicación como si fuésemos a cobrar por ella y por tanto, cuidando y mimando al usuario.

Siempre nos estamos quejando (con razón en muchos casos) de otros elementos que interfieren en el proyecto, cuando todavía queda mucho por mejorar en nosotros mismos.

El otro día leía en twitter “Con la tecnología actual se pueden hacer las cosas mejor y mucho más rápido ” y estoy seguro y convencido de que es así.

¿Que dos cosas le pediría a un programador?

Ecosistemas de desarrollo de software: lineas de automatización.

Todo este tema de los Ecosistemas de Software y la Integración Continua me encantan y me fascinan.

Se por experiencia que la mayor parte de los problemas y retrasos que se producen en los proyectos actuales es por no poner cuidado y el suficiente cariño en estos temas. No se les da la importancia adecuada y luego pasa lo que pasa.

  • Se puede llegar a estar hasta varios días sin poder realizar el build del proyecto.
  • Los errores y problemas se detectan demasiado tarde, lo que multiplica exponencialmente el coste de su solución.
  • Las modificaciones y correcciones no producen más que nuevos errores que, como indico en el punto anterior, se detectan tarde.
  • Los programadores tardan horas en desarrollar sus tareas por trabajar en un entorno poco optimizado.
  • Los programadores se desmotivan, se van del proyecto, con la perdida de conocimiento que ello implica en algunos casos.
  • Se pierde una cantidad enorme de horas en procesos manuales facilemente automatizables.
  • Se produce un “proceso de involución en el proyecto” en el que parece que este empeora en lugar de mejorar. Digo “parece” porque realmente no solemos tener herramientas fiables y “sinceras” que nos proporcionen la situación del proyecto. He puesto la palabra “sincera” a propósito, porque en la mayor parte de las ocasiones, quien proporciona esta información es una persona que miente descaradamente.
  • El proyecto se llenan de auditores y “tecnocratas” que con sus Word, Excel y Projects intentan solucionarlo. Y entonces se pieder el norte, ya no se sabe si el objetivo es el proyecto, o todos los informes que debes pasar a estas personas… que cuestan un montón de horas y dinero.
  • Etc, etc, etc…

Y si,  estoy convencido que muchos de estos problemas se podrían evitar si se decidises invertir tiempo en estos temas:

Ecosistema de software

 Un ecosistema de desarrollo software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

Integración continua

La integración continua es una práctica en el desarrollo de software que consiste en poner en común todos los cambios que afecten al resultado final de nuestro proyecto de una forma frecuente con el objetivo de ver la evolución de sus efectos.

Automatización

Y en la automatización  de estas 5 líneas que se suelen recomendar para conseguir un nivel óptimo de madurez en el desarrollo de software:

  • Build (compilación, empaquetado y distribuibles)
  • Automatic Documentation Generation
  • Testing
  • Continuous Inspection
  • Continuous Deployment

De todo esto es de lo que nos habla Manuel Jesús Recena Soto en esta estupenda presentación que realizo el pasado 14 de Febrero como ponente invitado al Máster de Ingeniería y Tecnologías Informáticas que se imparte en la Universidad de Sevilla.

Ecosistemas de desarrollo de software: lineas de automatización.

22 pequeñas reflexiones sobre la gestión y el desarrollo de proyectos

22 “pequeñas” reflexiones sobre la gestión y el desarrollo de proyectos.

  • La calidad es el aliado de la planificación, no su adversario. Si sacrificamos la calidad por la planificación lo estamos haciendo mal
  • “El software y las catedrales son muy similares. Primeros los construimos, después rezamos”, Sam Redwine.
  • No existe calidad del software sin satisfacción del usuario.
  • “Los buenos programadores utilizan sus cerebros, sin embargo las buenas prácticas nos permite no tener que pensar en todos los casos”.
  • La documentación se convierte en un problema cuando se convierte en un factor externo al desarrollo, como si fuera un elemento independiente.
  • Testing, ¿hasta donde?. Es difícil definir cual. obj. en este proceso sin llegar a la elim. de todos los err, algo que resulta imposible
  • Testing, ¿hasta donde?. No existe relación entre el tamaño del error y los problemas que causa.
  • Testing, ¿hasta donde?. Cohete de 18 mill. de dolares había sido destruido en vuelo debido a un simple guión que faltaba en un programa.
  • Los departamentos de calidad del software requieren una comunicación continua y fluida con los departamentos de desarrollo.
  • La documentación debe acompañar el desarrollo de software, ser parte de él. Debe servir al proyecto y no ser un obstáculo en el mismo.
  • No hay nada que justifique que el software se tenga que ir deteriorando conforme se van realizando tareas de mantenimiento con el mismo.
  • “Un programador trabaja para un resultado libre de errores; un tester, para encontrarlos”, Moses Oliver,
  • “La estructura de un sistema software refleja la estructura de comunicación del equipo que lo ha desarrollado”, Richard E. Fairley.
  • Cometer errores en el desarrollo de software es algo natural. Lo importante no es no equivocarse sino detectar los errores a tiempo.
  • “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”, Mike Johnson,
  • La detección de errores, lo más próxima posible a su origen, ahorra dinero.
  • Un programa que no funciona es incorrecto; pero un programa que funciona no es necesariamente correcto: difícil de mantener, entender ..
  • El origen de la sabiduría de un desarrollador se basa en conocer la diferencia entre un programa que funciona y un programa correcto,
  • Uno de los principales problemas con que se encuentran los equipos de testing es que se consideran obstáculos,
  • Los testers son desarrolladores de software, son una pieza más dentro del equipo, hacen otro tipo de trabajo, pero de gran importancia.
  • “El código no existe hasta que se sube a un repositorio de fuente”, Jeff Atwood
  • Escribid el código para que os entiendan otras personas, no sólo para que os entienda la máquina.
Y mucho más en: http://jummp.wordpress.com/
22 pequeñas reflexiones sobre la gestión y el desarrollo de proyectos