Diseñando para el cambio o la perdición

Hemos sido atemorizados hasta la parálisis sobre los males que podrían azotarnos si nuestros diseños no estuvieran pensados para el cambio: que el día del cambio, siete jinetes negros -muy parecidos a los del señor de los anillos- vendrán a reclamar nuestras almas y a sentarnos a extender un diseño o a cambiar lineas de código para luego llevarnos a la torre de los clientes insatisfechos. Lo que esto quiere decir es que en el momento de hacer los planos uno está pensando no solo en los usos requeridos actuales del sistema sino también en los posibles usos que podrían surgir en el futuro. Esta tarea es terriblemente compleja y nos eleva a la altura de Gitanas místicas o lectores de borra de café.

Mis experiencias con este tipo de diseños me inclinan a pensar que esta postura, si bien alagadora, conduce a aguas muy peligrosas, si lo vemos desde la óptica de que aquello que complica el entendimiento de un sistema está directamente ligado a la cantidad cosas que nos permite hacer. Cuanto mas grande el sistema, mas cosas se nos permite, más difícil es saber dónde están las que realmente necesitamos y mas escasean quienes saben como se comporta o adapta a una combinación de ellas. Un sistema grande tiende a ser un sistema complejo con interacciones complejas, esta complejidad produce demanda de mantenimiento y conduce a errores ya que, al ser difícil saber como tiene que comportarse, las fallas en su implementación y los errores de interpretación son frecuentes, y por la misma razón, es probable que su reparación incluya nuevos errores.

Curiosamente, un diseño pensado para el cambio, preparado para satisfacer una variedad de necesidades y soportar infinidad de rumbos, frecuentemente no llega a demostrar su valor enfrentando sus oraculares quimeras. Peor aún es el escenario que nos muestran los frecuentes despojos de sus sistemas que se pierden antes de llegar a producción, sin siquiera haber satisfecho las necesidades mínimas que le dieron origen, haciendo de sus dudosas fortalezas la causa de su caída.

Algunos atrevimientos a la espera de que den mejores resultados:

• diseñar para el uso en lugar del cambio - Antes de comenzar a hacer un diseño complejo, empezar escribiendo código de usuario que use el hipotético sistema: que el sistema sea simple de usar.

• si se trata de flexibilidad, que su uso se flexible - Si nos vemos obligados a proporcionar cierta flexibilidad o toleracia a cambios, diseñar el sistema de tal manera que el codigo de un usuario que no requiera tal flexibilidad no se vea complicado por ella. Si es optativo, que su setup no sea obligatorio.

• diseñar es restringir - El diseño mas flexible del mundo es el no diseño ya que nos permite hacer absolutamente todo. Siempre se puede tener un sistema mas flexible, la pregunta que cabe hacerse es si conviene tener dicha flexibilidad. Considera la posibilidad de restringir todo lo que puedas, que tu sistema contemple solo lo escencial ya que terminarás antes, tendrás mas tiempo para atender eventualidades y en caso de que las cosas salgan mal, la perdida será menor.
  

claves: diseño orientado a objetos, OOP, sistemas, patterns, agile, diseño para el cambio.