L'architecture logicielle est surestimée, la conception simple est sous-estimée

Nous vous proposons la traduction du poste de Gergel Oros, qui occupe le poste de directeur technique chez Uber. Il y partage son point de vue sur la conception de systèmes à grande échelle, basé sur sa propre expérience pratique dans Uber et Microsoft. Combiné avec des commentaires sur Hacker News , qui ajoutent des contre-arguments de poids et complètent le point de vue de l'auteur, son article est devenu l'un des articles les plus intéressants de la semaine. Le terme «conception de code» est utilisé dans l'article pour comparer avec «l'architecture» traditionnelle - vous en trouverez plus à ce sujet ici .

J'ai suffisamment d'expérience dans la conception et la création de systèmes à grande échelle. J'ai participé à la réécriture du système de paiement distribué chez Uber, à la conception et à la publication de Skype sur la Xbox One, et à la publication des RIB disponibles au public, un cadre d'architecture mobile créé par Uber. Tous ces systèmes avaient une conception soigneusement pensée, ont subi plusieurs itérations, et de nombreuses réunions ont eu lieu sur le tableau blanc et d'autres discussions. Ensuite, la conception a abouti à un document de conception, qui a été distribué aux autres développeurs pour recueillir des commentaires supplémentaires, qui s'est poursuivi jusqu'à ce que nous passions au développement.

Tous ces systèmes étaient à grande échelle: des centaines de développeurs les ont créés - ou ils les ont utilisés dans leurs conceptions - et aujourd'hui, ils battent dans le cœur des systèmes que des millions de personnes utilisent chaque jour. De plus, ces projets n'ont pas été créés à partir de zéro. Le système de paiement était censé remplacer deux autres systèmes de paiement existants utilisés par des dizaines d'autres systèmes et des dizaines d'équipes, le tout sans nuire à l'entreprise. La réécriture de l'application Uber était un projet sur lequel plusieurs centaines d'ingénieurs ont travaillé en même temps - il comprenait le portage de toutes les fonctionnalités existantes vers la nouvelle architecture.

Permettez-moi de commencer par quelque chose qui peut sembler inattendu. Premièrement, nous n'avons jamais utilisé d'outils de planification d'architecture logicielle standard pour travailler sur la conception de ces systèmes. Nous n'avons utilisé ni UML , ni le modèle 4 + 1 , ni ADR , ni C4 , ni les diagrammes de dépendance . Nous avons dessiné de nombreux diagrammes, mais aucun d'entre eux n'a suivi de règles strictes. Seuls de bons vieux rectangles et flèches étaient nécessaires - et nous avons obtenu des diagrammes similaires à celui-ci, qui décrit les flux d'informations , ou un autre, qui décrit la structure de la classe et la relation entre les composants . Deux graphiques dans le même document de conception avaient souvent un style différent, car ils étaient souvent ajoutés ou modifiés par des personnes différentes.

Deuxièmement, nous n'avions pas d'architectes à qui appartiendrait la conception. Il n'y avait ni architecte informatique ni architecte d'entreprise . C'est vrai - ni Uber, ni Skype / Mircrosoft n'ont un poste à plein temps pour les architectes logiciels. Les ingénieurs de niveau supérieur, tels que ceux qui occupent le poste d'ingénieur d'état-major, doivent toujours écrire du code régulièrement. Tous nos projets ont des ingénieurs expérimentés - cependant, pas une seule personne ne possède l'architecture ou la conception seule. Alors que des ingénieurs expérimentés ont été le moteur du processus de conception, d'autres développeurs ont été impliqués dans la discussion, y compris même le «juin» vert - en outre, ils ont souvent contesté les décisions des autres et ont proposé d'autres options de discussion.

Troisièmement, nous n'avons presque jamais fait référence à des modèles architecturaux courants et à d'autres jargons généralement acceptés, qui sont utilisés dans la littérature populaire sur l'architecture logicielle comme le manuel de Martin Fowler . Il n'y avait aucune référence aux microservices, à l'architecture sans serveur, aux limites d'application , à l'architecture événementielle ou à quoi que ce soit d'autre. Certains de ces termes sont apparus lors des séances de brainstorming; cependant, nous n'avons pas eu besoin de les mentionner nous-mêmes dans la documentation de conception.

Conception de logiciels dans les entreprises technologiques et les startups

Alors, comment avons-nous géré tout? Et pourquoi n'avons-nous pas suivi des approches communes de l'architecture logicielle?

J'ai discuté de ce problème avec des collègues ingénieurs travaillant dans d'autres sociétés technologiques - à la fois les tailles FANG (Facebook, Amazon, Netflix, Google) et les petites startups. La plupart des équipes et des projets - qu'ils soient grands ou petits - ont combiné une approche similaire de conception et de mise en œuvre:

1. Commencez par une tâche commerciale. Quel problème essayons-nous de résoudre? Quel produit essayons-nous de créer et pourquoi? Comment mesurer son succès?
2. Réfléchissez à «l'approche» choisie. Réunissez-vous avec l'équipe et trouvez une solution de travail en quelques séances. Ne tardez pas trop avec cette phase. Commencez par le niveau supérieur et abaissez-vous progressivement jusqu'aux niveaux inférieurs.
3. Dessinez votre approche au tableau. Rassemblez l'équipe et laissez l'un d'entre vous décrire l'approche à laquelle l'équipe se penche. Vous devez être en mesure d'expliquer clairement l'architecture de votre système / application à l'aide d'une carte - à partir du plus haut niveau et, si nécessaire, de plus en plus bas. Si vous avez des difficultés avec une explication ou si ce n'est pas assez clair pour vos collègues, vous devez mieux comprendre les détails de votre décision.
4. Corrigez-le sous la forme d'une documentation simple avec des diagrammes simples basés sur ce que vous avez expliqué précédemment avec le tableau blanc. Gardez le jargon au minimum: vous voulez que même les juniors comprennent ce qui se dit. Utilisez un langage clair et facile dans votre description . Chez Uber, nous utilisons un document de type RFC basé sur un modèle simple.
5. Discutez des compromis et des alternatives . Une bonne conception logicielle et une bonne architecture sont le bon choix pour les compromis. En soi, aucun des choix de conception n'est mauvais ou bon: tout dépend du contexte et des objectifs. Votre architecture est-elle divisée en différents services? Mentionnez la raison pour laquelle vous avez décidé de ne pas proposer un seul gros service, auquel il pourrait y avoir d'autres avantages comme un déploiement plus simple et plus rapide. Avez-vous décidé d'étendre le module ou le service avec de nouvelles fonctionnalités? Au lieu de cela, pesez la possibilité de développer un service ou un module distinct, et quels sont les avantages et les inconvénients de cette approche.
6. Distribuez le document de conception au sein de l'équipe / organisation et recueillez les commentaires. Auparavant, chez Uber, nous avons envoyé tous les documents de conception du logiciel à tous nos ingénieurs - jusqu'au moment où notre personnel comptait 2 000 personnes. Maintenant que nous avons atteint une telle échelle, nous essayons toujours d'atteindre le plus large public possible - mais en même temps, nous avons commencé à nous assurer que le niveau de bruit de l'information ne dépasse pas la limite autorisée. Encouragez les autres à poser des questions et à suggérer des alternatives. Soyez pragmatique quant aux délais pour discuter des commentaires et les inclure dans le document si nécessaire. Des souhaits spécifiques peuvent être appliqués immédiatement et rapidement, tandis que les commentaires détaillés sont mieux à démonter avec une personne en personne.

Pourquoi notre approche est-elle différente de ce qui est habituellement mentionné dans la littérature sur l'architecture logicielle? En fait, notre approche n'est fondamentalement pas si différente de ce qui est décrit dans les manuels d'architecture. Presque tous les manuels suggèrent de commencer par une tâche commerciale, ainsi que de décrire les solutions et les compromis - nous le faisons aussi. Ce que nous ne faisons pas, ce n'est pas d'utiliser des outils plus sophistiqués que de nombreux architectes et livres d'architecture préconisent. Nous documentons la conception le plus simplement possible, en utilisant les outils les plus simples et les plus évidents, tels que Google Docs ou Office 365.

Je pense que la principale différence dans notre approche réside dans la culture d'ingénierie des différentes entreprises. Un haut degré d'autonomie et une hiérarchie minimisée est une caractéristique commune aux entreprises technologiques et aux startups; dans le cas des entreprises plus traditionnelles, cela est loin d'être toujours vrai. C'est aussi la raison pour laquelle, dans ces endroits, ils ont souvent recours à une «conception basée sur le bon sens» au lieu d'une conception basée sur un processus avec des règles strictes.

Je connais des banques et des constructeurs automobiles, où les développeurs sont activement découragés de prendre des décisions architecturales sans avoir à monter dans la chaîne, obtenir l'approbation des architectes à plusieurs niveaux, qui supervisent plusieurs équipes. Cela ralentit le processus et, avec un grand nombre de demandes, les architectes sont surchargés. Par conséquent, ces architectes créent des documents encore plus formels, dans l'espoir que le système deviendra plus compréhensible - en utilisant tous les outils que la littérature que vous connaissez vous décrit. Ces documents sont soutenus par une approche descendante, car ils agissent sur des ingénieurs intimidants - ils ne sont pas des architectes et ne doivent pas douter ni contester les décisions, car ils ont déjà été documentés à l'aide de méthodes formelles dans lesquelles ils sont mal maîtrisés. Par conséquent, ils ne le font généralement pas. Honnêtement, ces entreprises font de même pour faire des développeurs une ressource interchangeable, car cela leur permet de transférer des personnes d'un projet à un autre en peu de temps. Ce ne sera probablement pas une surprise pour vous que différents outils soient mieux adaptés à différents environnements.

Conception logicielle simple sans jargon au lieu de motifs architecturaux

L'objectif de la conception du système doit être la simplicité. Plus le système est simple, plus il est facile à comprendre - et plus il est facile d'y trouver des problèmes et de le mettre en œuvre. Plus le langage par lequel il est décrit est clair, plus sa conception est accessible. Évitez d'utiliser un jargon que chaque membre de l'équipe ne comprendra pas - même les plus inexpérimentés de vos collègues devraient être en mesure de comprendre ce qui est en jeu au niveau des autres.

Un design épuré est comme un code propre: il est facile à lire et à comprendre. Il existe de nombreuses façons d'écrire du code propre. Cependant, vous entendrez souvent que quelqu'un suggère de commencer par appliquer des modèles de conception «gang de quatre» à votre code. Un code propre commence par le principe de la responsabilité exclusive, des noms clairs et des conventions faciles à comprendre. Ces principes s'appliquent également à l'architecture pure.

Quel est donc le rôle des modèles architecturaux? Je les trouve utiles - tout aussi utiles que les modèles de conception de code. Ils peuvent vous donner des idées sur la façon dont vous pouvez améliorer votre code ou votre architecture. Prenez des modèles de conception de code: je remarque par moi-même quand je remarque un singleton dans le code - et je lève les sourcils et je creuse plus profondément quand je vois une classe qui se comporte comme une façade , mais en fait, elle ne fait que des appels. Mais le jour n'est pas encore venu où j'aurais pensé: "une usine abstraite ne fait que le demander ici". En vérité, il m'a fallu beaucoup de temps pour comprendre ce que fait ce schéma et avant qu'il ne me vienne à l'esprit; la compréhension est le résultat d'un travail acharné avec l' injection de dépendance , l'un des rares domaines où ce modèle est répandu et extrêmement utile . J'avoue également que même si j'ai passé beaucoup de temps à lire et à comprendre les modèles de conception du «gang des quatre», ils ont eu beaucoup moins d'influence sur mon développement professionnel en tant que programmeur que les commentaires que j'ai reçus d'autres développeurs concernant mon code.

De même, connaître les modèles architecturaux communs est une bonne chose: cela permet de réduire le temps passé dans les discussions avec des personnes qui les comprennent de la même manière que vous. Mais les modèles architecturaux ne sont pas le but, et ils ne remplaceront pas les options de conception de système plus simples. Lorsque vous concevez un système, vous pouvez soudainement réaliser que vous avez accidentellement appliqué un modèle commun - et c'est bien, car plus tard, il vous sera plus facile de vous référer à l'approche utilisée. Mais vous ne devez jamais prendre un ou plusieurs motifs et les utiliser comme un marteau, pour lequel vous verrez toujours des clous.

Les modèles architecturaux ont vu le jour lorsque les ingénieurs ont attiré l'attention sur le fait que, dans certaines situations, il était logique de prendre des décisions similaires concernant la conception et sa mise en œuvre. Au fil du temps, ces décisions ont reçu des noms, ont été enregistrées et discutées par le grand public. Les modèles architecturaux sont des outils qui sont apparus après la recherche de solutions, dans l'espoir que cela faciliterait la vie des autres. En tant qu'ingénieur, vous devez définir comme objectif une recherche indépendante de solutions à vos problèmes et apprendre au cours de ce processus - au lieu de prendre un modèle architectural «hype» dans l'espoir que cela résoudra votre problème.

Comment apprendre à mieux concevoir des systèmes

Les gens me demandent souvent des conseils: comment "pomper" dans l'architecture et la conception des systèmes? Les ingénieurs expérimentés recommandent généralement de lire sur les modèles architecturaux, ainsi que des livres sur l'architecture logicielle. Je soutiens pleinement la recommandation de lire autant que possible - en particulier les livres, car ils vous permettent de plonger dans le sujet beaucoup plus profondément que les messages courts - cependant, j'ai quelques recommandations plus pratiques.

• Engagez l'un des membres de l'équipe et faites du tableau blanc ensemble. Dessinez au tableau ce sur quoi vous travaillez et expliquez la signification de l'image. Assurez-vous que vos collègues comprennent ce qui se dit. Et quand vous serez enfin compris, demandez des commentaires.
• Décrivez votre conception dans un document simple et partagez-la avec votre équipe en lui demandant des commentaires. Peu importe la simplicité ou la complexité de la tâche sur laquelle vous travaillez - il peut s'agir d'un petit refactoring ou d'un projet à grande échelle - vous devez le résumer de manière concise. Faites-le de telle manière que ce document soit logique pour vous et pour le reste compréhensible; d'inspiration - voici un exemple de la façon dont cela se fait dans Uber . Partagez ce document avec votre équipe dans un format qui permet de commenter - par exemple, en utilisant Google Docs, Office 365 ou quelque chose de similaire. Demandez aux autres de le compléter avec leurs pensées et leurs questions.
• Créez deux motifs différents et contrastez-les. Lorsque la plupart d'entre nous concevons l'architecture, ils vont généralement dans un sens: celui qui apparaît dans leur tête. Cependant, l'architecture n'est pas quelque chose de noir et blanc. Trouvez une deuxième option de conception d'architecture qui pourrait également fonctionner dans votre situation. Comparez les deux modèles et expliquez pourquoi l'un est meilleur que l'autre. Indiquez que vous avez envisagé la deuxième option pendant un certain temps comme alternative et expliquez pourquoi vous avez pris une décision qui n'était pas en sa faveur.
• Décidez des compromis que vous êtes prêt à faire - découvrez pourquoi vous les acceptez et ce que vous souhaitez réaliser avec leur aide. Établissez clairement les restrictions existantes que vous avez dû prendre en compte.
• Examinez les conceptions d'autres personnes. Et faites-le sagement. Si votre entreprise a une culture de partage de conceptions que les gens partagent à l'aide de tableaux blancs, de réunions ou de documents, obtenez-en plus. Habituellement, lors d'une revue, les gens perçoivent la conception du code de quelqu'un d'autre comme des observateurs; au lieu de cela, posez des questions de clarification pour les parties que vous ne comprenez pas très bien. Demandez quelles alternatives ils ont envisagées. Demandez quels compromis ils ont faits et quelles limitations ils ont envisagés. Soyez l'avocat du diable et suggérez une autre alternative, peut-être plus simple - même si elle n'est pas meilleure que leur solution - et demandez-leur ce qu'ils pensent de votre proposition. Même si vous n'avez pas si bien pensé votre conception par rapport à celui qui la présente, votre discussion peut encore apporter quelque chose de nouveau et vous aider à mieux comprendre la tâche que vous faites.

La meilleure conception de logiciel est simple et facile à comprendre. La prochaine fois que vous lancerez un nouveau projet, au lieu de réfléchir à la question: « Comment vais-je concevoir ce système, quels modèles dois-je utiliser au combat et avec quelle méthodologie officielle dois-je le documenter? », Pensez - « Comment puis-je arriver à la conception la plus simple possible - qui sera facilement comprise par n'importe qui? "

Les meilleures pratiques d'architecture logicielle, les modèles architecturaux des applications d'entreprise, les façons formelles de décrire les systèmes sont tous des outils utiles à posséder, car un jour ils peuvent vous être très utiles. Mais lors de la conception de systèmes, cela vaut la peine de commencer par un système simple et de rester aussi simple que possible. Essayez d'éviter la complexité que les architectures plus complexes et les outils formels apportent inévitablement à vos systèmes.

Ce message a provoqué une discussion animée parmi les travailleurs de l'industrie qui ont partagé leurs expériences et leurs attitudes envers l'architecture logicielle. Vous pouvez lire ces discussions sur Hacker News , Lobste.rs et Reddit .

Alors que la plupart des commentateurs sont d'accord avec le message principal de l'article, d'autres notent qu'en réalité une telle approche peut être mal applicable au monde de "l'entreprise sanglante", où les architectes "mangent leur pain" pour une bonne raison; ils se demandent à quoi ressemblera un système ainsi conçu 20 ans plus tard et rappelleront la «théorie des fenêtres cassées», et parlent également de l'intégration de 300 systèmes informatiques , qui par définition ne peuvent pas être simples - car chacun d'eux a une API unique, certains systèmes travaille sur Kobol et chacun d'eux sert de 5000 à 7000 opérateurs.