pragmatic programmer

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?

jbravomontero, , , , , , , , , , , , , 2 comentarios

En genbeta:dev han lanzado hace un día esta pregunta:

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?

Esta ha sido mi respuesta. Reconozco que me he dejado llevar y al final he hablado un poco de todo. En cualquier caso esta es la respuesta, desordenada y escrita en 5 minutos, pero creo que puede ser útil.

1.-En primer lugar Eclipse bien configurado.

Como por ejemplo nos indica aquí Sanjeev Kumar.

https://sites.google.com/a/javagyan.com/javagyan/useful-tips/usingeclipseeffectively

Esto lo podemos acompañar del algún plugin que nos mire las métricas mientras desarrollamos tipo: CodePro AnalytiX

https://developers.google.com/java-dev-tools/download-codepro

Y terminaría la configuración del eclipse con un conjunto de templates que me faciliten la escritura de cierto tipo de estructuras habituales:

http://eclipse.dzone.com/news/effective-eclipse-custom-templ

2.-Un buen entorno de integración e inspección continua con Jenkins y Sonar.

http://jenkins-ci.org/
http://www.sonarsource.org/

https://jbravomontero.wordpress.com/2012/02/18/ecosistemas-de-desarrollo-de-software-lineas-de-automatizacion/

Y el Sonar enriquecido con los siguientes plugins:

  • Timeline Plugin
  • Useless Code Plugin
  • SIG Maintainability Model Plugin
  • Quality Index Plugin
  • Technical Debt Plugin

http://onlysoftware.wordpress.com/2012/01/01/51-sonar-plugins-you-must-not-miss-2012-version/

Aunque para gestionar la deuda técnica también este estupendo plugin COMERCIAL 😦 que ayuda con la implementación de SQALE)

http://www.sonarsource.com/products/plugins/governance/sqale/

3.- Fomentar de «buen rollo» (no se puede ir diciendo este código es una mierda) entre los miembros del equipo las buenas prácticas.

Recomendando las lecturas de ciertos libros imprescindibles.

Y reuniendonos de vez en cuando para analizar ciertas partes del código en equipo.
Reflejar esta información y las conclusiones en un Wiki.

Fomentar cuando sea necesario:

  • La programación por pares.
  • Y siempre, siempre la revisión por pares. No dar por bueno un código hasta que otra persona no lo ha verificado en su máquina.

4.- Un buen conjunto de test que nos quite el miedo a la refactorización cuando sea necesario.

Técnicas TDD, etc.

5.- Y dejar claro cosas como:

  • Las prisas no justifican un mal código.
  • Poco a poco, la deuda técnica se acumula en las zonas que ya estaban llenos de deuda.
  • La programación puede ser divertida, también lo puede ser la criptografía, sin embargo es recomendable no combinarla.
  • «¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!».
  • Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives (Martin Golding).
  • etc

Y muchas cosas más…………….

Evidentemente he sido incapaz en los proyectos que he estado de implementar todas estas técnicas o teorías.. pero creo que el concepto esta claro y se podría resumir en estos puntos:

  • Formación continua entre los miembros del equipo.
  • Fomentar la premisa de buscar la excelencia en el código trabajando en equipo.
  • No esconder la información y fomentar el compartirla.
  • Fomentar un buen entorno de trabajo: Gamification (http://vimeo.com/32435331)
  • Y automatizar la generación e inspección del código.

Un saludo.

¿Qué herramientas utilizáis para controlar la calidad de vuestro código?