Si programamos como si estuviéramos creando una teoría llegaremos a un punto en la vida de nuestra aplicación en el que hacer cambios y mejoras se convertirá en el placer de descubrir que "sólo" tendremos que reutilizar lo que ya está hecho.
En una teoría todos los elementos, salvo los axiomas, se derivan unos de otros y es "fácil" crear nuevos teoremas a partir de los que ya se conocen mediante derivaciones lógicas.
Este punto no es fácil de alcanzar, requiere de una buena guía (léase arquitectura + convenciones) y sobre todo de una gran disciplina y esfuerzo por mantener la cohesión de lo que se genere.
Creo que en esto consiste "programar bien" y es lo que persiguen por diferentes vías las metodologías existentes.
En la analogía, que no pretende ser muy estricta, en nuestro programa crearemos nueva funcionalidad a partir de la existente, ya sea reutilizando o modificando. Mientras más fácil sea comprender lo que ya se ha hecho, y cómo funciona, más fácil será reutilizarlo y modificarlo para lograr nuestro objetivo.
Mantener la cohesión requiere aplicar las "buenas prácticas", en especial:
- Asignar nombres explicativos absolutamente a TODOS los elementos (métodos, variables, clases) por muy insignificante que parezcan.
- Aplicar SIEMPRE las reglas de nomenclatura que se decidan, de forma que cada nombre contenga la mayor cantidad de información posible para un lector.
- Mantener la relación entre los nombres y la funcionalidad. Sí, aunque requiera renombrar un archivo en el control de versiones.
Muchas veces he visto como alguien (incluyéndome) crea un pedazo de código "rapidito" para resolver un problema, sin pensar a largo plazo. 2 horas después este pedazo es incomprensible para todo el mundo (a veces incluso para la misma persona que lo escribió), y por lo tanto, no reutilizable ni modificable.
También he visto como se hace una modificación de la funcionalidad sin adaptar los nombres de los elementos involucrados, con idénticas consecuencias.
Estos fragmentos de código actúan como aglutinantes y en poco tiempo habrá más código dependiente de este que tampoco será reutilizable ni modificable.
Lo mínimo que debe hacer un buen programador es mantener la cohesión al nivel que le corresponda:
- Desarrollador: clases, funciones, propiedades, variables.
- Arquitecto: todo
Desafortunadamente, las reglas de negocio que debemos implementar seguramente están entre las teorías con menos cohesión que existen. A veces incluso ni se pueden considerar teorías porque hay reglas que se contradicen! Pero ya eso no está en nuestras manos. Lo que podemos hacer es mantener el desorden al mínimo, localizado en la implementación de esas reglas.
