Traditionnellement, le processus de développement logiciel est comparé à la construction. Le terme «architecte» ne fait que renforcer le lien associatif entre ces processus. Mais les réalités modernes ont rendu ce modèle hors de propos, car il existe des mécanismes qu'il ne peut expliquer:
- Si nous fabriquons une sorte d'objet ou de produit physique, alors pourquoi le logiciel n'est-il jamais considéré comme complet?
- Si nous parlons de solutions d'ingénierie, alors pourquoi ne pouvons-nous jamais planifier en toute confiance?
- Si nous sommes architectes ou constructeurs, pourquoi tant de projets se soldent-ils par un échec?
- Et enfin, avec tant de conseils, de bonnes pratiques, de principes, de livres et de rapports de développement de logiciels, pourquoi tant de projets deviennent-ils un lieu de travail insupportable?
Je propose une traduction du brillant rapport de Sarah May «Code habitable», qui est proche du texte, où elle examine toutes ces questions.
Pourquoi est-il important d'avoir un modèle?
Le modèle nous permet de faire une analogie entre un processus inconnu ou difficile à comprendre et quelque chose de familier, compréhensible pour nous. De plus, il devrait non seulement convenir à la description d'une situation où tout va bien, mais, comme toute bonne analogie, le modèle devrait nous guider dans des situations limites.
Le processus de développement logiciel est une combinaison de deux entités liées, en interaction mais néanmoins distinctes: le code et l'équipe.
La confirmation de ceci est la loi de Conway. La relation de ces entités nous indique que les problèmes dans le code sont liés à des problèmes dans l'équipe et vice versa. Par conséquent, nous avons deux options pour les résoudre: côté code et côté équipe.
Certains problèmes semblent être des problèmes uniquement avec le code, d'autres uniquement avec l'équipe. En fait, tous sont des problèmes avec les deux composants. Par conséquent, le nouveau modèle devrait être adapté aux réalités modernes et refléter la relation entre les deux composantes du processus de développement.
Description du nouveau modèle
L'espace dans lequel l'application vit
La construction du bâtiment comporte trois étapes distinctes: la conception, la construction et l'entretien. Auparavant, le développement de logiciels ressemblait: le résultat du développement était un produit fini. Il a été installé par l'utilisateur et transféré pour prendre en charge un groupe distinct, et les développeurs ont commencé à faire autre chose.
Mais dans le monde des applications Web, des déploiements et des versions plusieurs fois par jour, en fait, rien n'est complet. Une situation similaire est observée dans les applications mobiles et les jeux, lorsqu'ils sont automatiquement mis à jour sur la console via Steam (le plus souvent au moment le plus inopportun). De plus, dans un environnement commercial en évolution, les applications doivent être flexibles et capables de changer. L'effort de développement doit être énorme pour garantir cette flexibilité. On ne peut pas attendre la même chose des bâtiments.
L'infrastructure que nous utilisons lors du développement d'applications ressemble plus à un bâtiment. Ce que nous créons n'est pas les bâtiments eux-mêmes, car la plupart des applications d'application prennent de la place dans des structures pré-érigées. Cela ressemble à un passage des architectes aux architectes d'intérieur, mais il y a beaucoup de puissance dans un tel modèle. Les bâtiments sont la base de nos applications: la base est l'OS, le niveau de stationnement est le langage de programmation, le bâtiment lui-même est le cadre utilisé et nous développons des applications déjà à l'intérieur.
L'espace interne (structure) fourni par les bâtiments est modifiable, mais il est plus difficile de le changer que votre propre code. Autant la démolition du mur est plus difficile que de déplacer le mobilier. Ainsi, le bâtiment lui-même (charpente) impose certaines restrictions sur les capacités et l'apparence de votre intérieur (application).
Chaque bâtiment est optimisé pour ses propres besoins. Une application peut être placée dans n'importe lequel d'entre eux, mais certains espaces y seront mieux adaptés, et certains seront pires. Par conséquent, le code que vous allez placer dans un espace préformé sera généré d'une certaine manière par cet espace.
Il y a encore énormément de travaux de construction dans notre industrie, mais la plupart d'entre nous travaillent toujours sur les intérieurs (applications).
Nouvel objectif en développement
Si vous ajoutez à tout cela que les projets ne sont jamais considérés comme terminés, vous arrivez à la conclusion que le code n'est pas ce que nous construisons, mais où nous vivons . Cela vous fait regarder l'objectif même du développement sous un angle différent. L'endroit où nous vivons doit être rendu habitable : adapté, confortable et confortable pour vivre. Et pas seulement pour nous-mêmes, mais aussi pour ceux qui vivent avec nous. Dans le cas du code, il ne suffit pas de terminer le produit et de continuer. Il doit également être rendu vivable : compréhensible, soutenu, extensible - pour l'équipe qui «y vit».
Qu'est-ce que le code habitable?
Habitable par rapport à la maison signifie que vous vivez dans un espace où vous pouvez faire des activités quotidiennes avec confort et facilité. Il y a une lampe de lecture dans la chambre, des serviettes sont sur la table basse, il y a une boîte pour les joysticks dans le salon et il y a un porte-vélo dans le couloir.
Mais ce que signifie vivre pour un groupe de personnes dépend d'eux-mêmes. Une maison confortable pour les jeunes parents avec un enfant n'est pas comme une maison pour étudiants ou pour personnes âgées, ni pour un parent seul avec un adolescent.
Habitable pour le code signifie la même chose: vous pouvez changer ou ajouter ce que vous voulez, mais sans trop de complexité et d'agacement. Vous comprenez où se trouve, alors sautez facilement au bon endroit dans le code et travaillez avec. Ici, le principe est le même: le fait que vivre pour une équipe ne convient pas à une autre. Ce qui est habitable pour un senior et quatre juniors diffère de ce qui est habitable pour cinq seniors, et est très différent de ce qui est habitable pour une équipe externalisée.
Les gens vont et viennent, donc créer et maintenir du code dans un état habitable est un processus continu. L'apparition d'un nouveau membre de l'équipe s'apparente à un nouvel appartement voisin: il a un étrange canapé, qu'il aime vraiment pour une raison quelconque, vous acceptez donc à contrecœur de le mettre dans le salon. Et après quelques jours, un voisin suggère de remplacer les rideaux et les stores, car il y en a plus ergonomiques. Et le pire, c'est qu'il lave la vaisselle avec des languettes au lieu d'espaces! 
Mais maintenant, vous vivez ensemble, vous devez donc négocier.
Il s'avère que votre humeur et votre condition dépendent davantage de ceux avec qui vous vivez que de choses spécifiques dans l'appartement et encore moins de son agencement. Aussi avec le code: votre bien-être dépend principalement de ceux avec qui vous travaillez, et encore moins du code lui-même ou du framework.
Comment un projet devient encombré
Mais que faire si votre code ressemble à cette pièce? Comment le rendre adapté à l'équipe? Par où commencer?
D'accord, il est difficile de se déplacer ici, sans parler de comprendre comment mettre les choses en ordre. Pourquoi les maisons atteignent-elles cet état? On dit souvent que c'est de la paresse. Les psychologues pensent différemment: la maison entre dans un tel état en raison d'une série de mauvaises décisions apparemment insignifiantes.
Imaginez comment tout cela pourrait commencer. Il y a une petite pièce dans laquelle vous avez essayé d'optimiser l'espace: ajouté plusieurs étagères et tiroirs, utilisé un rebord de fenêtre. Pendant un moment, tout allait bien: vous avez gardé l'ordre tous les jours. Mais la soirée est venue après une dure journée où vous n'êtes pas sorti. Le matin, vous avez dormi trop longtemps, et quand vous êtes rentré chez vous, vous avez dîné juste à votre bureau et oublié de retirer l'assiette. Les parents ont apporté vos vieux trucs le week-end. Nous n'avons pas eu le temps de les démonter et vous avez mis les boîtes telles quelles. Et vous sentez que la pièce n'est plus en ordre, mais son état est si déprimant que vous ne pouvez pas savoir par où commencer pour corriger la situation et elle se transforme rapidement en informatique. Une série de petites mauvaises décisions: la salle est déjà un gâchis terrible, pourquoi ne pas jeter des livres par terre?
La même chose se produit avec le code. Vous ouvrez un fichier déjà mauvais, une demi-douzaine de modèles qui ne fonctionnent plus. Et le gestionnaire se tient derrière vous, attendant que le bug soit corrigé. La première chose qui me vient à l'esprit est de corriger le bug avec la bande autant que possible et de sortir d'ici le plus tôt possible.
Ces solutions locales apparemment petites sont exactement ce qui rend le code invivable . Cependant, il existe des moyens de sortir de ce trou, que nous creusons pour nous-mêmes.
Le salut par le changement d'habitudes
Avez-vous remarqué que dans la plupart des maisons encombrées et soignées, il y a souvent de nombreux magazines, coupures de journaux avec de beaux intérieurs confortables? Il y a aussi des photos, des projets, des conseils pour l'aménagement compétent de l'espace de vie.
Les gens qui vivent dans des maisons encombrées veulent vivre différemment, ils regardent tous ces magazines et veulent le même intérieur, mais ils ne savent pas comment y parvenir. Et ils pensent que seule une décision cardinale, un événement leur permettra de rendre leur maison la même que sur la photo.
Il y a une émission Hoarders à la télévision américaine. Les personnes vivant dans un gâchis éternel acceptent de participer, afin qu'une équipe de professionnels nettoie et réalise un intérieur design dans leur maison. Et bien, comme toujours, à la fin du programme, de belles photos AVANT et APRÈS. Fait intéressant, la plupart des participants admettent qu'en fin de compte, leur maison est revenue à son état d'origine. C'est simple: la même séquence de petites décisions incorrectes les a conduits au résultat précédent.
Il s'avère qu'un moyen plus efficace consiste à travailler progressivement plus longtemps, non pas avec le contenu de la maison, mais avec les gens eux-mêmes. Le but est de changer leurs habitudes afin de faire du maintien de l'ordre une partie de leur vie quotidienne. Malheureusement, les producteurs trouveraient cette option trop ennuyeuse pour une émission de téléréalité.
Le code encombré se comporte de la même manière: nous le combattons tous les jours, uniquement pour résoudre le problème actuel, et rêvons de tout réécrire. Maintenant, si nous pouvions tout refaire, nous ne ferions certainement pas les mêmes erreurs! Nous devons réécrire jQuery sur Ember! Il faut couper le monolithe en microservices!
Parfois, cela fonctionne, au moins assez longtemps pour écrire un article de blog triomphant. Mais alors la lumière s'éteint, les caméras cessent de fonctionner, l'équipe de tournage quitte le site, et si vous n'avez pas changé vos habitudes, vous êtes à nouveau en désordre et encore plus vite que vous ne le pensez.
Les gens pensent que de grosses erreurs nous tuent: la maison est trop petite, l'agencement est infructueux, le mauvais cadre, le monolithe, pas assez de ressources. Ce n'est pas le cas. Nous sommes tués par ces très petites décisions qui sont causées par les habitudes et la façon de penser.
Vous pouvez réécrire tout ce que vous voulez. Mais, si votre équipe ne change pas ses habitudes, vous vous retrouverez dans un réseau complexe de microservices, tout comme vous aviez un réseau complexe de classes et de modules dans un monolithe.
Habitudes d'équipe
Il est à noter que nous ne parlons pas d'individu, mais d'habitudes et de normes d'équipe. Cela explique pourquoi l'image du développeur en tant que professionnel individuel, artisan ne reflète pas la réalité. Ce n'est pas un développeur séparé paresseux et non professionnel. Il s'agit d'une équipe avec une culture de travail d'équipe boiteuse.
Tout comme avec les colocataires: tout le monde devrait effectuer le nettoyage quotidien, laver la vaisselle après lui-même, nettoyer périodiquement la salle de bain et les toilettes, nettoyer le salon commun. Mais il existe des activités plus complexes pour augmenter la qualité de vie , qui ne peuvent être laissées "qu'aux intéressés". Par exemple, l'emportez sur les armoires de cuisine ou choisissez une table appropriée dans le salon au lieu d'être trop encombrante.
Mais le travail quotidien est ce que chacun doit faire. Autrement dit, vous pouvez avoir des personnes dans l'équipe qui sont intéressées par le refactoring architectural global, fractionnant des modules trop grands, optimisant les interactions entre eux et ceux qui ne veulent pas le faire. Tout le monde n'est pas obligé de participer au réaménagement des meubles, mais tout le monde doit laver la vaisselle.
Deux extrêmes sont invivables ou pourquoi les livres ne fonctionnent pas
Intérieur magnifique, n'est-ce pas? Tout est parfaitement assorti et pensé, rien de plus. En un mot - un rêve. Tout comme une description de modèles montrant une belle version d'un code parfaitement cohérent et parfaitement abstrait. Si beau que l'œil se réjouit.
Oui, l'appartement sur la photo est magnifique, mais vous ne pouvez pas y vivre. Les appartements des pages des magazines sont intentionnellement privés d'encombrement, car l'encombrement est quelque chose d'individuel.
En quoi consiste ce gâchis, c'est différent pour tout le monde. Si vous aimez lire, ce sont des livres, si vous aimez les jeux informatiques, c'est une console et des joysticks, et si vous aimez les activités de plein air, c'est un vélo ou un kayak. Les choses que vous utilisez doivent être à portée de main, vous devez donc supporter un certain désordre. L'essentiel est qu'il ne devrait pas y en avoir trop.
Les magazines sur les beaux intérieurs dans le monde du développement de logiciels affichent un code d'une pureté irréaliste et définissent donc les mauvaises directives. Ce sont des livres sur le développement de logiciels, les modèles de conception, des conseils de blogs et des articles. Un code qui satisfait toutes leurs exigences, parfaitement cohérent et abstrait - n'est pas viable dans le monde réel. Même si vous parvenez à y parvenir, vous ne pouvez pas y vivre.
Nous avons besoin d'un petit désordre pour nous sentir à l'aise. Cela est vrai pour l'appartement et le code.
Les deux extrêmes sont invivables . Si vous avez un morceau de code que vous ne comprenez pas et ne savez pas comment travailler avec, alors c'est à l'un de ces extrêmes. Soit il est trop jonché qu'il est impossible de distinguer les idées appropriées des idées inappropriées, soit il est si pur qu'il est tout simplement impossible de trouver des idées appropriées.
De plus, ces deux extrêmes peuvent exister simultanément dans le même projet. Parfois même à proximité les uns des autres. Le code habitable se situe quelque part entre les deux. En plus d'un espace de vie confortable, il se situe entre les photos des couvertures de magazines et les appartements encombrés.
Par conséquent, vous devez être en mesure de prendre un peu d'encombrement, car cela rend l'espace habitable .
Manifeste
Vous pouvez dire: «C'est tout, bien sûr, très intéressant, mais que se passe-t-il si mon code est déjà en plein désarroi? Ou si le projet n'est pas si mauvais, mais je veux être sûr qu'il ne va pas dans la mauvaise direction? »
Supposons que votre code ressemble à un ancien salon encombré avec des chemins de compréhension étroits pour les chèvres qui le traversent. Ne vous inquiétez pas, vous n'êtes pas une mauvaise personne - cela peut arriver à tout le monde.
Si vous regardez le problème d'un point de vue technique, il crie simplement: «Réécrivez! Comment est-il possible d'organiser quelque chose dans un tel endroit sans espace libre? Retirez tout d'ici et recommencez! »Cette planification descendante convient bien à certaines tâches d'ingénierie, mais pas à la plupart des logiciels. Ce n'est pas parce que nous sommes de mauvais ingénieurs ou que nous essayons mal, mais parce que dans notre domaine, l'approche d'ingénierie ne fonctionne pas. Et le code fonctionne comme un espace dans lequel les gens vivent. Vous devez comprendre que les gens sont exactement ce sur quoi vous devez travailler.
Voici comment procéder. Il y a quatre règles qui s'appliquent à n'importe quel langage et cadre.
Ne fais pas de mal
Presque comme en médecine. Lorsque vous ouvrez un fichier déjà encombré, promettez de ne pas l'aggraver. Même si vous n'avez pas le temps de réparer ces choses qui sont déjà terribles. Si, lors d'une révision de code, vous voyez comment une personne viole cette règle, rappelez-lui simplement ce que vous avez convenu.
Croyez en des améliorations cohérentes
Une pile de cinq livres par terre et une rangée dans une bibliothèque vaut mieux qu'une pile de six livres. Peut-être que celui qui touchera ce code la prochaine fois passera un autre livre du tas à l'étagère. Si vous attendez le temps de les mettre tous en même temps, cela ne se produira jamais.
L'utilisation de cette approche peut être problématique. Les améliorations successives sont difficiles pour beaucoup, elles continuent donc à vivre avec un désir ardent de réécrire complètement un module, un sous-système ou une application. En conséquence, la pile de livres ne diminue pas et reste au sol d'itération en itération.
Faites de l'entretien ménager une partie du flux de travail
Ne démarrez pas les user stories pour le refactoring. N'attendez pas deux semaines pour corriger un fichier. Apprenez à intégrer des règles simples dans votre travail quotidien. La règle du scout dit: laissez le camp plus propre qu'avant votre arrivée. Si vous le suivez constamment, éliminez progressivement les «mauvaises habitudes».
Restez en contact
Soyez prêt à toujours communiquer avec chaque membre de l'équipe sur ce que vous faites. Le paragraphe précédent ne signifie pas que vous devez cacher ce que vous faites. Vous avez juste besoin d'envisager une refactorisation et de mettre les choses en ordre dans le cadre de tout ce que vous faites.
Lorsque vous refactorisez:
- Ne demandez pas la permission. Cela fait partie de votre travail. Mais soyez ouvert à discuter de vos décisions.
- Ne vous dérobez pas à la responsabilité de vos erreurs et apprenez de chacun. Les erreurs font également partie du travail. C'est à travers eux que nous arrivons à comprendre sur quoi nous travaillons. Vous les ferez, humiliez-vous. Parfois, vous ne pouvez pas terminer le refactoring, parfois, au contraire, vous pouvez vous laisser trop emporter, mais l'essentiel est d'apprendre de vos erreurs à maintes reprises.
- Demandez des conseils, mais ne les suivez pas toujours. Votre tâche en tant que développeur est de déterminer ce que vous devez refactoriser et ce qui ne l'est pas. Vous devez avoir la liberté de prendre ces décisions et de faire des erreurs.
- Faites-le tous ensemble parce que vous vivez ici. C'est très important. , , , .
Conclusion
— . — . , , , , .
. — . , , , , .
Les références
- , ,
- Principes connexes de Bob Martin