En parcourant des articles sur la conception de logiciels, j'ai constamment rencontré un nuage d'abréviations sans précédent et de pratiques de développement nonchalamment mentionnées.

• TDD - eh bien, tout le monde le sait, nous écrivons d'abord des tests, puis le reste du code.
• BDD est quelque chose de familier, un peu comme des tests aussi, mais des tests spéciaux.
• TDD - Encore une fois? Alors, arrêtez, ici ce n'est pas du tout des tests. Mais pourquoi est-il appelé la même chose?
• DDD - contextes liés, langage omniprésent, domaine ...
• FDD - Oui, combien est-ce possible?
• MDD - Sérieusement, basé sur un graphique?
• PDD - ...

Les approches de développement sont divisées par complexité, domaines d'application et objectifs.
Je pense que le moment est venu de comprendre pourquoi ils sont nécessaires, pourquoi ils sont si nombreux et comment ils peuvent nous être utiles.

Nous commencerons à les connaître du plus simple au plus complexe, considérons des exemples d'utilisation et les avantages et les inconvénients de chacun d'eux.

TDD - Développement piloté par les tests

TDD est une méthodologie de développement logiciel basée sur la répétition de courts cycles de développement: initialement, un test est écrit couvrant le changement souhaité, puis un code de programme est écrit qui implémente le comportement système souhaité et vous permet de passer le test écrit. Ensuite, le code écrit est refactorisé avec des tests constants des tests.

Cela semble simple et clair. Beaucoup connaissent cette approche du développement, et même l'oncle Bob lui-même en fait activement la promotion.

TDD est considéré comme une forme de construction d'application appropriée. La philosophie de développement pilotée par les tests est que vos tests sont une spécification du comportement de votre programme. Si vous considérez votre suite de tests comme une partie obligatoire du processus de génération, si vos tests échouent, le programme ne se construit pas car il est incorrect. Bien sûr, la limitation est que l'exactitude de votre programme est uniquement définie comme l'exhaustivité de vos tests. Cependant, des études ont montré qu'un développement basé sur des tests peut réduire les erreurs de 40 à 80% en production.

Lorsque vous commencez à utiliser TDD, vous pouvez sentir que vous courez plus lentement que d'habitude. En effet, vous travaillerez en dehors de la «zone de confort», ce qui est tout à fait normal.

Une fois que vous sentez que l'écriture de tests est devenue une partie simple et naturelle du flux de travail, que vous n'avez plus besoin de penser à l'utilisation de TDD lorsque vous travaillez sur un projet, vous vous rendez compte que TDD a coulé dans votre travail.

Cette méthodologie nous permet de réaliser la création d'une application adaptée aux tests automatiques et une très bonne couverture du code avec des tests, puisque TK est traduit dans le langage des tests automatiques, c'est-à-dire que tout ce que le programme doit faire est vérifié. TDD simplifie également souvent la mise en œuvre logicielle: la redondance de la mise en œuvre est éliminée - si un composant réussit le test, il est alors considéré comme prêt.

L'architecture des produits logiciels ainsi développés est généralement meilleure (dans les applications adaptées aux tests automatiques, la responsabilité entre les composants est généralement très bien répartie et les procédures complexes exécutées sont décomposées en de nombreuses simples). La stabilité de l'application développée grâce aux tests est plus élevée du fait que toutes les fonctionnalités de base du programme sont couvertes par des tests et leurs performances sont constamment contrôlées. Accompagner des projets où tout ou presque tout est testé est très élevé - les développeurs peuvent ne pas avoir peur de modifier le code, si quelque chose ne va pas, les résultats des tests automatiques en informeront.

Vous pouvez en apprendre plus sur les principes TDD en lisant le livre Extreme Programming de Kent Beck.

TDD - Type Driven Development

Le développement piloté par type est abrégé ainsi que le développement par le biais de tests, donc généralement le nom complet est écrit.

Lors du développement sur la base de types, vos types de données et signatures de type sont une spécification du programme. Les types servent également de formulaire de documentation dont la mise à jour est garantie.

Les types sont de petits points de contrôle, grâce auxquels nous obtenons beaucoup de mini-tests tout au long de notre application. De plus, les coûts de création de types sont minimes et leur mise à jour n'est pas nécessaire, car ils font partie de la base de code.

Le développement par type est une autre bonne méthode pour construire une application. Comme pour le développement basé sur des tests, le développement basé sur le type peut accroître votre confiance dans votre code et vous faire gagner du temps lors de la modification d'une grande base de code.

Parmi les inconvénients, seule la complexité croissante des langues à typage dynamique. Par exemple, pour JavaScript, cette approche est plus difficile à appliquer que pour TypeScript.

Sur un habr il y a un excellent article sur la dactylographie.

BDD - Développement axé sur le comportement

En raison de certaines similitudes méthodologiques, TDD (Test Driven Development) et BDD (Behavior Driven Development) sont souvent confondus même par les professionnels. Quelle est la différence? Les concepts des deux approches sont similaires, les premiers tests sont effectués et ce n'est qu'ensuite que le développement commence, mais leur objectif est complètement différent. TDD concerne davantage la programmation et les tests au niveau de l'implémentation technique du produit, lorsque les tests sont créés par les développeurs eux-mêmes. BDD implique un testeur ou un analyste décrivant les scripts définis par l'utilisateur dans un langage naturel - si je puis dire, dans le langage des affaires.

BDD - le développement axé sur le comportement est un développement basé sur le comportement. Une certaine personne (ou des personnes) écrit des descriptions du formulaire "en tant qu'utilisateur que je veux lorsque le bouton de démarrage est enfoncé alors le menu était affiché comme dans l'image" (il y a des mots clés spécialement mis en évidence). Les programmeurs ont écrit depuis longtemps des outils spéciaux qui traduisent ces descriptions en tests (parfois complètement transparents pour le programmeur). Et puis le développement classique avec des tests.

Si vous enregistrez les noms des tests sous forme de phrases et utilisez le vocabulaire du domaine d'activité pour écrire les noms des méthodes, la documentation créée devient claire pour les clients, les analystes et les testeurs.

Les textes de script sont écrits sous une forme spécifique.

Ayant (approximativement donné - donné) un certain contexte,

Quand (notez quand) un événement se produit,

Ensuite (environ ensuite) vérifiez le résultat.

Quelque chose comme ça pourrait arriver:

Ou un autre exemple en russe:

Scénario 1: Il y a de l'argent dans le compte +

Avoir un compte avec de l'argent

Et une carte valide

Et un guichet automatique avec de l'argent

Lorsqu'un client demande de l'argent

Assurez-vous ensuite que le compte a été débité

Et assurez-vous que l'argent est émis

Et assurez-vous que la carte est retournée

L'approche BDD, ainsi que les pratiques d'ingénierie, nous ont permis d'abandonner la documentation existante contenant des informations non pertinentes et de recevoir de la nouvelle documentation à la volée, de la stocker avec le projet, ce qui a rapproché les analystes et les testeurs du code.

BDD est plutôt un processus dont le but est de réduire le coût de mise en œuvre de nouvelles fonctionnalités. Même au début du développement, nous obtenons des artefacts importants. Par exemple, une documentation compréhensible à prendre en charge. Cette documentation permet à toutes les parties intéressées de se forger une propre compréhension des scénarios de comportement du produit et de l'utilisateur qui doivent être mis en œuvre lors des itérations de développement. Avec l'approche BDD, nous abaissons également le seuil d'entrée de nouveaux membres dans le projet.

Quel est l'avantage de BDD?

• Tests lisibles pour les non-programmeurs.
• Ils sont faciles à changer. Ils sont souvent écrits en anglais presque pur.
• Ils peuvent être rédigés par le propriétaire du produit ou d'autres parties intéressées.
• Les résultats des tests sont plus humains.
• Les tests sont indépendants du langage de programmation cible. La migration vers une autre langue est grandement simplifiée.

Inconvénients:

Mais cette approche a ses inconvénients - elle est longue et coûteuse. Le BDD n'est pas pratique, même s'il nécessite la participation de spécialistes des tests déjà au stade de l'élaboration des exigences, ce qui allonge le cycle de développement.

Le moyen de sortir de cette situation peut être le choix d'un cadre BDD approprié et des processus de développement correctement construits.

En savoir plus sur BDD ici .

Beaucoup ont compris depuis longtemps que le dépistage est une sorte de panacée pour toutes les maladies, mais est-ce vraiment le cas? Bien sûr, un code soigneusement testé fonctionne plus stable et prévisible, mais les tests ne nous épargnent pas de problèmes et d'erreurs au stade de la conception et de la définition des tâches. Les approches de développement suivantes peuvent vous y aider.

DDD - Conception pilotée par domaine

La conception orientée sujet n'est pas une technologie ou une méthodologie spécifique. DDD est un ensemble de règles qui vous permettent de prendre les bonnes décisions de conception. Cette approche peut accélérer considérablement le processus de conception de logiciels dans un domaine inconnu.

La conception orientée sujet (moins souvent axée sur les problèmes, l'anglais. La conception orientée domaine, DDD) est un ensemble de principes et de schémas visant à créer des systèmes d'objets optimaux. Le processus de développement se résume à la création d'abstractions logicielles, appelées modèles de domaine. Ces modèles incluent une logique métier qui établit une relation entre les conditions réelles du domaine d'application du produit et le code.

L'approche DDD est particulièrement utile dans les situations où le développeur n'est pas un spécialiste dans le domaine du produit développé. Par exemple: un programmeur ne peut pas connaître tous les domaines dans lesquels il est nécessaire de créer un logiciel, mais à l'aide d'une représentation correcte de la structure, grâce à une approche orientée sujet, il peut facilement concevoir une application basée sur des points clés et une connaissance de l'espace de travail.

Dans cet article, j'essaie de transmettre l'essence de chaque approche du développement logiciel, mais à propos de DDD, vous pouvez écrire plus d'un article et couvrir toutes les nuances en plusieurs paragraphes, cela ne fonctionnera pas pour moi. Par conséquent, en expliquant, je fournirai des liens explicatifs vers les sources les plus dignes.

L'objectif principal de la conception pilotée par domaine est de lutter contre la complexité des processus métier, leur automatisation et leur implémentation dans le code. «Domaine» se traduit par «domaine», et le développement et la conception dans le cadre de cette approche sont éloignés du domaine.

Le concept clé de DDD est le langage omniprésent. Un langage omniprésent favorise une communication transparente entre les participants au projet. Il n'est pas un dans le sens où il l'est pour toutes les occasions. Bien au contraire. Tous les participants y communiquent, toutes les discussions se déroulent en termes de langue unique et tous les artefacts doivent être présentés en termes de langue unique, c'est-à-dire à partir des savoirs traditionnels et se terminant par un code.

Le concept suivant est le «modèle de domaine». Ce modèle est un glossaire de termes issus d'un langage omniprésent. Le modèle de domaine et le langage omniprésent sont tous deux limités par le contexte que la conception pilotée par domaine appelle contexte borné. Il restreint le modèle de domaine de telle manière que tous les concepts qu'il contient sont sans ambiguïté et que tout le monde comprend ce qui est en jeu.

Exemple: prenez l'entité «personne» et placez-la dans le contexte de «parler en public». Dans ce contexte, selon DDD, il devient un orateur ou un orateur. Et dans le contexte de la «famille» - un mari ou un frère.

Maintenant sur le code. Il est important que votre code soit lu comme un livre, qu'il soit simple et compréhensible pour tous ceux qui parlent le langage commun du projet. Qu'est-ce que je veux dire?

Si, dans la langue du projet, vous utilisez l'expression "le produit a été ajouté", l'option suivante n'est pas DDD:

var product = new Product ('apple')

product.save ()

Pourquoi? Le code indique que nous avons créé le produit d'une manière étrange et l'avons enregistré. Comment ajouter un produit tout de même? Besoin de l' ajouter . Voici le code DDD:

Produit :: add ('apple');

Architecture:

Du point de vue de la conception pilotée par domaine, peu importe l'architecture que vous choisissez. La conception pilotée par domaine ne concerne pas cela; la conception pilotée par domaine concerne le langage et la communication.

Mais DDD est presque impossible sans une architecture de projet propre, car lors de l'ajout de nouvelles fonctionnalités ou de la modification de l'ancienne, vous devez essayer de maintenir la flexibilité et la transparence de la base de code. Vous pouvez lire sur les ports, les adaptateurs et l'architecture d'oignon dans un excellent article . L'image ci-dessus en est juste.

Il y a aussi des articles sur DDD que je recommande fortement de lire attentivement - ici et ici .

Qu'est-ce que cela nous donne au final:

• presque tous les membres de l'équipe peuvent lire le code du projet;
• l'énoncé des tâches devient plus explicite;
• les bogues dans la logique métier deviennent plus faciles à rechercher;
• Il est beaucoup plus facile pour les spécialistes de l'assurance qualité d'analyser le code et de trouver des erreurs logiques et des bogues.

Inconvénients:

• Des développeurs hautement qualifiés sont requis, en particulier au début du projet;
• tous les clients ne sont pas disposés à faire de tels coûts, DDD doit être étudié par tous les participants au processus de développement.

FDD - Développement piloté par les fonctionnalités

FDD - Cette méthodologie (brièvement appelée FDD) a été développée par Jeff De Luca et le gourou reconnu dans le domaine des technologies orientées objet, Peter Coad. FDD est une tentative de combiner les techniques les plus reconnues dans l'industrie du développement logiciel qui prennent comme base les fonctionnalités (propriétés) importantes du logiciel développé pour le client. L'objectif principal de cette méthodologie est de développer un logiciel réel et fonctionnel systématiquement, dans les délais.

Comme d’autres méthodologies adaptatives, elle se concentre sur de courtes itérations, chacune servant à déterminer une certaine partie des fonctionnalités du système. Selon le FDD, une itération dure deux semaines. FDD a cinq processus. Les trois premiers concernent le démarrage du projet:

• développement d'un modèle commun;
• compiler une liste des propriétés système requises;
• planification des travaux sur chaque propriété;
• conception de chaque propriété;
• construction de chaque propriété.

Les deux dernières étapes doivent être effectuées lors de chaque itération. De plus, chaque processus est divisé en tâches et a des critères de vérification.

Arrêtons-nous sur chaque élément plus en détail.

Développement d'un modèle commun.

Le développement commence par une analyse de l'étendue de l'éventail des tâches existantes et du contexte du système. De plus, pour chaque zone simulée, une analyse plus détaillée est effectuée. Les descriptions préliminaires sont compilées en petits groupes et soumises pour discussion et évaluation par des experts. Après l'un des modèles proposés ou leur combinaison devient un modèle pour une zone spécifique. Les modèles de chaque domaine de tâche sont combinés en un modèle final commun, qui peut changer au cours du travail.

Caractéristiques de l'annonce

Les informations recueillies lors de la construction du modèle général sont utilisées pour compiler une liste de fonctions. Les fonctions sont combinées en ce que l'on appelle des «domaines» (domaine anglais) et, à leur tour, ils sont divisés en sous-régions (domaines thématiques anglais) selon un attribut fonctionnel.

Chaque sous-domaine correspond à un processus métier spécifique et ses étapes deviennent une liste de fonctions (propriétés). Les fonctions sont présentées sous la forme «action - résultat - objet», par exemple «vérifier le mot de passe utilisateur». Le développement de chaque fonction ne devrait pas prendre plus de 2 semaines, sinon la tâche doit être décomposée en petites itérations. La liste des propriétés dans FDD est la même que le backlog de produit dans SCRUM.

Plan des propriétés (fonctions)

L'étape suivante est la distribution des fonctions entre les principaux programmeurs ou équipes.

Conception des fonctionnalités

Un package de conception est créé pour chaque propriété. Le programmeur principal décrit un petit groupe de propriétés à développer dans un délai de deux semaines. Après cela, des diagrammes de séquence détaillés pour chaque propriété sont laissés, spécifiant le modèle général. Viennent ensuite les «talons» écrits des classes et des méthodes. À ce stade, nous devons nous concentrer sur la conception du produit logiciel.

Implémentation des fonctions

Nous écrivons le code, supprimons les talons, testons.

Une fois que la propriété a été testée et intégrée au produit, nous prenons la propriété prioritaire suivante, répétons le cycle de conception / mise en œuvre.

Au total, en conséquence, nous obtenons:

• documentation des propriétés du système;
• conception soignée;
• plus facile à évaluer de petites tâches;
• les tests sont axés sur les tâches commerciales;
• processus de création de produits sophistiqué;
• De courts cycles de développement itératifs vous permettent d'augmenter rapidement les fonctionnalités et de réduire les erreurs.

Inconvénients:

• FDD est plus adapté aux grands projets. Les petites équipes de développement ne pourront pas profiter de tous les avantages de cette approche;
• coûts de mise en œuvre et de formation importants.

MDD - Développement piloté par les modèles

Récemment, une grande attention a été accordée dans les publications au thème de l'architecture et du développement basé sur les modèles MDA (Model Driven Architecture) et MDD (Model Driven Development). Sans entrer dans les détails, nous ne mettons en évidence que les points clés.

Le développement piloté par les modèles est un style de développement logiciel où les modèles deviennent les principaux artefacts de développement à partir desquels du code et d'autres artefacts sont générés.

En termes simples, tout le point de développement est de construire les diagrammes nécessaires, à partir desquels nous générons ensuite le code de travail du projet.

L'objectif principal de MDD est de minimiser les coûts associés à la connexion à des plates-formes système et des infrastructures logicielles spécifiques. Après tout, la logique métier principale est contenue dans des diagrammes et ne nous lie pas à la portée du choix d'un langage de programmation et des outils de développement.

Écartons-nous un peu et pensons au compilateur. Il convertit un langage de programmation de haut niveau en une implémentation équivalente en langage machine. Le modèle dans ce cas est un programme écrit dans un langage de haut niveau qui cache des détails non pertinents sur sa mise en œuvre. Dans MDD, nos diagrammes sont un autre niveau d'abstraction, ce qui ne nous permet pas de nous enliser dans les détails du développement, mais de regarder la situation dans son ensemble.

Les diagrammes agissent comme des «dessins» particuliers à partir desquels divers processus automatisés et semi-automatisés extraient des programmes et des modèles correspondants. ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

Inconvénients:

• .

PDD , , , .

Conclusion

agile . , , .

- Driven Development , DDD, BDD, MDD , .