Top Mantra de los Arquitectos (II)

Este artículo es el segundo de una serie de dos. Para ver el anterior, clic aquí.

Tenía pendiente terminar este artículo que ya inicié hace algún tiempo. Vamos a ello. Estábamos hablando del Top 10 de los Mantras de un arquitecto de software. El post anterior repasaba los mantras del 1 al 5. Vamos a los números 6 al 10.

Mantra #6: ¿No estás en la capa de datos? Entonces no pongas SQL!
Tal y como establece SoC (Separation of Concerns), intenta poner cada cosa en su sitio, sin mezclar. Pon el código de acceso a datos y los detalles como connection strings, bien lejos. Tarde o temprano, tendrás que ocuparte de ellos, pero considera por separado las lógicas de negocio y presentación de cara a la persistencia. Siempre que sea posible, delega la persistencia en una herramienta ORM.

Mantra #7: la mantenibilidad es lo primero
A pesar de que ya hablé en mi post sobre los mitos de la mantenibilidad, Dino Exposito tiene más razón que un santo al establecer que si hay que elegir un atributo para el software, como arquitectos, ha de ser la mantenibilidad, por encima de la escalabilidad, seguridad, rendimiento y testeabilidad. Si código y la arquitectura son mantenibles, el resto se puede conseguir más tarde (no así al contrario)

Mantra #8: el input del usuario es pura maldad
Tal y como comenta Dino en su libro, si existe una forma en que los usuarios hagan algo mal, encontrarán la forma de hacerlo. Si te suena esta afirmación a la ley de Murphy: SI, así es.

Mantra #9: Optimización Post-Mortem
Tal y como indica Dino (y estoy totalmente de acuerdo), empezar a diseñar un sistema con la optimización en mente es un error. Yo voy a ir un poco más allá: es un signo de inmadurez. Y me refiero a inmadurez profesional, a falta de experiencia. Tratar de que un sistema crezca siendo óptimo desde el principio es una buena forma de perder el foco de lo que realmente es importante. Es mucho más importante (ver mantra #7) que sea mantenible, ya que ante cualquier cambio, podemos optimizarlo. Un software muy optimizado desde el principio, seguramente no será mantenible y por tanto, ante cualquier cambio (que los habrá, no os preocupéis), dejará de ser óptimo. Y por desgracia, en esa situación, ya poco habrá que hacer.

Mantra #10: La seguridad y testeabilidad, han de estar "por diseño".
Aquí poco hay que decir. Es tan radicalmente cierto, que incluso hay un estándar de la International Organization for Standardization (ISO) que explícitamente, lo establece. Un sistema, por mantenible que sea, es muy complicado (y por tanto caro) que sea seguro a base de hacer cambios. Lo mismo la testeabilidad. Si no empiezas diseñando para que sea testeable, con sus pruebas unitarias, con la arquitectura adecuada...no podrás de repente implantar la testeabilidad.

Y nada más. Que os recomiendo encarecidamente este libro. Es de los pocos, junto con los del eterno Steve McConnell, que merecen la pena comprarse y leerse más de una vez. ¡Ah, y no me llevo comisión por decir esto, eh! Más info del libro:

by Dino Esposito and Andrea Saltarello

Microsoft Press. (c) 2009

Microsoft .NET: Architecting Applications for the Enterprise