Hacer un buen diseño no es trivial, más aún: tampoco es trivial decir si un diseño es bueno. ¿Qué es un buen diseño? Alguien podría decir que un buen diseño es un diseño «escalable», pero que pasa si la escalabilidad no es uno de lo requisitos del problema. Creo que muchas veces se persiguen propiedades sin considerar las necesidades. En este sentido creo que una primera propiedad de un buen diseño es que resuelva el problema en cuestión.En línea con esto podríamos decir que un «mal diseño» es uno que no resuelve el problema en cuestión.

Mmmm, esto tampoco cierra. «Diseño bueno» o «diseño malo», no creo que sea una cuestión tan binaria: «bueno o malo». Pero si creo que la evaluación del diseño debe ser en función del problema que queremos resolver. Intento resaltar esto con un ejemplo concreto: puedo hacer un diseño super purista, que cumple con N propiedades, pero luego resulta no factible de ser implementado :-(. Entonces un diseño que no se implementa ya perdió. Nota al margen: creo que esto refleja la diferencia entre «la ciencia teórica» y la ingeniería.

Típicamente los problemas que tenemos que resolver tienen múltiples dimensiones representadas por: a) funcionalidades, el qué, lo que software debe hacer y 2) propiedades, atributos de calidad, el cómo, que influyen en el cómo resolvemos el problema, o sea: lo revolvemos de una forma que resulta mantenible, extensible, performante, etc, etc. A partir de esto creo que no es conveniente una evaluación «binaria» (bueno/malo), sino es que es mejor hablar en un continuo, una gama de grises entre el bueno y el malo.

Es en este grupo de propiedades que definen la solución hay una que destaca por ser de presencia «universal», o sea, que en general es requerida en toda solución: la mantenibilidad. Raro son los casos en los que resolvemos una problema de una y nunca más tenemos que tocar su código. En general nos aproximamos a la solución en forma iterativa y eso no lleva a volver una y otra vez sobre el código previamente escrito. Es ahí donde la mantenibilidad tiene un impacto decisivo en el costo (y los riesgos) de trabajar sobre código previamente escrito. Desde mi perspectiva la mantenibilidad implica: que el código sea legible, fácil de entender, que sea testeable (y que tenga pruebas), que revele su intención, que esté documentado, etc, etc.

Aquí es donde entra mi idea de «diseño decente», es un diseño que puede tener algunos puntos flojos pero que resuelve la dimensión funcional del problema y respeta ciertas premisas de mantenibilidad y testeabilidad de forma tal que nos lleva a generar una implementación que concretamente:

1. Respeta las convenciones del lenguaje de programación (fácilmente verificable con un linter)
   
2. Mantiene una clara separación entre el código de la lógica «de negocio» y el código de entrada/salida (infraestructura)
   
3. Tiene pruebas automatizadas

Traigo esta idea de «diseño decente» porque es justamente lo que intento enseñar a mis alumnos.