Seguro que habéis escuchado en varias ocasiones la famosa frase “lo importante es que funcione”, pero, ¿por qué esto no es suficiente? Antes de contestar a esta pregunta vamos a exponer qué es un código limpio para poder llegar a conclusiones.

Un código limpio…
• es fácil de entender
• es fácil de modificar
• es fácil de testear
• funciona correctamente

Entonces, ¿por qué no basta con que funcione? Fácil, el trabajo no está completo si el código funciona, pero no es fácil de mantener, fácil de modificar y fácil de testear. Como ya habréis concluido, la manera de hacer el trabajo completo es mediante el código limpio.

Este artículo expone una selección de las reglas, metodologías, consejos o aspectos de diseño sobre este tema que consideramos importantes. Lo primero que hay que tener claro es que “clean code” (concepto propuesto por Bob Martin) es completamente objetivo, no es una cuestión artística o subjetiva. Otra cosa importante es la refactorización, nadie escribe el mejor código a la primera (como anécdota: el propio Bob Martin refactoriza código de Ken Beck en uno de sus libros).

Nombres significativos en variables y métodos

Esto es básico para entender el código. Cuanto más descriptivos sean los nombres de variables y métodos, mejor. Hoy en día, con las herramientas de los IDEs, no es ningún problema tener nombres de una gran longitud o cambiarlos en medio del desarrollo. También es muy importante que los nombres de los métodos reflejen todo lo que hacen. Los nombres que revelan la intención aclaran efectos colaterales y facilitan el mantenimiento.

Veamos por ejemplo este código, en el que los nombres de variables o métodos están ofuscados y no representan lo que hacen. El nombre del método tampoco revela la intención de almacenar cacheado el precio total para no recalcularlo en consecutivas llamadas… ¿y si se añade un nuevo descuento y el desarrollador que usa el método no es consciente que el precio total está almacenado?

 

Solucionar esto es sencillo, basta con poner nombres aclarativos a las variables y métodos. Además, extenderemos el nombre del método para que revele la intención de cachear el resultado y así solucionar posibles futuros problemas. Queda un código como el de a continuación, mucho más fácil de entender y, por tanto, de mantener.

 

 

Evita los comentarios

Está muy relacionado con el apartado anterior. Utiliza buenas descripciones en los nombres de las variables y métodos en lugar de comentarios que clarifiquen lo que son/hacen. Esto no quiere decir que se deje de comentar siempre que sea necesario, sino que hay que intentar describir el código con el propio código y no con comentarios.

Patrones de diseño

Los patrones de diseños son técnicas contrastadas para resolver problemas de diseño. El uso de estos patrones es altamente recomendable ya que, además de estar muy probados como soluciones eficaces, los desarrolladores pueden identificarlos con facilidad y así entender la naturaleza del problema y el contexto del mismo. Además de lo anterior, los patrones son muy eficaces para hacer el código fácilmente modificable y testeable.
Existen 3 tipos de patrones de diseño: patrones creacionales, patrones estructurales y patrones de comportamiento.

Principio abierto/cerrado

El acrónimo SOLID pertenece a principios de diseño para programación orientada a objetos. La O de este acrónimo, open/closed (abierto/cerrado), nos dice que una entidad clase, módulo o función debe estar abierta a la extensión, pero cerrada a la modificación. Es decir, una clase debe permitir la extensión de su comportamiento sin tener que modificar su código fuente.

Query en lugar de comandos

Definamos primero que es una función “Query” y qué es una función “Comando” para poder interpretar esto. Una función que no modifica el estado del objeto instanciado y se limita a devolver ciertos datos haciendo cualesquiera que sean las operaciones necesarias, es una función o método query. Por otro lado, tenemos los comandos, funciones que modifican el estado del objeto instanciado o de objetos instanciados dentro de sus atributos.

 

 

Lo malo de usar “comandos” es que tienen “efectos colaterales”, más aún si se utilizan comandos que usan comandos, que usan comandos… Siendo este un escenario más común de lo que pensamos inicialmente. Por tanto, siempre que sea posible, es preferible utilizar funciones query libres de “efectos colaterales” que pueden ser indeseados. Además, las funciones query son mucho más fáciles de testear.

La lógica, en el lugar adecuado: evitar lógica en SQL

En muchas ocasiones nos encontramos repositorios con sentencias SQL que ocupan varias líneas, haciendo JOIN de varias tablas y manipulando resultados dentro de la misma. Esto puede ser resultado de dos cosas: un mal modelo de datos o un intento por reducir el número de llamadas a bases de datos. En el caso de lo primero, la solución es obvia, hay que tratar de modificar el modelo de datos. En el caso de lo segundo, es posible que el problema sea peor de lo que pensamos… ¿realmente se necesitan una cantidad ingente de llamadas a base de datos? Puede que el diseño de nuestra solución no sea el óptimo. Si no existe un problema de la cantidad de llamadas a base de datos, sino que es una decisión de diseño… ¡No ocultes la lógica en la sentencia SQL! Es difícil de entender, cambiar, mantener y testear.
________________________________________

Y tú, ¿qué reglas o metodologías consideras importantes para mantener el código limpio?







¿Te gustaría recibir nuestros próximos artículos?