Découvrir la maison de votre code. Dans quel type de maison est votre code ? | de Elye | janvier 2023

Dans quel type de maison est votre code ?

Il n’y a pas si longtemps, j’ai écrit sur l’importance de la propriété du code. Bien qu’il s’agisse d’un principe fondamental, il est souvent négligé au fil du temps. Sans propriété claire, vous vous retrouverez avec un code hérité désordonné.

Le code est comme une maison. Nous le construisons pour y vivre. Il faut en prendre soin. Comment ça se passe, c’est à quel point nous nous en soucions. Alors, quel type de maison est votre code ?

Il a été construit il y a de nombreuses années. C’était autrefois un endroit glamour pour coder. Chaque développeur était fier d’avoir son nom sur la liste des contributeurs du git-repo.

Mais comme la propriété a changé à maintes reprises, le nouveau propriétaire a peut-être eu trop de systèmes à entretenir, alors il a laissé celui-ci sans surveillance.

La dernière fois que son code a changé, c’était il y a des mois, voire des années. Personne n’ose modifier une ligne de code à l’intérieur. Tout au plus, ils sont d’accord pour ajouter un patch ici et là en cas de besoin.

De l’extérieur, vous pouvez toujours voir que c’est structurellement décent, mais personne ne veut entrer à l’intérieur.

Officiellement, il y a un propriétaire, mais en réalité, personne ne le possède. Il pourrit juste plus loin.

C’est censé être un prototype. Il a été construit rapidement comme une preuve de concept. L’interface utilisateur a l’air plutôt décente et possède toutes les fonctionnalités, mais nous savons que si nous la poussons, des pièces s’effondreront.

Il n’est pas conçu pour les tests de résistance et sa fonctionnalité n’est pas prête pour la production. De nombreux cas d’angle ne sont pas pensés. Le vent et l’eau le feront tomber comme un château de sable.

Parfois, cela peut sembler temporairement utilisable, comme une tente, mais cela ne durera pas longtemps. Il n’évolue pas et n’est pas extensible. Il n’y a pas de fondement.

Le propriétaire de l’entreprise nous a demandé de l’expédier, mais nous savons qu’une fois qu’il sera expédié, ce ne sera pas durable.

Ne cédez pas. Construisez des fondations appropriées.

Il y a un type de maison sur l’île de Bornéo appelée la Maison longue. Tout le village vit à l’intérieur.

Il n’y a pas de cloisons ou de frontières claires séparant les résidents. C’est une grande famille.

Cela peut aussi arriver avec du code. Une partie du code est stockée dans le même dépôt. Tout a été jeté dans ce repo sans limites claires. Le propriétaire principal peut être un chef de file, tout comme le chef du village.

Puisqu’il n’y a pas de frontières, il n’y a pas de structure de code claire à l’intérieur. N’importe quel code peut être n’importe où. C’est difficile à suivre. Il y a des frontières arbitraires, mais pas vraiment concrètes.

De plus, il peut y avoir des frontières virtuelles tacites qui dépendent de la compréhension mutuelle de chacun, mais il n’y a pas de filet de sécurité pour empêcher l’intrusion dans différentes parties du code. Au fur et à mesure que les développeurs vont et viennent, ces limites sont toutes mélangées.

Maintenant, traditionnellement, pour un petit projet, cela peut convenir. Mais il ne devrait pas être mis à l’échelle dans l’architecture moderne.

Nous avons aujourd’hui des maisons longues dans la société moderne, c’est-à-dire des maisons mitoyennes, mais elles ont des limites claires avec des murs et une propriété claire de quelle maison appartient à qui. Nos bases de code devraient avoir la même chose.

La maison au-dessus pourrait être l’une des maisons les plus folles que j’aie jamais vues. Sa base est solide, mais la structure supérieure est de la ferraille. Chaque couche devient plus folle et plus insoutenable à mesure qu’elle monte.

Il est rare qu’une maison (probablement une seule sur un milliard de maisons) soit construite comme celle-ci, mais c’est courant dans de nombreuses bases de code.

Lorsque le projet a commencé, tout a été soigneusement planifié et « architecturé ». Mais comme nous avons construit fonctionnalité sur fonctionnalité, il n’y a pas de temps pour la refactorisation. Nous devons le construire et le publier.

C’est comme sprint 1, sprint 2, sprint 3… release, release, release. Le refactor peut attendre un autre jour (qui n’arrive jamais).

C’est comme ce que font les gens ci-dessous:

Parfois, nous avons l’intention de bien concevoir l’architecture, mais nous avons plusieurs idées architecturales en concurrence les unes avec les autres. Il n’y a aucune indication claire de laquelle est la meilleure. Par conséquent, nous pouvons nous retrouver avec les deux architectures dans une seule base de code.

Cela peut sembler décent d’un coup d’œil rapide, mais c’est techniquement déroutant, peu pratique et entraîne de mauvaises performances.

Si chaque architecture est appliquée à différentes bases de code, chacune fonctionnera parfaitement, mais certaines ne peuvent pas être combinées.

Ce dicton est si vrai, « Deux cuisiniers gâtent la soupe. »

OK, il ne s’agit pas de la maison elle-même, mais de son environnement. Ils sont soit recouverts de mauvaises herbes touffues, soit d’objets salissants qui bloquent l’entrée.

La maison elle-même peut être décente, mais suscite le doute quand on regarde l’extérieur.

De même, dans notre base de code, une base de code saine n’a pas seulement une excellente architecture et structure internes, mais l’environnement de construction et la base de code sont généralement également bien organisés et maintenus.

Le processus CI/CD est correctement configuré. C’est encore mieux car la plupart sont automatisés avec une documentation appropriée, etc.

Nous ne voulons pas tondre notre pelouse tous les jours, n’est-ce pas ? Non, nous achetons une tondeuse à gazon automatique.

Bien que différents, la construction et l’entretien de maisons nous ont appris de nombreuses leçons applicables en matière de codage, telles que les suivantes :

• Ayez un plan et une base d’architecture clairs et solides.
• Évitez de construire un prototype simple et de l’expédier.
• La base de code interne doit avoir des limites tangibles avec des modèles d’architecture cohérents.
• Évitez les modèles hybrides au sein de la même base de code simplement parce que les deux sont bons.
• Refactorisez chaque extension ajoutée au code.
• Ne laissez jamais trop de dettes technologiques. Plus ils restent assis longtemps, plus ils auront du mal à payer plus tard.
• Chaque code doit avoir une propriété claire et continuer à être travaillé. Si cela ne se produit pas, il se transformera bientôt en code hérité.
• Évitez de posséder trop de bases de code. Chaque développeur n’a qu’une capacité limitée de code qu’il peut maintenir.
• N’oubliez pas les scripts de construction et de traitement. Gardez-les bien entretenus.

Tout comme une maison, le code a besoin d’amour et d’attention. Chérissez-le et nourrissez-le, et il deviendra une maison. Négligez-le, et il deviendra une maison hantée, revenant à jamais nous hanter.