Este es un recuento gratuito y muy breve del nuevo libro de Robert Martin (Tío Bob) "Clean Architecture", lanzado en 2018.
Introduccion
La arquitectura de software es un poco como la construcción de arquitectura. Los edificios también tienen una estructura fractal: los edificios consisten en compartimentos, los compartimentos consisten en habitaciones, las habitaciones consisten en paredes, las paredes están hechas de ladrillos. Los programas, por otro lado, consisten en módulos, que consisten en paquetes, que consisten en clases, que consisten en funciones, etc. Sin embargo, la diversidad de las estructuras del programa es mucho más amplia que la de los edificios, por lo que el tío Bob considera que la arquitectura de software es "más arquitectónica" que la arquitectura de edificios.
Además, la arquitectura de edificios es más fácil de visualizar en la cabeza que el software, porque vemos edificios todos los días, y la arquitectura de los programas está oculta para nosotros dentro del código fuente. La arquitectura del software no es como nada.
Por otro lado, la arquitectura del software también debe recordar las limitaciones físicas, porque los programas se ejecutan en hardware real con rendimiento, memoria, ancho de banda de red, etc. limitados.
¿Qué es la buena arquitectura? Esta es una arquitectura que satisface las necesidades de los usuarios, propietarios de negocios y programadores, no solo en el momento actual,
sino también con el tiempo .
"Si crees que la buena arquitectura es cara, entonces prueba mal".
"La única forma de ir rápido es ir bien".
Prólogo
El tío Bob ha estado escribiendo código por más de 50 años. Escribió una amplia variedad de programas: grande, pequeño, GUI, consola, web, etc. ¡Y llegué a la conclusión de que las reglas de la arquitectura son las mismas en todas partes! E incluso más de 50 años no han cambiado a pesar del aumento gigantesco en la productividad del hierro.
Los lenguajes de programación también han mejorado mucho, pero las construcciones básicas se han mantenido igual: si, asignación, bucles, etc. Si pones un programador de mediados del siglo pasado para una MacBook moderna, al principio se vuelve loco, pero luego será normal escribir código Java en la Idea.
Pero durante más de medio siglo se ha ganado mucha experiencia, que aún no era hace 50 años. Se formularon las reglas, a las cuales se dedica este libro.
Introduccion
Escribir un programa de trabajo es fácil. Es difícil
escribir el programa correctamente . Esto requiere conocimiento, experiencia y habilidades, cuyo desarrollo requiere mucho tiempo y disciplina.
Cuando el programa se realiza correctamente, es fácil de mantener y hacer cambios. Hay un porcentaje muy bajo de defectos. No necesita hordas de programadores, toneladas de documentos con requisitos y rastreadores sofisticados.
Suena utópico, pero el tío Bob logró trabajar en tales proyectos. Pero desafortunadamente, en la mayoría de los casos tenemos que trabajar en un diseño terrible.
¿Qué es el diseño y la arquitectura?
Asumamos que diseño y arquitectura son uno y lo mismo.
La arquitectura no es solo el nivel superior, son los detalles de nivel superior y bajo en su conjunto. Uno sin el otro no existe.
El objetivo de la arquitectura de software es
minimizar los recursos humanos necesarios para construir y mantener el sistema requerido.
Si los esfuerzos son pequeños y lo
siguen siendo durante toda la vida , entonces el diseño es bueno. Si los esfuerzos aumentan con cada lanzamiento, entonces el diseño es malo.
Como ejemplo, el tío Bob muestra un gráfico de un proyecto real, en el que el número de empleados aumentó 50 veces, pero el número de líneas de código aumentó solo 2,3 veces (3M -> 7M). Un gráfico más aterrador es un aumento en el costo de una sola línea de código en ~ 40 veces. Es decir La productividad cayó del 100% a casi cero. Los programadores trabajan lo mejor posible, pero esencialmente no se puede hacer nada. Y ahora lo peor: si en el primer lanzamiento tuvimos que pagar a los empleados varios cientos de miles de dólares al mes, ¡al final esta cifra se convirtió en 20 millones de dólares al mes!
A continuación, el tío Bob recuerda la parábola de la liebre y la tortuga. En ella, la tortuga ganó la carrera porque la liebre era demasiado segura de sí misma, se fue a la cama y durmió durante toda la carrera.
Lo mismo con el desarrollo: el programador se divierte con la confianza de que podrá lanzar rápidamente el producto y restablecer el orden más adelante. Sin embargo, el problema es que después del lanzamiento necesita hacer la siguiente función, de lo contrario se quedará atrás de los competidores en el mercado. Al final, en unos meses su productividad simplemente caerá a cero y perderá.
Luego da un ejemplo de un experimento realizado por cierto Jason Gorman, donde escribe un programa simple varias veces. Y resulta que con TDD la primera vez es más rápida que incluso la tercera vez sin TDD. Es decir, si escribe correctamente, el resultado es más rápido.
El desarrollador debe
ser responsable del desorden que introduce en el proyecto. La calidad de la arquitectura debe ser tomada en serio. Pero para esto necesitas saber qué es una buena arquitectura.
Una historia sobre dos valores.
Hay dos valores: comportamiento y arquitectura.
Comportamiento significa que el programa cumple con los requisitos funcionales y, por lo tanto, aporta dinero a los dueños de negocios. El problema es que muchos programadores creen que este es su trabajo.
El segundo valor es la calidad con la que el programa permanece en un estado mantenido. Es decir, es fácil de cambiar. La complejidad de los cambios debe ser proporcional a la escala de estos cambios, pero no a su forma. La arquitectura no debe hacer preferencias de algunas formas sobre otras, de lo contrario, las solicitudes de los propietarios serán cada vez más difíciles de implementar cada vez.
¿Qué es más importante: comportamiento o arquitectura? Los gerentes creen que es más importante que el sistema funcione. Pero los programadores deberían considerar lo contrario, que la arquitectura es más importante.
La matriz de Eisenhower dice que importante y no urgente tiene una prioridad más alta que urgente y sin importancia. Y la arquitectura siempre es importante en contraste con el comportamiento, por lo que es más prioritario.
El programador debe luchar por la arquitectura. Un programador también es miembro de la empresa. La arquitectura es su responsabilidad.
Continuará ...