Architectures agiles [fermé]

Question

Je commence mon mémoire de fin d'études et le sujet sera "les architectures agiles"

Fondamentalement, cela commencera par une description des méthodologies traditionnelles de développement de logiciels, et la naissance ultérieure des méthodologies agiles, pour finir par des recommandations et une conception d'une architecture d'application flexible facilement adaptable aux changements inhérents à la construction de logiciels.

Ma question est la suivante : quels modèles et pratiques de conception recommanderiez-vous pour une telle architecture ?Je m'intéresse aux modèles qui permettent de maximiser le découplage de classes comme l'injection de dépendances, une maintenabilité élevée et une abstraction maximale du problème spécifique.

Answer 1

Je recommande ce qui suit :

1. Modèle de référentiel
2. Modèle de spécification
3. Injection de dépendance
4. Conception basée sur le domaine

Fondamentalement, tout ce que prêche la foule d’ALT.NET.

Answer 2

Certainement les pratiques d'IoC et basé sur un contrat la programmation en général serait en tête de ma liste.Par expérience, cependant, je mets en garde contre une trop grande abstraction du problème simplement pour le plaisir de l’abstraction.Par exemple.faire abstraction parce que vous le pouvez et non parce que n'importe qui pourra un jour utiliser cette abstraction.J'ai vu ce type d'architecture se détériorer et simplement ajouter un degré trop élevé de complexité à un système, ce qui aggrave la maintenance du système.

Une sorte de boucle de rétroaction autour de votre processus de développement – ​​qu'il s'agisse de tests unitaires, d'intégration continue et/ou de réunions « Scrum ».Je me rends compte que cela n'entre pas vraiment dans le cadre des "architectures" agiles, mais si vous n'avez pas de processus agile, aucun degré d'architecture "orientée agile" n'aura d'importance.

Answer 3

Les pratiques de conception essentielles que je suggère est de construire d'abord un squelette fonctionnel et de bout en bout de votre architecture.Le valider le plus tôt possible par de vrais retours d’expérience.

C'est ce que les programmeurs pragmatiques appellent "Tracer Bullets", et Alistair Cockburn comme "squelette ambulant".

Pouvez-vous également définir ce qu'une application est dans le contexte de votre thèse?Considérez-vous seulement logiciel d'application Ou traitez-vous également avec des systèmes plus complexes?

Answer 4

C'est une question intéressante, ça.Une architecture peut-elle être créée de manière agile de manière isolée ?Si nous envisageons quelque chose comme XP, je suis un peu dubitatif.Ou peut-être ai-je mal compris, mais cela ne m'a jamais empêché de développer...

Dans XP, pour adopter une approche que je connais mieux, nous allons avoir une sorte de structure très peu de temps après le démarrage d'un projet ;en fait, à peu près au moment où la première histoire est terminée.Au cours de l'écriture initiale de l'histoire, nous aurons commencé à avoir une idée de ce que nous pourrions construire - c'est inévitable :les programmeurs ont tendance à penser en termes de code.Mais penser trop loin nous amène dans YAGNI territoire.

Je pensais en quelque sorte qu'une grande partie de l'architecture d'une application développée dans un environnement agile devrait émerger grâce, en particulier, à une refactorisation constante et dédiée pour éliminer les duplications.

La question est donc peut-être tout autant d’évaluer s’il existe des caractéristiques particulières – ou des classes de caractéristiques – que les architectures évoluées à la suite d’un processus agile auront tendance à afficher.Et puis je pense que cela dépendra du type d'application que nous construisons, même si certains des principes déjà mentionnés (dont je comprends même quelques-uns) doivent être probables.

Answer 5

En ce qui me concerne, Agile ne prêche aucune « architecture » en tant que telle.Agile est une méthodologie basée sur des principes fondamentaux qui affectent la gestion de projet, les cycles de publication et les pratiques générales de développement, mais certainement pas l'architecture logicielle.

Tous les modèles logiciels répertoriés ici pourraient être utilisés en utilisant un processus en cascade puissant, ce qui est contraire au développement Agile.

Answer 6

Architecture de l'oignon

exemple

Answer 7

Être agile signifie accepter le changement, c'est-à-direadopter les changements dans les exigences et les décisions de conception et accepter la refactorisation, etc.beaucoup de choses de manière "traditionnelle" seraient mal vues, puisque vous touchez quelque chose qui fonctionne/précédemment convenu.

Dans des méthodes comme XP, on essaie de maintenir une qualité élevée en écrivant des tests unitaires.Imaginons que nous soyons tous d'accord sur l'écriture de tests unitaires.

C'est maintenant ici que vous pouvez introduire une architecture afin que le système soit testable, ou convivial, car tous les systèmes ne sont pas testables.Par exemple, rendre la couche intermédiaire appelable et séparer la couche d'interface utilisateur de la logique métier, etc.

Answer 8

Si Robert Martin a quelque chose à dire à ce sujet (et il a appelé la réunion originale du Manifeste Agile IIRC), alors l'architecture a absolument tout à voir avec l'Agilité.Toute la première section de son livre Développement de logiciels agiles, principes, modèles et pratiques il s'agit de SOLIDE principes architecturaux.Cela a été quelque peu controversé dans certains milieux, mais je ne comprends pas pourquoi.Si votre base de code est fragile et fortement couplée, elle ne peut pas être très ouverte au changement, ce qui est la marque de l'agilité.Séparer conceptuellement le processus de la pratique du code est une chose très peu agile à faire.

Principe 1 du manifeste :"Nous valorisons les individus et les interactions plutôt que les processus et les outils."

Définir le « processus » Agile comme une abstraction distincte de l’architecture de la base de code viole selon moi l’esprit de ce premier principe.