El requeteframework
Comenta Julio en el post Maldivas Arquitectura 1 – El sentido común del amigo Juan Irigoyen, "me ha sorprendido ver a gente de Plain Concepts "sonreirse" cuando le comentas algo del framework, no te dicen nada pero no están muy en su favor"
Me voy a permitir hablar en nombre de Plain Concepts, ya que en mi tarjeta pone Software Architect y estamos hablando de arquitectura... conste que esto en sí es un atrevimiento gordo, pues hay muchas visiones sobre el tema de los framework en Plain Concepts y gente que, aun teniendo otra visión, es tan arquitecto como yo o más. Además, no hay balas de plata.
Podría resumir el sentimiento general sobre el tema en lo siguiente...
No somos amigos de los frameworks generalistas que quieren solucionar todos los problemas y que añaden una capa de abstracción adicional, a veces demasiado compleja y pesada, sobre el framework de .Net. Ya tenemos un framework generalista que funciona muy bien: el .Net Framwork. Lease: generalmente no nos gusta Enterprise Library para proyectos 'in house'. Cuando tienes un solo proyecto, la curva de aprendizaje de Enterprise Library es muy significativa y rara vez se ve compensada por la reutilización y la flexibilidad que aporta.
Pongamos un ejemplo: Enterprise Library permite posponer la decisión sobre donde tiras tus logs a tiempo de despliegue de la aplicación. Evidentemente esto es algo que en si mismo, si no se cuenta el precio que hay que pagar es una excelente idea. Es algo que si no se valoran los costes adicionales todos 'compramos'. Es fácil ver solo reutilización y flexibilidad y obviar otras cuestiones relevantes: coste de aprendizaje, complejidad, perdida de control, fugas de abstracción etc… Por no decir que obligas a quien despliega ha realizar una configuración adicional que es propensa a errores. No todo tiene que ser configurable. Configurar tiene costes y riesgos asociados que una buena arquitectura centrada en el problema nos puede evitar.
Además parece que la flexibilidad y la reutilización son valores en si mismos, y no es cierto. La flexibilidad y la reutilización solo son importantes si es algo que necesitas. No son un valor en si mismas, y sobre todo ¡no son gratis!.
La simplicidad si que es un valor por si misma. Tal y como yo entiendo mi trabajo de arquitecto del software, y en gran parte como lo entendemos en Plain Concepts, este consiste en lograr la arquitectura más simple posible que cumple los requisitos marcados. Generalmente cuando utilizas un framework generalista arrastras mucha funcionalidad que nunca jamás vas a utilizar y que sin embargo vas a 'sufrir'. Yo no quiero que mi sistema de traceo sea capaz de salir a 27 fuentes diferentes. Yo quiero saber que necesidades de traceo tengo y buscar la arquitectura más simple que cubre esas necesidades.
Yo creo en los framework de dominio especifico que surgen de la continua refactorización y de necesidades reales. Creo en la arquitectura emergente. Creo en el enfoque de Juan, que ve su necesidad concreta y automatiza y simplifica todo lo que puede el trabajo repetitivo que aparece en su proyecto. Que crea abstracciones concretas para sus necesidades concretas. No creo que los 'frameworks' que se venden con lemas del estilo de 'genera 10000 líneas de código con un solo click de ratón'… no creo en esto hasta que el lema sea 'mantén 10000 líneas de código con un solo click de ratón'. Escribir código es la parte más barata del proceso de desarrollo de software. Los costes están en mantenerlo, evolucionarlo, probarlo, ponerlo en producción… esto se obvia a menudo. Estos costes son directamente proporcionales a la complejidad de tu base de código. No quiero 10000 líneas de código que no necisito solo por que Enterprise Library o un generador me las de gratis, es una complejidad que no quiero pagar.
Cuando usas un framework generalista esta cediendo control a una abstracción. Lo problemas empiezan cuando esa abstracción fuga detalles y tu no entiendes que pasa o no puedes recuperar un control que necesitas. Esto no significa que las abstracciones sean malas, sino que tienen un precio. Joel Spolsky lo explica como nadie en su excelente The Law of Leaky Abstraccions.
Lógicamente hay situaciones, como factorías de software donde las oportunidades de reutilización son muchísimo más altas que en el desarrollo de software 'in house'. Hay es posible que los costes de mantener un framework generalista si sean interesantes, por que un framework de dominio, debería adaptarse a tantas situaciones que acabaría siendo un framework generalista.
¡Por eso cuando oímos hablar de frameworks nos sonreímos!