architecture - hashtags - Arquitecturas ágiles
architecture hashtags instagram (8)
Definitivamente las prácticas de IoC y la programación basada en contratos en general estarían en la parte superior de mi lista. Sin embargo, por una cuestión de experiencia, me gustaría advertir en contra de abstraer demasiado del problema simplemente por el bien de la abstracción. Ej. Resumir porque puedes y no porque alguien alguna vez podrá hacer uso de esa abstracción. He visto que ese tipo de arquitectura ha ido mal y simplemente agrega un grado demasiado alto de complejidad a un sistema que empeora el mantenimiento del sistema.
Algún tipo de retroalimentación alrededor de su proceso de desarrollo, ya sean pruebas unitarias, integración continua y / o reuniones "scrum". Me doy cuenta de que eso realmente no entra en el ámbito de las "arquitecturas" ágiles, pero si no tiene un proceso ágil, no importará ningún grado de arquitectura "orientada a la agilidad".
Estoy comenzando mi tesis de posgrado y el tema será "arquitecturas ágiles"
Básicamente, comenzará con una descripción de las metodologías tradicionales de desarrollo de software, y el posterior nacimiento de metodologías ágiles, terminando con recomendaciones y un diseño de una arquitectura flexible de aplicaciones fácilmente adaptable a los cambios inherentes en la construcción del software.
Mi pregunta es, ¿qué patrones y prácticas de diseño recomendaría para una arquitectura así? Me interesan los patrones que permiten la maximización del desacoplamiento de clases como la inyección de dependencia, la alta capacidad de mantenimiento y la máxima abstracción del problema específico.
En lo que a mí respecta, Agile no predica ninguna "Arquitecturas" como tal. Agile es una metodología que se basa en los principios fundamentales que afectan la gestión de proyectos, los ciclos de publicación y la práctica general de desarrollo, pero ciertamente no la arquitectura de software.
Todos los patrones de software enumerados aquí se pueden usar mediante un proceso de cascada fuerte que es anatema para el desarrollo ágil.
Es una pregunta interesante, esto. ¿Se puede crear una arquitectura ágil de forma aislada? Si estamos viendo algo así como XP, entonces estoy un poco dudoso. O tal vez he entendido mal, pero eso nunca me impidió expandirme ...
En XP, para adoptar un enfoque que conozco más, vamos a tener algún tipo de estructura dentro de muy poco tiempo después de que comencemos un proyecto; sobre el momento en que se completa la primera historia, de hecho. Durante la escritura de la historia inicial, comenzaremos a tener una idea de lo que podríamos construir: es inevitable: los programadores tienden a pensar en términos de código. Pero pensar demasiado adelante nos lleva al territorio de YAGNI .
Creo que se espera que gran parte de la arquitectura de una aplicación desarrollada dentro de un entorno ágil sea emergente a través de, en particular, la refactorización constante y dedicada para eliminar la duplicación.
Entonces, tal vez la pregunta sea tanto para evaluar si hay características particulares, o clases de características, que las arquitecturas desarrolladas como resultado de un proceso ágil tenderán a mostrarse. Y luego creo que dependerá del tipo de aplicación que construyamos, aunque algunos de los principios ya mencionados (algunos de los cuales incluso entiendo) deben ser posibles.
Recomiendo lo siguiente:
- Patrón de repositorio
- Patrón de especificación
- Inyección de dependencia
- Diseño impulsado por el dominio
Básicamente todo lo que predica la multitud de ALT.NET.
Ser ágil significa abrazar el cambio, es decir, adoptar para cambiar los requisitos y las decisiones de diseño y aceptar la refactorización, etc. muchas cosas que la forma "tradicional" frunciría el ceño, ya que estás tocando algo que está funcionando / acordado previamente.
En métodos como XP, intenta mantener la calidad alta escribiendo pruebas unitarias. Supongamos que todos estamos de acuerdo en escribir pruebas unitarias.
Ahora, aquí puede introducir algunas arquitecturas para que el sistema sea comprobable o apto para pruebas, ya que no todos los sistemas se pueden probar. Por ejemplo, hacer que la capa intermedia se llame y separe la capa de UI de la lógica de negocios, etc.
Una práctica de diseño esencial que sugeriría es construir primero un esqueleto funcional de extremo a extremo de su arquitectura. Para validarlo lo antes posible por real feedback.
Esto es lo que los programadores pragmáticos llaman "Tracer Bullets" y Alistair Cockburn como " esqueleto andante ".
¿Puede definir también qué aplicación es en el contexto de su tesis? ¿Solo considera el software de la aplicación o también se ocupa de sistemas más complejos?
Si Robert Martin tiene algo que decir al respecto (y llamó al original Agile Manifesto meeting IIRC), entonces absolutamente la arquitectura tiene todo que ver con Agility. Toda la primera sección de su libro Desarrollo de software ágil, Principios, patrones y prácticas trata sobre los principios arquitectónicos SÓLIDOS . Esto ha sido un tanto controvertido en algunos sectores, pero no entiendo por qué. Si su base de código es frágil y fuertemente acoplada, entonces no puede ser muy abierto para cambiar, que es el sello distintivo de la agilidad. El proceso de separación conceptual de la práctica del código es una tarea muy poco ágil.
Principio 1 del manifiesto: "Valoramos los individuos y las interacciones sobre los procesos y las herramientas".
Definir el "proceso" ágil como una abstracción separada de la arquitectura del código base para mí viola el espíritu de este primer principio.