Antipatrones de diseño

Artículo perteneciente a la sección de calidad de código

Hola a todos,

En el capítulo anterior hablamos de los antipatrones de diseño como un tipo de "olor del código",  pero.. que es un antipatrón de diseño??

De la misma manera que un patrón de diseño es una herramienta que usada con moderación y cautela puede disminuir la complejidad del código, el antipatrón de diseño es una manera de diseñar, enfocar el desarrollo y/o implementar el código que conduce con bastante seguridad al desastre.

Lo peor de los antipatrones es que en muchas ocasiones los tenemos tan incrustados en nuestra manera de trabajar que hasta que no nos hacen ver que ahí tenemos un problema no podemos reaccionar.

La lista de antipatrones es larga y abarca numerosos ámbitos del desarrollo del software , así que solo pondré los más representativos para que os hagáis una idea de como va el tema. Además de esto, cada antipatrón tiene un nombre "divertido" para facilitar su aprendizaje ("Pollo sin cabeza" , "Gran bola de lodo" son solo dos ejemplos :) ), yo me abstengo a poner esos nombres, en primer lugar por que al provenir del inglés las traducciones y matices son múltiples y en segundo lugar por que os confundiría más que ayudaría. Recordemos que esto solo es un pequeño tutorial para saber de que va el tema de los antipatrones. Aquí os dejo la lista resumida de antipatrones:

- Antipatrones de gestión: 
      - Buscar la productividad a toca costa, olvidando la calidad del código o la calidad de vida de los trabajadores
       - Responsable que no da la talla: o nunca está localizable, o no gestiona bien, o no da la cara por sus trabajadores o no es justo en el trato a los miembros del equipo,etc...
       -  Trabajadores con demasiada diferencia de nivel, hacen que al final todas las responsabilidades vayan a parar a la misma persona.

- Antipatrones del diseño de software:
        - Concentrar demasiadas responsabilidades en un solo módulo
        - No determinar correctamente las decisiones complejas del proyecto
        - Diseñar un sistema sin una estructura clara
        - Diseñar de una manera extremadamente compleja.

- Antipatrones de programación:
         - No utilizar una nomenclatura clara y veraz
         - Programar con más complejidad de la necesaria para resolver el problema
         - Programar sistemas con una estructura poco clara y enrevesada.
         - Usar hardcodeos sin ninguna explicación de donde vienen.
         - Ocultar errores y parchearlos en vez de solucionarlos realmente.

Hay muchísimos más, si os interesa el tema googlead y encontrareis cientos de ellos.

Si os da pereza googlear o directamente queréis ir a fuentes más serias podéis mirar los siguientes libros especializados en antipatrones del software:


Espero que os haya servido para entender un poco más sobre calidad de código.

Nos vemos

Code Smell: ¿ A que huele el código ?

Artículo perteneciente a la sección de calidad de código

Hola a todos,

En muchas ocasiones no tenemos tiempo para revisar a conciencia el código de otras personas, pero paradójicamente, a medida que vamos ganando experiencia todos los programadores obtenemos un cierto sexto sentido para detectar código que da "mala espina". No se puede explicar y como mucho se puede decir que la nomenclatura de las variables no es demasiado correcta, o que el código está estructurado "raro", o que cuesta de entender... es difícil argumentar esa sensación.

En los 90 Kent Beck (uno de los grandes investigadores de la calidad de código) acuñó el término de Code Smell (Mal olor del código) y propuso una lista básica de factores(que ha sido revisada y ampliada por cientos de personas) que hacen inclinarnos a pensar que el código no está bien del todo:
   - Código duplicado.
   - Código muerto.
   - Funciones grandes.
   - Demasiados parámetros.
   - Uso forzado de patrones de diseño.
   - Nombres de variables y funciones demasiado largos.
   - Nombre de variables y funciones demasiado cortos.
   - Nombres de variables y funciones que no explican lo que realmente hacen.
   - Uso excesivo de hardcodeos (datos que podrían estar en ficheros de configuración en vez de dentro el código)
   - Sentencias switch en exceso.(en lenguajes orientados a objetos, implica un mal diseño de herencia)
   - Excesivos comentarios.
   - Bloques de If's excesivamente grandes
   - Demasiado código preparado "porsiacaso" (cuando no se sabe nunca de lo que realmente pasará en el futuro)
   - Uso excesivo de tipos primitivos
   - Las funciones deberían tener solo una responsabilidad.
   - Encadenamiento excesivo (cuando se tiene una función que solo llama a otra, que llama a otra, que llama a otra.....)
    - Detección de un antipatrón de diseño (ya lo explicaremos con más calma en otro artículo)

El hecho que en el código que revisamos veamos alguna de estas características no significa que haya algo necesariamente mal, pero da bastantes indicios de que seguramente habrá problemas y será una zona de código que se deberá revisar con más detenimiento.

Espero que os haya gustado

Ya como nota final, os comento que el término Code Smell surgió en este libro, por si os interesa:


Nos vemos