Lorsque j'étais ingénieur junior, j'avais cette arrogance classique avec laquelle beaucoup d'entre nous commencent - je crachais sur tout code que je n'avais pas écrit moi-même.
Je parcourais la base de code, commentant les "idiots" qui avaient créé cet "héritage en désordre" dont je devais maintenant assurer la maintenance. Les plaintes concernant la correction des erreurs de quelqu'un d'autre étaient constantes. J'étais jeune, trop confiant et j'avais tout à fait tort.
Ce retour à la réalité s'est produit alors que je travaillais pour un client dont le code était relativement récent mais mal écrit. Notre équipe a hérité du projet et, malgré nos efforts, nous n'avons réussi qu'à rafistoler les choses sur les bords. Le client était suffisamment satisfait de nos solutions pour prolonger notre contrat, mais les problèmes fondamentaux persistaient.
Ensuite, le client a décidé de procéder à la migration du fournisseur git. Nous avons dû créer un nouveau repo, copier le code et le mettre en ligne. C'était une tâche facile pour moi, mais quand j'ai regardé l'historique des livraisons, je n'ai vu que mon nom d'utilisateur qui me fixait. Les futurs ingénieurs me blâmeraient dans git pour chaque ligne et maudiraient mon nom pour l' "héritage de cauchemar" dont ils avaient hérité, tout comme je l'avais fait pour d'autres.
L'ironie du sort m'a frappé de plein fouet : j'étais devenu l' "idiot" sans visage que j'avais l'habitude de blâmer.
Ce jour-là a transformé ma compréhension des codes hérités. Parfois, vous n'êtes pas le héros qui vient réparer les choses ; vous n'êtes qu'un ingénieur de plus dans une longue chaîne, qui fait de son mieux avec les contraintes dont il dispose.
Cette expérience m'a appris que le mot "héritage" est une étiquette mal utilisée et toxique que nous avons accolée aux logiciels en service. Le vrai problème n'est pas le code vieillissant - c'est notre attitude dédaigneuse à son égard.
Lorsque nous qualifions un code d' "héritage", nous créons une prophétie auto-réalisatrice qui conduit à l'impuissance et à des réécritures coûteuses.
Nous traitons le code inconnu comme un produit défectueux qui doit être remplacé alors qu'en réalité, nous ne comprenons tout simplement pas les problèmes qu'il a été conçu pour résoudre.
Comprendre le vieillissement du code
Lorsque les ingénieurs parlent de code "hérité", ils veulent généralement dire qu'ils ne l'ont pas écrit, qu'ils ne le comprennent pas et qu'ils sont inquiets à l'idée de le modifier.
Il s'agit parfois de problèmes réels, comme une qualité médiocre ou une technologie dépassée, mais le plus souvent, il s'agit d'un écran de fumée qui cache une méconnaissance.
Quelle ironie ! Si les ingénieurs d'origine assuraient encore la maintenance du système, on ne parlerait probablement pas d'héritage.
Cela révèle une vérité gênante : le problème de l' "héritage" ne réside souvent pas dans le code, mais dans notre relation avec le code écrit par d'autres.
Comprendre ce qui fait qu'un code est "hérité" permet de trouver des stratégies pour l'éviter :
- Des équipes stables : Les membres de l'équipe qui travaillent depuis longtemps conservent la connaissance du projet. Lorsque les auteurs restent dans les parages, leur code reste compris et maintenable.
- Architecture et documentation : Un code bien structuré et clairement documenté survit aux changements de développeurs. Une architecture et une documentation de qualité constituent des passerelles de connaissances pour les futurs responsables de la maintenance.
- Collaboration : La programmation en binôme régulière et les revues de code approfondies diffusent les connaissances au sein de l'équipe. Lorsque plusieurs ingénieurs comprennent chaque composant, aucun départ n'entraîne de déficit de connaissances.
- Formation des jeunes ingénieurs : Le fait de confier la responsabilité de composants à des ingénieurs débutants assure le transfert des connaissances et crée un pipeline de mainteneurs qui comprennent le système.
- Pile technologique : L'utilisation de technologies standard et éprouvées facilite le transfert de connaissances. La chasse aux technologies de pointe crée de futurs codes hérités - soit à partir d'expériences ratées, soit à partir d'implémentations réussies qui deviennent obsolètes.
La plupart des équipes ont du mal à mettre en œuvre ces pratiques, ce qui entraîne une augmentation du code "hérité".
Élaborer des solutions, pas des problèmes
Imaginez que vous emménagiez dans une nouvelle maison et que vous la trouviez encombrée et confuse. Vous ne voudriez pas avoir à gérer le désordre de quelqu'un d'autre, n'est-ce pas ?
Il en va de même pour le code.
Un code désordonné est un code qu'il est impossible de transmettre. C'est comme laisser un labyrinthe à quelqu'un d'autre. Cela peut provenir de plusieurs facteurs :
- Une mauvaise conception : Une architecture bâclée empêche de voir comment les choses se connectent.
- Tests manquants : Sans tests, comment être sûr que le code fonctionne réellement ?
- La chasse aux tendances : Suivre aveuglément les pratiques à la mode peut gonfler votre code d'une complexité inutile. Pensez aux « modèles de conception pour tout ! » ou aux modèles architecturaux trop verbeux.
Voici une bonne astuce pour éviter de créer des maux de tête en matière de codage : posez-vous la question suivante :
[B]« Quelle est la solution la plus simple pour faire le travail ? »[/BI]
N'ajoutez de la complexité qu'en cas d'absolue nécessité.
Vous aimez apprendre de nouvelles technologies ?
C'est parfait !
Mais ne le faites pas juste pour être à la mode.
Avant de vous plonger dans des modèles de conception fantaisistes, posez-vous la question suivante : « Quel problème spécifique cela va-t-il résoudre ? »
Si la réponse est « Je veux juste apprendre des modèles de conception », attendez.
Concentrez-vous sur la résolution de besoins réels, et non sur la recherche des dernières tendances en matière de développement ou sur vos intérêts d'apprentissage.
L'innovation ne se limite pas à l'utilisation des dernières technologies
Pour de nombreux ingénieurs, l'innovation se résume à l'adoption des dernières technologies - nouveaux frameworks, nouveaux langages brillants, etc.
Cette idée fausse se retourne souvent contre eux, créant plus de problèmes qu'elle n'en résout. Par exemple, si nous décidons soudainement de créer tous les nouveaux services en Golang, nos systèmes existants basés sur Javascript deviennent instantanément "hérités", même s'ils sont encore parfaitement fonctionnels.
La véritable innovation consiste à relever de nouveaux défis ou à trouver de meilleures solutions aux problèmes existants.
Se contenter de passer à une nouvelle technologie sans objectif précis n'est pas de l'innovation - c'est simplement dépenser des ressources inutilement. Ce type d' "innovation" ne résout pas les problèmes ; il les crée, ce qui, en fin de compte, fait perdre du temps et de l'argent à l'entreprise.
Pour être clair, je ne dis pas que nous ne devrions jamais adopter un nouveau langage ou un nouveau cadre. L'essentiel est que la nouvelle technologie réponde à un problème réel et qu'elle soit la solution optimale à ce problème.
Par exemple, alors que le développement d'applications mobiles natives pour iOS et Android nécessite des bases de code distinctes (Swift/Objective-C pour iOS, Java/Kotlin pour Android), l'utilisation de frameworks multiplateformes comme Flutter ou React Native permet aux développeurs d'écrire une seule base de code qui peut être déployée sur les deux plateformes, ce qui réduit considérablement le temps et le coût de développement tout en permettant souvent d'atteindre des performances proches de celles des applications natives.
Donner du pouvoir aux autres
Vous vous souvenez que j'ai mentionné le fait que le code devient "hérité" lorsque le créateur initial s'en va ? La vérité est que la plupart des programmeurs ne peuvent pas écrire un code parfait, mais presque tout le monde peut expliquer ce que fait leur code existant.
Et devinez quoi ?
L'enseignement n'est pas seulement bénéfique pour l'apprenant, il l'est aussi pour l'enseignant !
Expliquer les choses vous oblige à penser de manière critique et à approfondir votre compréhension, ce qui fait de vous un meilleur ingénieur. De plus, le mentorat est une compétence clé pour les ingénieurs en informatique, et y travailler contribue donc à votre évolution de carrière.
La meilleure façon d'enseigner ? La programmation en binôme !
Il est étonnant de voir tout ce qu'un nouvel ingénieur peut assimiler en deux heures en corrigeant un bogue difficile à vos côtés. Vous pouvez également travailler en binôme sur le développement de nouvelles fonctionnalités - de cette façon, la propriété est partagée dès le départ.
La meilleure option suivante ? Les revues de code.
Bien qu'elles soient plus lentes et asynchrones (c'est-à-dire qu'elles se déroulent dans le temps), elles permettent d'obtenir un retour d'information précieux. La communication écrite peut s'avérer délicate, c'est pourquoi vous avez besoin de réviseurs ayant un œil vif et un sens aigu du codage - ce qui n'est pas toujours facile à trouver.
Les anciens ne sont pas tous cassés
Le terme "héritage" devrait être réservé aux systèmes qui nous déconcertent et résistent au changement. Si un système est simplement ancien mais fonctionne bien, le qualifier d' "héritage" est injuste et peut conduire à des réécritures inutiles.
Les systèmes activement développés n'ont pas besoin d'une étiquette spéciale. Les systèmes dont le développement est lent ou bloqué peuvent être considérés comme "en mode maintenance".
Le problème principal du "code hérité" est le manque de compréhension de ses mainteneurs. Au lieu de le jeter, nous pouvons simplement apprendre ses méthodes.
Même s'il ne s'agit pas du plus beau code, les améliorations progressives, les nouvelles fonctionnalités et même l'ajout de tests sont tous réalisables. Même si ce n'est pas aussi excitant qu'une réécriture complète, cela profite davantage à l'entreprise sur le long terme.
Ce n'est que dans de rares cas que les systèmes existants sont vraiment irrécupérables et doivent être remplacés.
Cependant, une telle décision ne peut être prise qu'avec une compréhension approfondie du système et de ses problèmes. Cela signifie qu'il faut s'efforcer de "comprendre le système" pendant une longue période avant d'envisager sérieusement une réécriture.
Par conséquent, ne réécrivez que si vous avez de fortes raisons de penser que réparer le système existant demandera beaucoup plus de travail que de repartir à zéro.
Toutefois, pour atteindre ce niveau de certitude, il faut bien comprendre le système actuel et le coût de la construction d'un nouveau système.
Affronter ou esquiver
Les codes hérités nécessitent une attention particulière, mais cela ne signifie pas automatiquement qu'ils relèvent de votre responsabilité. Changer de projet ou même d'entreprise est un choix tout à fait respectable par rapport à celui d'entamer une réécriture.
Si vous décidez de rester, la tâche peut vous sembler intimidante et interminable.
Cependant, vous serez probablement surpris par les progrès réalisables en l'espace d'un an. En outre, il peut être bénéfique d'impliquer des membres de l'équipe moins expérimentés et de leur confier progressivement la responsabilité du projet.
Ce qui vous semble être un travail fastidieux et peu gratifiant peut être une occasion d'apprentissage passionnante pour quelqu'un qui vient d'arriver dans le domaine.
Les systèmes hérités sont présents dans la plupart des entreprises. Ils sont le résultat d'un code mal écrit laissé par les ingénieurs précédents. La personne suivante n'a pas la volonté de résoudre les problèmes existants et opte pour une réécriture complète, répétant ainsi le cycle.
Vous avez le pouvoir d'interrompre ce schéma.
En évitant de créer de nouveaux systèmes hérités et en comprenant progressivement ceux que vous rencontrez, vous deviendrez un ingénieur plus compétent.
Votre équipe, votre entreprise et le marché vous reconnaîtront comme celui qui résout les problèmes, et non comme celui qui les crée.
Vous serez celui qui a mis de l'ordre dans le chaos, et non celui qui y a succombé. C'est le genre de héros dont Gotham a besoin.
Source : "The Anti-Legacy Manifesto: Writing Code That Lasts"
Et vous ?
Pensez-vous que ce manifeste est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Boostez votre carrière dans le développement de logiciels grâce à ces 10 compétences essentielles, par Mensur Durakovic 10 vérités difficiles à avaler que l'on ne vous dira pas sur le métier d'ingénieur logiciel, par Mensur Durakovic, ingénieur logiciel L'illusion de l'ingénieur sénior : Ce que je pensais et ce que j'ai appris, par Mensur Durakovic