Image du blog tomaszjaniak
Montrez-nous votre architecture
Il se trouve que vous travaillez sur un projet depuis quelques années et que vous êtes maintenant assis à vos coudes dans le code, les tests brûlent, le refroidisseur d'ordinateur portable fait du bruit, essayant de refroidir la chaleur du processeur surchauffé par le compilateur, juste quelques heures de plus - et la refactorisation sera terminée. Et puis il faut de toute urgence tout abandonner et dessiner l'architecture du projet. Un gros client est prévu, et pour conclure la transaction, il est nécessaire de se soumettre à un audit. Et dans ce cas, il n'y a nulle part sans diagrammes architecturaux. Alors que se passe-t-il si le projet est encore petit et qu'une douzaine de ses développeurs en vrai travail n'ont pas besoin d'architecture là-bas. Voici le code - tout est clair. Mais il n'y a aucune issue. C'est nécessaire - alors c'est nécessaire.
Si vous savez comment tout fonctionne, l'architecture de n'importe quel produit peut être dessinée en une heure. Et cela suffit généralement pour un audit. Après tout, le but de l'audit n'est pas que les tiers comprennent vraiment l'architecture de votre produit. Le but de la question est de déterminer si les développeurs de produits eux-mêmes ont une compréhension de ce qu'ils font. Et si vous parlez avec suffisamment d'assurance et répondez aux questions sans hésitation, tout se passera bien. Mais quand même, lorsque cette histoire se terminera, quelque part dans les profondeurs, un ver s'installera, ce qui aiguisera la question: mais quand même, quel type d'architecture le produit a-t-il réellement? Après tout, s'ils le demandent, probablement d'autres ont l'architecture. Et si nous ne l'avons pas, c'est clairement un gâchis. Il y a un grand désir de tout bien faire pour être responsable de l'architecture la prochaine fois comme il se doit.
Comment le faites-vous correctement? Vous devez dessiner des diagrammes, décrire les fonctionnalités des documents, puis tout mettre à jour. Ensuite, ce sera l'architecture. Mais, après avoir présenté la quantité de travail, il devient vite clair que tout cela ne vaut pas le temps passé. Voici le code - tout est clair. Et si un autre client vient, dans une autre heure, il sera possible de dessiner un nouveau diagramme.
Et après quelques années, vous risquez de vous retrouver dans la situation inverse, et les documents qui décriront l'architecture d'un autre produit ne seront pas meilleurs. Bien sûr, il est utile de savoir que d'autres ont aussi une très mauvaise architecture. Mais lorsque la taille d'un projet commence à se mesurer en millions de lignes de code, et le nombre de développeurs en centaines, la question de la nécessité d'une architecture devient encore importante.
Ici, dans le cadre du workflow, divers schémas architecturaux commencent à apparaître, les propositions architecturales commencent à écrire sur les fonctionnalités, tout cela est discuté, revu, validé, approuvé et, bien sûr, devient obsolète avant même que ces processus ne soient terminés. Il n'est pas nécessaire de dire que ces documents reflètent la structure réelle du code d'application. Et en ce qui concerne la mise en œuvre, il arrive que les développeurs ne lisent pas du tout ces documents. Ou quelque chose de complètement différent de ce qui a été écrit est mis en œuvre. Quelqu'un a mal compris quelqu'un, ou il était urgent de le faire, et il n'y avait pas de temps pour discuter.
C'est peut-être comme ça que ça devrait être. Peut-être que l'architecture est la bureaucratie autour de documents spéculatifs, séparée de la réalité? Mais l'intuition nous dit qu'après tout, non. Alors, qu'est-ce que «l'architecture»?
L'architecture est ...
Que se passe-t-il si vous posez la question "Qu'est-ce que l'architecture?" dix développeurs professionnels? Si vous ne fouillez pas dans Wikipedia, donneront-ils la même réponse?
L'architecture est à la fois un ensemble de décisions importantes et la structure des éléments, et de leurs interfaces, et un système de dispositions, de règles et d'accords, et d'approches formées qui maintiennent l'ordre et les solutions aux problèmes mondiaux, et la décomposition avec interaction, et une description de haut niveau du système et de son cycle de vie. des éléments et des modèles de structure et de comportement, et ce qui est difficile ou coûteux à modifier ou à supprimer, ainsi que les décisions et compromis fondamentaux, et bien plus encore.
L'architecture est également la manière dont une application remplit son objectif.
L'API est une architecture, un schéma de données est également une architecture et une structure de modules et de services. Il existe une architecture de mise à l'échelle des applications, une architecture de fiabilité des applications, une architecture d'interaction des composants et une architecture de sécurité. Et bien sûr, chaque fonctionnalité a sa propre architecture. Et tout cela ensemble est aussi de l'architecture.
Tout cela peut-il être considéré comme une réponse à la question "Qu'est-ce que l'architecture?" - peut-être oui. Tout semble correct, tout semble clair. Mais cette réponse est-elle pratiquement utile, quelque chose qui peut être utilisé dans un vrai workflow? Pas vraiment.
Comment savoir si une décision est importante ou fondamentale? Quels sont les défis mondiaux? Qu'est-ce que cela signifie cher ou bon marché? Comment évaluez-vous la complexité? Quelle est la frontière entre le haut niveau et le bas niveau? Qu'est-ce que l'ordre? Quel est le but du système?
Ce sont toutes des questions auxquelles vous pouvez également essayer de répondre. Formuler des définitions, expliquer avec des exemples, au pire, organiser le processus décisionnel. Mais cela restera encore quelque chose de controversé, quelque chose d'intuitif, dépendant de la perception personnelle et compris par chacun un peu à sa manière. Cela signifie qu'il y aura toujours des conflits basés sur le fait que différentes personnes interprètent la même situation de manière radicalement différente. Les développeurs se plaindront que les architectes falsifient les détails de mise en œuvre, les architectes que les développeurs brisent l'architecture. S'il n'y a pas de frontière claire, les conflits sont inévitables.
Tout le monde a probablement une compréhension générale de ce qu'est l'architecture. Mais il est difficile de nommer une définition unique, formellement vérifiée et mathématiquement précise.
D'un autre côté, si vous demandez "Qu'est-ce que la réalisation?" - la réponse est susceptible d'être sans ambiguïté: "Voici un lien vers le référentiel de code!" Et vous ne pouvez pas discuter avec cela. Et il n'y a aucun doute ou ambiguïté dans l'interprétation de cette réponse. 1 + 1 = 2, l'implémentation est du code.
Et c'est très facile de travailler avec le code. Si vous souhaitez comprendre l'implémentation, vous pouvez ouvrir le projet dans l'environnement de développement. Si les modifications du code doivent être examinées, il existe des branches dans le référentiel. S'il est temps de publier une nouvelle version de l'application, des tests sont lancés.
Bien entendu, la structure du projet peut prêter à confusion, les évaluations sont de mauvaise qualité et la couverture des tests est incomplète. Mais, au moins lorsque vous travaillez avec du code, il est toujours clair ce qu'il faut faire et quand.
Mais que se passerait-il si l'architecture était exprimée en code, tout comme l'implémentation?
De nombreux langages de programmation traditionnels sont utilisés dans le développement moderne. La plupart d'entre eux sont apparus il y a longtemps ou très longtemps. Et tant qu'ils sont encore bons, ils sont un peu démodés. Ce sont des langages faiblement typés: JavaScript, Python, PHP, Ruby et des langages fortement typés: Java, C / Objective-C / C ++, C #. Ils sont remplacés par de nouveaux langages qui, dans le cadre de la même plateforme, tentent de résoudre des problèmes de longue date, en les saupoudrant de sucre syntaxique, mais sans introduire de concepts fondamentalement nouveaux, si vous regardez globalement: Swift, Kotlin, TypeScript, Go. Ce sont tous des langages construits sur le paradigme orienté objet. En outre, l'approche fonctionnelle de la programmation a gagné en popularité, qui est à la fois implémentée dans les langages listés et présentée dans des langages spécialisés, mais moins populaire: Erlang, F #.Les langages qui implémentent des concepts sensiblement nouveaux commencent également à gagner en popularité: Rust, Haskell.
Toute cette diversité a un point commun: ce sont tous des langages d'implémentation. Aucun de ces langages de programmation n'est une expression de l'architecture. Mais il y a une exception: SQL.
SQL est le seul langage de programmation grand public à être déclaratif. Il est construit sur un modèle d'algèbre relationnelle et a une spécialisation étroite - travailler avec des données stockées. Mais encore, pourquoi SQL peut-il être considéré comme le langage de l'architecture?
Tout d'abord, SQL donne accès à des méta-informations sur le schéma de données. Vous pouvez facilement obtenir une liste de tables, colonnes, relations, index, vues, rôles, etc. à partir de la base de données. Documenter le schéma de stockage et pouvoir le visualiser est une aide précieuse pour comprendre la structure de votre application. Une description de schéma de données est un type de description d'architecture de haut niveau.
Deuxièmement, SQL fournit un langage de requête de données qui permet au client d'interroger n'importe quelle combinaison de données décrites dans le schéma. S'il n'y avait pas de langage de requête, alors pour chaque modèle de données requis par le client, soit une méthode API distincte devrait être implémentée, soit le client serait forcé de faire plusieurs appels API à différentes parties du schéma de données et de combiner le modèle requis de son côté. La présence du langage de requête permet d'exclure de la description de la mise en œuvre de l'architecture les détails associés à l'énumération des méthodes API pour obtenir des modèles de données spécifiques selon le schéma général. Le langage de requête exclut les détails d'implémentation de la description de l'architecture.
SQL fournit trois propriétés clés importantes pour la description de l'architecture:
- Déclarativité - SQL vous permet de séparer la description de l'architecture de son implémentation.
- Facilité d'analyse - SQL donne accès aux méta-informations du schéma de données, ce qui vous permet de visualiser, documenter et analyser ses représentations.
- Exactitude - SQL vous permet de définir les contraintes du modèle de données, ce qui permet d'éviter diverses violations d'intégrité des données par l'implémentation.
Peut-être que SQL peut être appelé un outil pour décrire l'architecture en termes de stockage de données, mais ce n'est clairement pas suffisant pour décrire l'architecture complète d'un produit.
Autres moyens de décrire l'architecture
L'analogue direct de SQL est GraphQL, qui vous permet également de définir le schéma de données et d'y accéder via le langage de requête. Dans le même temps, GraphQL est construit sur la théorie des graphes, pas sur un modèle d'algèbre relationnelle. Cela permet de travailler avec des modèles de données hiérarchiques de manière plus naturelle, contrairement à SQL, où travailler avec des hiérarchies peut être difficile.
GraphQL est souvent présenté comme une solution de communication client-serveur, mais ce n'est pas le seul domaine de son application. De même, via GraphQL, vous pouvez fournir une communication de serveur à serveur, et même une communication de serveur à base. Le fait que les bases de données modernes fournissent uniquement une interface SQL, mais ne fournissent pas une API pratique pour travailler avec des requêtes hiérarchiques est une omission offensive.
Si SQL est un moyen de décrire l'architecture du schéma de stockage de données, alors GraphQL vous permet de décrire l'architecture du schéma de données déjà au niveau métier, en termes de domaine d'application spécifique. En ce sens, GraphQL vous permet de définir l'Architecture à un niveau supérieur, plus proche du domaine d'application réel du produit.
Les modules de code et les microservices, ainsi que leurs API et leurs dépendances, sont également des véhicules pour exprimer l'architecture en termes de structure et de relations.
Architecture et mise en œuvre
Pour un petit projet avec une douzaine de développeurs travaillant sur, une description séparée de l'architecture n'est souvent pas nécessaire. Si le code du projet est écrit proprement et bien structuré, cela peut suffire à comprendre l'image globale et les directions de développement.
Au fur et à mesure que le projet se développe, divers documents apparaissent, décrivant à la fois son architecture générale et les détails des nouvelles pièces et des améliorations majeures. C'est une approche plutôt fonctionnelle dans le cas où plusieurs dizaines de personnes travaillent sur un projet.
Mais pour un projet assez important, quand il y a des centaines de développeurs, cette approche commence à échouer. Il y a trop de documents et leur contenu commence à diverger de plus en plus de l'implémentation. Il devient de plus en plus difficile d'exprimer ses pensées de la même manière pour tout le monde. Des rassemblements pour des dizaines de personnes sont organisés pour discuter d'une variété de sujets privés, tandis que des changements vraiment importants peuvent être mis en œuvre sans aucune discussion. Tout cela conduit à la nécessité d'organiser de plus en plus de processus, lorsque certains doivent offrir quelque chose, d'autres suivent, d'autres révisent et d'autres encore le font. Bureaucratie. En conséquence, les développeurs commencent à écrire plus de documents et moins de code, et ce n'est pas le problème le plus important.
Bien sûr, il n'y a rien de mal avec la bureaucratie en tant que telle. Dans tout travail, son organisation est importante. Le problème est la quantité de bureaucratie par unité de travail utile. Si, pour en faire une, vous devez tenir deux autres réunions, trois, quatre, cinq, ce n'est plus bon nulle part.
Même la simple question de savoir quel changement le développeur peut faire lui-même, car il s'agit d'une implémentation, et pour laquelle il faut faire une demande de révision, car il s'agit d'une architecture, commence à poser des difficultés. Vous devez trouver une variété de déclencheurs architecturaux, que si vous modifiez le schéma de données ou touchez à des problèmes de cryptographie et de sécurité, cela doit être revu sur le plan architectural, et d'autres sujets ne semblent pas l'être, mais ce n'est pas certain. Tout cela doit non seulement être formulé et expliqué à des centaines de développeurs, mais aussi pour s'assurer que les règles décrites sont respectées. Un tel processus échouera constamment.
Tous ces problèmes sont liés au manque de définition claire de l'architecture.
Tout comme la modification d'un fichier ".java" dans un référentiel indique sans ambiguïté un changement d'implémentation, la modification d'un fichier ".architecture" peut indiquer un changement d'architecture. Bien entendu, les fichiers ".architecture" n'existent pas dans la nature. Mais pour chaque projet, vous pouvez définir quels aspects de celui-ci sont spécifiquement liés à son architecture et le rendre explicite.
Si une modification du schéma de données est considérée comme une modification de l'architecture, les fichiers contenant les migrations SQL doivent faire référence à l'architecture. Si l'API fait également partie de l'architecture, vous pouvez définir l'API sous la forme des mêmes fichiers swagger et compter sur eux. Si la structure des modules est Architecture, alors le changement dans la description des modules est un changement architectural. Etc.
Tous les aspects de l'architecture ne peuvent pas être exprimés par des moyens standard. Chaque projet a ses propres spécificités. Par exemple, si le produit utilise un modèle spécifique de droits, de rôles, de types d'abonnements, de modules complémentaires, etc., alors vous devriez penser à définir l'architecture de cet aspect du produit sous une forme déclarative appropriée, mettant ainsi en évidence l'essence de l'architecture à partir des détails de mise en œuvre. Bien entendu, de telles modifications peuvent nécessiter une refonte importante du code. Mais c'est un investissement nettement meilleur dans la définition d'une architecture de produit que d'essayer de décrire son modèle de droits dans un document.
Une représentation formelle de l'architecture dans le code est possible, et seulement cela donne une définition claire de ce qu'est une architecture. Cette vue permet d'analyser l'architecture et de générer automatiquement une documentation sur celle-ci, qui sera toujours à jour. Tout le reste: documents, schémas et schémas faits à la main - Bureaucratie.
Une architecture peut avoir une expression formelle dans le code, et seul cela définit une frontière claire entre l'architecture et l'implémentation. Et une telle frontière est nécessaire.
Ingénierie et approches évolutives en architecture
Au cours du dernier demi-siècle, l'industrie du développement a parcouru un long chemin, des modèles en cascade au développement itératif. Et maintenant, il semble que l'industrie soit allée trop loin dans ce dossier. Dans certains endroits, le travail d'un architecte ne ressemble plus à celui d'un ingénieur ou même d'un jardinier, et commence de plus en plus à ressembler au travail d'un saisonnier engagé dans le seul but de désherber les lits des mauvaises herbes.
Ce qui distingue l'ingénierie de l'artisanat, c'est la compréhension des lois de la nature, les lois sur la base desquelles on peut faire des calculs et des conclusions, concevoir des solutions et non expérimenter. Tout menuisier peut fabriquer un tabouret parfaitement acceptable, mais des connaissances en ingénierie sont nécessaires pour rendre le tabouret optimal: léger, fiable, stable, simple et bon marché à fabriquer. Une approche d'ingénierie vous permet d'obtenir le résultat optimal rapidement et avec le moins d'effort. Malheureusement, dans le développement de logiciels, une approche d'ingénierie n'est pas toujours possible.
Souvent, le résultat que l'on souhaite obtenir est défini de manière très vague, de nombreux facteurs qui affectent de manière significative l'architecture de la solution ne sont pas clairs ou pas du tout connus, et le travail de mise en œuvre de la solution elle-même peut être plus rapide et moins coûteux que l'élaboration détaillée de son architecture. C'est l'une des raisons pour lesquelles l'approche itérative du développement a gagné une telle popularité. Parfois même au-delà de toute mesure.
Dans le pire des cas, le développement de l'architecture peut se réduire au fait que chaque équipe de développement donne simplement à l'architecte une description de ce qu'elle va mettre en œuvre. Dans une telle situation, le travail d'un architecte se réduit à un désherbage. Et ici vous n'avez pas oublié? En avez-vous tenu compte? Et ici, c'est faux. Voulez-vous ajouter un index ici? Et donc itération après itération.
Il est nécessaire de désherber les mauvaises herbes. Mais à quoi ressemblera un jardin si vous ne faites que cela? Les parterres de fleurs se faneront à l'ombre des arbres fruitiers, les fraises et les carottes alterneront, et tout cela sera parcouru par d'innombrables chemins, gaspillant l'espace disponible. Il est difficile de parler d'une architecture ici.
Pour que l'architecture apparaisse, un architecte doit au moins faire le travail d'un jardinier. Les baies et les légumes doivent être cultivés séparément - la structure, et là où les gens vont le plus souvent, des chemins doivent être tracés - des connexions. En observant les particularités, l'architecte peut agir de manière proactive, en organisant et en systématisant les particularités qui surgissent dans le processus de réalisation en une seule structure. À l'instar de l'aménagement paysager, un architecte peut façonner le cours naturel des événements, en renforçant les tendances positives et en évitant les tendances négatives.
Et ici, nous avons besoin d'une définition claire de l'architecture dans le code. Schémas de données, structures de modules et de services, leur API et règles d'interaction. Sans définir ces outils, l'architecte va soit s'enliser dans une revue d'implémentation, soit espérer naïvement que les développeurs suivront vraiment les règles décrites dans certains documents là-bas, ce qui, bien sûr, ne se produira pas.
S'il y a une présentation formelle de l'architecture et des règles de ses changements, cela peut déjà être appelé une approche évolutive du développement de l'architecture. Et ce n'est pas mal. Mais devrions-nous nous limiter à cela?
Oui, au départ, les exigences peuvent paraître vagues, les facteurs peuvent paraître vagues et le système lui-même est si complexe qu'il est plus facile à faire qu'à concevoir. Mais avec le temps, ces choses commencent à devenir claires. Avec une expérience pratique dans le développement de l'architecture, les détails de l'organisation de son domaine d'application apparaissent de plus en plus clairs. Il devient clair que cette solution générale est mise en œuvre de cinq manières différentes, et que les utilisateurs souffrent d'une telle diversité. Que certaines choses ne sont pas à leur place et doivent être déplacées, tandis que d'autres sont déjà obsolètes et remplacées par de nouvelles solutions, elles doivent donc être supprimées. Et les nouveaux développements ne semblent plus si nouveaux - et nous avons déjà mis en œuvre ceci, et cela. Vous rappelez-vous ce que tout cela a conduit? Faisons-le tout de suite pour ne pas avoir à le refaire plus tard. Après tout, le faire correctement en une fois est généralement plus rapide que nécessaire.Mais ce n'est que si vous savez vraiment comment le faire correctement. Et avec l'expérience, une telle compréhension vient souvent.
La bonne architecture n'est pas quelque chose qui s'est développé par lui-même et qui a ensuite été un peu organisé, mais quelque chose de holistique, symétrique et organique. Une approche technique du développement de l'architecture est possible, la simple compréhension des règles et des modèles peut prendre un certain temps.
La définition formelle de l'architecture d'un projet particulier n'a pas à être statique. Les méthodes d'API obsolètes peuvent être déclarées comme obsolètes et les méthodes manquantes peuvent être déclarées comme non implémentées. Les parties significatives du code peuvent être marquées pour être placées dans des modules séparés. Vous pouvez prévoir de diviser la table en deux ou de les déplacer vers une autre base de données. Etc. L'architecture peut être modifiée sans changer l'implémentation. La mise en œuvre rattrapera son retard. Et pour rattraper plus rapidement, le processus peut être légèrement automatisé en effectuant des rappels automatiques dans les discussions d'équipe. De la même manière, les modifications apportées par les développeurs dans les fichiers architecturaux peuvent automatiquement accéder au chat de l'équipe d'architecture.
Une approche d'ingénierie pour le développement de l'architecture est possible.
En même temps, il ne faut pas supposer que le travail de l'architecte est fondamentalement meilleur ou pire que celui du développeur. Elle est juste différente. Le développeur, tout d'abord, travaille dans le style impératif, tandis que le travail de l'architecte est plus déclaratif. Il arrive qu'il soit difficile d'élaborer l'architecture, mais la mise en œuvre est une routine. Cela se produit également vice versa.
Architecture et design
Les termes Architecture et Design sont souvent utilisés de manière interchangeable. Vous pouvez dire: architecture système ou conception système. Dans l'ensemble, il est clair de quoi il s'agit. Cependant, il existe des différences significatives dans ces termes.
Le design, tout d'abord, signifie quelque chose de visuel, quelque chose qui peut être imaginé ou vu. Schémas, diagrammes, modèles. La conception vous permet de montrer visuellement la relation entre les entités, de tracer des chaînes d'interaction, de voir les différences structurelles et les analogies.
Mais l'architecture n'est pas seulement visuelle, elle peut inclure des règles et des contraintes, des inférences et des calculs mathématiques. Des concepts mal visualisés.
Bien sûr, les deux sont importants.
C'est bien si des aspects importants de l'architecture sont explicitement définis dans le code. Mais ce n'est pas assez. Il est important de rendre l'architecture visuelle et les principes qui y sont inhérents automatiques.
Si l'architecture inclut un schéma de données, il doit y avoir une représentation visuelle de celui-ci. Les modules ont des dépendances - ils doivent également être rendus. S'il existe une API, il doit y avoir une documentation à ce sujet qui est directement liée à la structure des services. Etc. Le design est une représentation visuelle de l'architecture.
Si l'architecture a certains principes, par exemple, «les applications clientes ne peuvent accéder qu'à certains types de microservices, mais pas à tous», alors s'il existe un modèle de communication, elles peuvent être vérifiées automatiquement. De même, vous pouvez contrôler les liens entre les microservices et les bases de données. S'il existe certaines règles pour la conception des modèles de données, les mêmes règles pour nommer les tables, elles peuvent également être vérifiées automatiquement. En développement, des vérifications de code automatiques sont utilisées, la même chose peut être faite pour l'architecture. Vous pouvez écrire des autotests sur l'architecture.
Conclusion
Le développeur moderne dispose d'une vaste gamme d'outils étonnants pour faciliter son travail. Environnements de développement, systèmes de construction, diverses bibliothèques et cadres, services d'infrastructure et conteneurs. Les développeurs n'écrivent pas de code dans le Bloc-notes.
L'architecture est aussi du code, et pour travailler avec l'architecture, il existe une boîte à outils aussi puissante et riche que pour travailler avec l'implémentation. Google Docs n'est pas le seul outil d'architecture que vous pouvez utiliser, et il est loin d'être le meilleur. Bien entendu, la gamme d'outils prêts à l'emploi dont dispose actuellement l'architecte n'est pas aussi large que la gamme d'outils de développement. Et tout ce qu'un architecte peut potentiellement utiliser ne fonctionne pas immédiatement. Pourtant, les choses ne sont pas si mauvaises.
De nombreux outils existent depuis des décennies, comme SQL, il vous suffit d'apprendre à les utiliser correctement. Les nouvelles technologies telles que GraphQL commencent à gagner du terrain, et elles offrent l'espoir que la tâche de décrire un domaine d'entreprise deviendra aussi banale au fil du temps que de décrire un domaine de stockage. Des outils de documentation et de visualisation de la structure de l'application et de l'API sont disponibles, y compris Swagger. Vous pouvez utiliser les mêmes frameworks et outils d'intégration pour tester l'architecture que vous le feriez pour tester l'implémentation.
Architecture - Déclarative. Probablement, la bureaucratie du travail avec des documents ne disparaîtra jamais complètement du travail d'un architecte, mais déjà maintenant son volume peut être considérablement réduit. L'architecture est aussi du code, et avec le temps, les outils disponibles pour travailler sur l'architecture peuvent devenir aussi avancés que les outils pour travailler sur l'implémentation. Nous verrons.
-
Dmitry Mamonov,
Wrike
PS J'ai commencé l'article par une liste de questions philosophiques auxquelles, je l'espère, j'ai pu donner des réponses assez précises. Du moins, c'est mon point de vue. Avez-vous trouvé quelque chose d'utile ou de nouveau dans l'article? Comment répondez-vous vous-même à ces questions? Écrivez dans les commentaires.