Un libro que os recomiendo leer es  “The Architecture of Open Source Applications” (eds. Amy Brown y Greg Wilson, el mismo del libro sobre programas completos con 500 LoC o menos del que ya os hablamos antes). El libro explica, a través de sus autores, la arquitectura de 25 aplicaciones open source muy conocidas, especialmente lo que los autores han aprendido acerca de temas arquitectónicos durante su evolución.

Leer acerca de la experiencia adquirida durante muchos años en un entorno real permite aproximarse al mundo del diseño de arquitecturas de software de una forma mucho más práctica. Dejadme que os dé como ejemplo 15 “perlas de sabiduría” sacadas del libro, de las muchas que encontraréis si lo compráis (también se puede leer online gratis, y si queréis leer estas mismas 15 “wisdom pearls” en inglés, pasaros por aquí).

  1. La estructura de un programa no es algo que puedas diseñar de entrada sino que se crea a medida que pasa con el tiempo – James Crook
  2. Es muy difícil pensar acerca de la arquitectura de un programa una vez la fase de depuración de errores empieza – Margo Seltzer  y Keith Bostic
  3. Dos copias de una misma funcionalidad en el código es garantía de tener una de ellas implementada de forma incorrecta –  Margo Seltzer  y Keith Bostic
  4. Los programadores están más contentos y son más productivos cuando utilizan las herramientas con las que están familiarizados. Si dejas que un programador utilice la herramienta que prefiere, estarás optimizando tu recurso más valioso: él/ella mismo – Bill Hoffman y Kenneth Martin
  5. No hay asegurar la retrocompatibilidad (“backward compatibility”) de algo a lo que los usuarios no tienen acceso directo – Bill Hoffman y Kenneth Martin
  6. Escoger una arquitectura determinada parece canalizar o influir en las funcionalidades mismas que podremos ofrecer.  C. Titus Brown y Rosangela Canino-koning
  7. Una API es para siempre. Una API estable es un contrato entre el cliente y el proveedor de la API. Kim Moir
  8. Raramente vale la pena gastar mucho tiempo preparando una aplicación para que sea completamente adaptable a futuras evoluciones. La mayor parte de las veces acabarás introduciendo decisiones de diseño muy complicadas para escenarios que nunca van a pasar – Emil Ivov
  9. Un paquete que entra a formar parte de la Librería Estándar, tiene un pie en la tumba – Tarek Ziadé
  10. Principio de diseño: acepta que “un programador” es un recurso finito – Eric Allman.
  11. La mayoría de las funcionalidades fueron diseñadas en respuesta a feedback de los usuarios. Pero esto no quiere decir que hiciéramos lo que nos pedían  – Juliana Freire, David Koop, Emanuele Santos, Carlos Scheidegger, Claudio Silva y Huy T. Vo
  12. El futuro cercano del proyecto consiste más en gestionar el crecimiento de la comunidad que el del propio software – Berk Geveci y Will Schroeder
  13. La escalabilidad tiene poco que ver con detalles de rendimiento de bajo nivel y sí mucho con el diseño global del sistema. – Chris Davis
  14. Puedes aprender mucho más de los fallos reales que de disquisiciones teóricas sobre la estrategia a seguir  – Chris Davis
  15. Tener datos replicados y consistentes entre ellos es más difícil de lo que crees – Adam Marcus

¿Qué os parecen? ¿Hay alguna con la que no estéis de acuerdo (no todas son intuitivas a primera vista)? ¿Cuál añadiríais vosotros?

 

Ah, y si os han gustado estas lecciones y queréis más, os recomiendo también el libro Delft Students on Software Architecture, una colección de descripciones de las arquitecturas de proyectos open source (como Play Framework, Diaspora, Vagrant or Jekyll) escritas por estudiantes del máster deInformática de la Universidad de Delft. El libro está disponible en su totalidad en este proyecto en GitHub.