Hace poco escuché a un desconocido decir algo como - Lo importante es que el código funcione correctamente no si se lee mejor o peor - no dudo ni por un minuto, que es mejor un código mal hecho que funcione, a un código perfectamente legible que no funciona. Dándole un par de vueltas y teniendo en cuenta que yo no había escuchado el resto de la conversación, imagino que lo que quería decir esa persona es que si el código mal hecho pero que funciona se puede hacer en 30 minutos en vez de en 60 es mejor, pero ahí si que discrepo totalmente.

Cuando estaba en la universidad, esa máxima era cierta, lo importante era tener la práctica terminada y funcionando (total, una vez corregida nadie la volvía a mirar). Pero cuando empecé a trabajar me dí cuenta de algo muy duro - algo me había comentado algún profesor pero de manera un poco abstracta y sin mucho detalle - ¡el software hay que mantenerlo!, ¿cómo?, a mi nadie me había enseñado eso, en que clase dieron esa parte?!?!?!

Pues sí, esa es la dura realidad, el software tiene un mantenimiento, y puede ser realmente caro si no se hacen las cosas correctamente desde el principio. Ese programador que tarda 30 minutos en hacer una funcionalidad X, dentro de 3 meses puede que tarde 5 horas en descubrir cual es el error de la aplicación simplemente porque no entendía su propio código (cuando es el suyo, porque si es de otra persona puede tardar 15 horas). Pero el programador que tardó 60 minutos, porque quería tener un código legible y usar patrones para que el código fuese más limpio, puede que tan solo tarde 1 hora en resolver el problema.

Aunque estas cifras no son científicas, creo que están muy próximas a lo que puede ocurrir en el mundo real, o simplemente a mi propia experiencia :) Con lo cual tenemos, que el programador tardó el doble en programar el método (lo que hace un total de 30 minutos de perdida), pero realizó la corrección del error 5 veces más rápido (lo que hace que gane 4 horas). Es pura lógica, yo prefiero ganar esas 4 horas!!!

Nota: Para todos aquellos que no realizan el mantenimiento de su propio código (y para que quede constancia, en general yo me encuentro en ese caso actualmente), estos consejos son igual de válidos. Si el código se mantiene facilmente, el cliente estará más contento y más contratos tendremos, además le haremos la vida más feliz a nuestros compañeros si son ellos los que mantienen el código, haciendo que nuestra empresa sea un sitio mejor. Y si lo mantiene otra empresa simplemente le harás la vida más feliz a otra persona que hará dicho trabajo, lo cual te hará mejor persona o mejorará tu karma, o cualquier otra explicación que te guste :)

El año pasado llegó a mis manos casi por casualidad un libro titulado "The Thoughtwors Antology". Mirandolo por encima, uno de sus capítulos, escrito por Jeff Bay, me llamó la atención porque daba una serie de reglas para mejorar la calidad de nuestro código orientado a objetos en muy pocas páginas. A mi me gustaría comentar algunas de estas reglas en mi blog porque considero que son bastante útiles.

Esto no quiere decir que podamos evitar la lectura de libros (de gran calidad) dedicados al tema como puede ser "Clean code", pero nos permite tener una visión general para todos aquellos que no seamos expertos en la programación orientada a objetos.

Un nivel de indentación por método.

Dicho así de rápido y fuera de contexto puede resultar una regla un poco dura, pero en realidad hace referencia a la necesidad de tener métodos cohesivos y que realicen una única tarea. Una de las mejores métricas que he conocido en mi breve vida de desarrollador de software es esta, porque cuando un mismo método tiene más de dos niveles de anidamiento es que está haciendo algo más de lo que debería (esto no quiere decir que se cumpla en el 100% de las veces).

No hacer uso de la palabra reservada "else".

En mi experiencia de estudiante lo más importante de las prácticas es que funcionen, siempre tiene algo de importancia la calidad del código pero no se mira con mucho detalle (dependerá de la asignatura y el profesor). Pero cuando empiezas a trabajar, muchas empresas también buscan que el código sea sencillo y se entienda en una sola pasada, principalmente porque en el código trabaja más gente a parte de tí. Los bloques condicionales son una de las estructuras que más oscurecen el código fuente, por lo que es necesario simplificarlos lo mejor posible.

Pongamos el ejemplo siguiente.

public void deleteDocument(String docId) {
   Document document = getDocument(docId);
   if (document != null)
      database.delete(document);
   else
      throw new BlackboardException(...);
}

Utilizando esta regla podemos refactorizar al siguiente bloque, que en general resultará más sencillo de leer y por lo tanto de saber cual es su función (aunque el propio nombre del método debería aclararlo).

public void deleteDocument(String docId) {
   Document document = getDocument(docId);
   if (document == null)
      throw new BlackboardException(...);

   database.delete(document);
}

Hay algunos autores que incluso recomiendan evitar el uso de los bloques condicionales, haciendo uso de las propiedades de los objetos. Intenta hacer algunos ejercicios verás como la calidad de tú código mejora drásticamente.

Envolver todas las primitivas y strings.

Esta, en mi opinión, es una regla un poco controvertida, pero es igual de cierto que es una práctica común en Domain-Driven Design (DDD) porque hace los conceptos explícitos. Hay casos en los que el uso de primitivas se entiende perfectamente bien, pero hay casos en los que el uso de objetos valor (objetos que envuelven a la primitiva, en general extendiendola) puede aclarar el modelo de dominio y además hacer que el modelo se pueda evolucionar más facilmente en el futuro.

Utilizar un solo punto (.) por línea.

Aunque lo intento evitar en la medida de lo posible, es muy normal encontrar en muchos lugares de mi código cosas como ...

...
comprobarCodigoPostal(persona.getDireccion().getCodigoPostal());
...

Para mucha gente será obvio que no se está haciendo uso de forma correcta de la abstracción de los objetos. Sería más lógico y mucho más claro tener algo como ...

...
comprobarDireccion(persona.getDireccion());
...
comprobarCodigoPostal(direccion.getCodigoPostal());
...

Quizás el ejemplo no es el más claro del mundo, pero espero que se aprecie que evitando la utilización de más de una referencia por línea, el código es mucho más sencillo y manejable, además de representar su funcionalidad a primera vista.

No usar abreviaciones.

Robert C. Martin escribe en su libro que hay que llamar a las cosas por su nombre, y esto es básicamente lo que quiere decir esta regla.

Revisando mis prácticas de Universidad he observado la tendencia a abreviar todos los nombres de instancias o de métodos, en parte adoptado de un modelo de programación más funcional. Lo que ocurre es que cuando miro dichas prácticas unos años más tarde, ya no se lo que siginifican algunas variables llamadas t o x porque ya no tengo en la cabeza el modelo que estaba tratando en ese momento, pero aún puede resultar peor para una persona que jamas haya trabajado en el dominio del problema que estaba resolviendo.

Mantener las clases lo más pequeñas posible.

En esta regla Jeff Bay indica que las clases no deben tener más de 50 líneas de código y los paquetes no deben tener más de 10 ficheros. No creo que sea un regla que haya que seguir al pie de la letra, supongo que una clase puede tener 60 líneas sin que signifique que no es cohesiva. Pero es bueno que la usemos para preguntarnos si estamos siguiendo el camino correcto, porque una clase cohesiva se limita a una sola cosa y por lo tanto no debería necesitar una gran cantidad de líneas de código para realizar dicha cosa.

Nota: Todas estas reglas pueden ser aplicadas en gran cantidad de ocasiones, pero hay que tener claro que habrá momentos en los que no nos conviene o simplemente no podemos hacerlo porque el problema es demasiado complejo, por ejemplo.

Hace unos días Carlos Blé ha publicado su libro, "Diseño ágil con TDD", posiblemente el primer libro en castellano de esta temática. Se puede descargar de forma gratuita desde la web del libro.

He tenido el placer de colaborar con él como revisor, por lo que he leido las versiones previas del libro unas cuantas veces, aunque sea por encima, y he aprendido muchísimo. Creo que habrá mucha gente a la que este libro le puede servir de ayuda y le puede ayudar a entrar en el mundo del desarrollo ágil de software.

Solo me queda felicitar a Carlos y al resto de coautores (he trabajado con dos de ellos personalmente, Gregorio Mena y Fran Reyes, y puedo asegurar sin lugar a equivocación que son dos grandes profesionales) por el trabajo realizado, esperando que en el futuro se produzcan más iniciativas como esta.