Principios de mal diseño

•

¿Qué es el buen diseño de software? Es una de esas preguntas para las que es difícil encontrar una respuesta convincente. Muchas veces no entendemos lo que es el buen diseño hasta que lo vemos. Si es que lo vemos, porque el buen diseño tiende a parecer obvio.

Y al parecer obvio es como si no requiriese un esfuerzo. Todas las piezas encajan. Es aprehensible. Es intuitivo. Pero el buen diseño suele ser fruto de mucho trabajo y mucha reflexión. Puede ser muy complicado explicar cómo diseñar bien por lo que a veces tenemos que centrarnos

en lo opuesto. O sea, en cómo diseñar mal y evitarlo. Parafraseando algo que leí alguna vez sobre cine: podemos discutir mucho sobre lo que hace buena a una película, pero hay mucho acuerdo en aquello que la hace mala. En software es algo parecido, es fácil ver lo que está mal.

Veamos algunos anti-principios (que me he sacado de la manga)

Anti-principio de inutilidad. El software no hace lo que se espera de él, no responde a las necesidades de las usuarias o lo hace de tal manera que es preferible no usarlo. Tenemos unos cuantos ejemplos en administraciones públicas.

Anti-principio de defectuosidad. El software puede ser útil, pero está plagado de defectos. No es confiable. A veces funciona, a veces no. Depende de condiciones que no podemos controlar (alto acoplamiento, dependencias técnicas, etc.)

Anti-principio de no reutilización. Los módulos de código no se pueden reutilizar. De nuevo, el acoplamiento es tan alto que es muy costoso reutilizarlo, lo que lleva a duplicaciones de conocimiento y resultados incongruentes según cómo lo utilices.

Anti-principio de desorganización. El código es una gran bola de lodo en el que es muy difícil encontrar algo, lo que favorece que sea más barato añadir más lodo en forma de módulos que duplican funcionalidad porque no podemos reutilizar lo existente.

Anti-principio de no testeabilidad. El código no es testeable. Por su falta de organización, modularización inadecuada o inexistente, el código es muy difícil de poner bajo test. Incluso podría ser imposible.

Anti-principio de ilegibilidad. El código por sí mismo no sirve para entender el conocimiento que representa. Es necesario disponer de documentación extensiva que lo explique, existiendo el riesgo de que esta documentación haya perdido la sincronía con el código.

Anti-principio de insostenibilidad. Modificar el código es una operación que entraña riesgos, porque no es posible garantizar que no generará efectos negativos en otras partes del sistema que no podemos predecir.

Probablemente haya alguno más, pero es algo por donde empezar.