El crear software, a mi muy humilde opinión, más que una profesión o un burdo oficio (para muchos), es un arte que requiere de toda la creatividad, dedicación y pasión necesarias ya que no es solo cuestión de cumplir con n requerimientos y que el programa “corra”, realmente hacer un buen programa requiere de un proceso mucho más complejo y parte de este complejo proceso es escribir código de calidad, pero ¿qué implica esto?
La calidad es un concepto tan abstracto que fue necesario crear una lista interminable de reglas y normas para poder “alcanzarla” pero todos sabemos que eso no es suficiente siempre existe una falla y la calidad se pierde un poco. En software es evidente que no es la excepción y averiguando un poco descubrí que en la programación orientada a objetos un par de muchachos: Kent Berck y Martin Fowler definieron un concepto muy ilustrativo para detectar problemas dentro del código: bad smells in code o malos olores en el código.
Este concepto se refiere a detectar algunos problemas como: tener muchos parámetros dentro de un método, o tener clases muy largas con muchas responsabilidades, o clases que dependen mucho una de la otra y así una lista un poco extensa de los muchos problemas que pueden encontrarse dentro del código de cualquier programador, por muy experto que este sea.
Pero y ¿esto de qué nos sirve? Pues la respuesta más inmediata es: estos “olores” nos ayudan a detectar errores de forma (estilo o modo de escribir el código) en nuestras líneas de código y nos permiten optimizarlas para realmente tener un programa con cierta calidad.
Y ¿qué “olores“ se pueden encontrar? A continuación listaré una serie de “malos olores” y a qué se refiere cada uno.
| Nombre | ¿A qué se refiere? |
|---|---|
| Comentarios | Se tiene un exceso de comentarios dentro del código. Los comentarios existentes contestan más a la pregunta ¿por qué lo hace? que la pregunta ¿qué hace? |
| Método largo | Se tiene un método demasiado largo. Los método cortos son más fáciles de entender, de leer y de mantener. |
| Lista de parámetros muy larga | Entre mayor sea el número de parámetros, mayor será la complejidad del método. |
| Código duplicado | El código duplicado es la ruina del desarrollo de software. Hay que evitar esto a toda costa. |
| Explosión combinatoria | Se tienen métodos que hacen casi lo mismo pero, el comportamiento de la información varía poco. |
| Clases largas | Tal como los métodos muy largos, las clases muy largas son muy difíciles de mantener, de entender y de leer. |
| Tipo dentro del nombre | Se tienen tipos de datos en los nombres de los métodos. Esto no sólo es redundante sino que obliga a cambiar el nombre del método si el tipo cambia. |
| Nombre poco comunicativo. | ¿El nombre del método describe lo que este hace? |
| Nombres inconsistentes | Si ya se ha elegido un estándar para asignar métodos, es necesario que este estándar se siga. |
| Código muerto | Se tiene código que no se usa. |
| Especulación general | Se tiene código que “resuelve” problemas del futuro pero no los presentes. |
| Solución excéntrica | Se tienen varias soluciones para un mismo problema. |
| Campo temporal | Se tiene un objeto con muchos campos innecesarios. |
Bueno, lo más interesante de esto ¿cómo arreglar estos problemas? Pues para esto se usa una técnica llamada “refactorización” pero, este tema es un poco extenso así que lo dejaré para el próximo número. Espero que estos problemas sean mínimos en nuestros códigos.
1 Comments.