Alguna reflexión sobre el conocimiento en ingeniería del software y una lista de malos olores

Después de los post “Duplicar, o copy pegar, código no es una buena idea” y “Un case o switch con muchas clausulas, o muchos ifs anidados, tampoco es una buena idea” llegaron algunos correos preguntando dónde se puede encontrar una lista completa de problemas de este tipo. Y he de decir que la respuesta no es fácil. Porque aunque en ingeniería del software hemos avanzado mucho en los últimos años y hemos ido documentando nuestro conocimiento y buenas prácticas a la hora de construir sistemas… aun nos queda mucho por hacer en este sentido.
La iniciativa más destacada a la hora de catalogar el conocimiento en ingeniería del software  es de los 90, cuando se publicó el primer catálogo de patrones de diseño software. Pero existe mucho más conocimiento aparte de estos patrones, y aquí viene el problema, que ese otro conocimiento está poco clasificado, recibe terminología heterogénea, etc., y es costoso de encontrar. Si, por ejemplo, nos ponemos a buscar elementos que pudieran contener conocimiento o buenas prácticas de diseño software, aparte del que describen los patrones, entraremos en un “caos” y encontraremos cosas como principios, heurísticas, lecciones aprendidas,  defectos, prácticas, experiencias, malos olores (bad smells), refactorizaciones, anti-patrones, patrones, etc.
Pero, no obstante, y para no dejar el post sin alguna buena respuesta, os dejo una relación de algunas “cosas” que no se deberían hacer a la hora de diseñar o programar un sistema software. Los siguientes son un extracto de uno de los catálogos más interesantes sobre buenas prácticas a nivel de diseño software y que los autores llamaron “malos olores” o cosas que viéndolas me pueden hacer pensar que algo va mal:

• Método Largo. Los programas que viven más y mejor son aquellos con métodos cortos, que son más reutilizables y aportan mayor semántica.
• Clase Grande. Clases que hacen demasiado y por lo general con una baja cohesión, siendo muy vulnerables al cambio.
• Lista de Parámetros larga. Los métodos con muchos parámetros elevan el acoplamiento, son difíciles de comprender y cambian con frecuencia.
• Obsesión Primitiva. Uso excesivo de tipos primitivos. Existen grupos de tipos primitivos (enteros, caracteres, reales, etc.) que deberían modelarse como objetos. Debe eliminarse la reticencia a usar pequeños objetos para pequeñas tareas, como dinero, rangos o números de teléfono que debieran muchas veces ser objetos.
• Clase de Datos. Clases que sólo tienen atributos y métodos tipo “get” y “set”. Las clases siempre deben disponer de algún comportamiento no trivial.
• Estructuras de agrupación condicional. Lo que comentamos en un case o switch con muchas clausulas, o muchos ifs anidados, tampoco es una buena idea
• Comentarios. No son estrictamente “malos olores”, más bien “desodorantes”. Al encontrar un gran comentario se debería reflexionar sobre el porqué algo necesita ser tan explicado y no es auto explicativo. Los comentarios ocultan muchas veces a otro mal olor.
• Atributo Temporal. Algunos objetos tienen atributos que se usan sólo en ciertas circunstancias. Tal código es difícil de comprender ya que lo esperado es que un objeto use todas sus variables.
• Generalidad Especulativa. Jerarquías con clases sin utilidad actual pero que se introducen por si en un futuro fuesen necesarias. El resultado es jerarquías difíciles de mantener y comprender, con clases que pudieran no ser nunca de utilidad.
• Jerarquías Paralelas. Cada vez que se añade una subclase a una jerarquía hay que añadir otra nueva clase en otra jerarquía distinta.
• Intermediario. Clases cuyo único trabajo es la delegación y ser intermediarias.
• Legado rechazado. Subclases que usan sólo un poco de lo que sus padres les dan. Si las clases hijas no necesitan lo que heredan generalmente la herencia está mal aplicada.
• Intimidad Inadecuada. Clases que tratan con la parte privada de otras. Se debe restringir el acceso al conocimiento interno de una clase.
• Cadena de Mensajes. Un cliente pide algo a un objeto que a su vez lo pide a otro y este a otro, etc.
• Clase Perezosa. Una clase que no está haciendo nada o casi nada debería eliminarse.
• Cambios en Cadena. Un cambio en una clase implica cambiar otras muchas. En estas circunstancias es muy difícil afrontar un proceso de cambio.
• Envidia de Características. Un método que utiliza más cantidad de cosas de otro objeto que de sí mismo.
• Duplicación de Código. Lo que contamos en duplicar, o copy pegar, código no es una buena idea
• Grupos de Datos. Manojos de datos que se arrastran juntos (se ven juntos en los atributos de clases, en parámetros, etc.) debieran situarse en una clase. Beneficios inmediatos son la reducción de las listas de parámetros y de llamadas a métodos.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023