Les héritages ne meurent jamais: Comment gérer le code hérité

Lorsque le terme « code hérité » apparaît, il est généralement dit ou reçu avec une teinte de dédain. Une recherche préliminaire sur Google pour les « mèmes de code hérités » fait apparaître des centaines et des centaines de macros d’images de personnes qui s’arrachent les cheveux, ont l’air fatiguées ou extrêmement déçues.

Lorsque j’ai commencé à travailler en tant que développeur de logiciels il y a 6 mois, je n’avais aucune idée de ce qu’était le code hérité ni de ce que cela impliquait de travailler avec.

Pendant mon quatrième mois en tant que développeur junior, on m’a demandé d’ajouter un filtre de recherche modal à une application créée par un de mes collègues il y a deux ou trois ans. Cela semblait assez facile; J’avais passé la majorité des quatre derniers mois à travailler sur une application incroyablement complexe pour un autre client impliquant notre pile standard: TypeScript / React / Redux / Redux-Saga. J’avais déjà résolu de nombreux problèmes uniques et je me sentais suffisamment confiant dans ma capacité de codage pour créer un modal simple pour transmettre les paramètres de requête au backend.

Comme vous l’avez peut-être deviné, ce n’était pas si simple. Mais pourquoi?

Qu’est-ce que le code hérité et pourquoi il peut être difficile de traiter

Le code hérité est du code hérité d’un autre développeur ou équipe qui utilise des technologies plus anciennes qui ne sont plus prises en charge ou qui ont été remplacées par une version plus récente. De nombreux programmeurs disent que « le code devient du code hérité dès qu’il est écrit ». La différence fonctionnelle entre le code « normal » et le code hérité pourrait simplement être qu’il a des conventions différentes de celles avec lesquelles vous avez l’habitude de travailler.

Dans mon cas, l’application à laquelle j’ai été affecté utilisait Flow plutôt que TypeScript, et elle n’était pas aussi fortement typée que ce à quoi j’étais habitué. Cela m’a rendu un peu plus difficile de comprendre la structure des données extraites du backend. Aucun type ne signifiait que je rencontrais beaucoup plus fréquemment des TypeErrors lors de l’exécution, ce qui peut être difficile à déboguer lorsque vous écrivez une grande fonctionnalité. En plus de cela, l’application utilisait une version beaucoup plus ancienne de React qui devait être réconciliée avec une version compatible de la bibliothèque de composants que je voulais utiliser pour construire le modal.

Avant d’entrer dans le vif du sujet de la façon de gérer le code hérité avec un sens de l’équilibre et de la rationalité, je veux ajouter un avertissement indiquant que le code hérité n’est pas tout mauvais et que travailler sur un projet hérité ne doit pas être terrible. Au contraire, travailler sur du code hérité m’a appris à être flexible, patient, et surtout, l’expérience m’a permis de résoudre des problèmes avec une nouvelle perspective dans un contexte nouveau.

En fait, cela a fait de moi un meilleur développeur qu’avant de commencer à travailler sur la base de code susmentionnée, et j’espère que votre projet hérité pourra vous apprendre quelque chose aussi.

Comment gérer le code hérité au niveau technique

Photo de Jeff Sheldon sur Unsplash

Lisez la documentation et les commentaires de code lorsque cela est possible

Dans un monde parfait, chaque base de code dispose d’un README robuste qui contient des explications concises sur le fonctionnement du projet, des commentaires de code qui expliquent la logique exacte de l’auteur original, et toute l’application est parfaitement logique. Cependant, c’est rarement le cas. De nombreux READMEs ne sont pas mis à jour au fur et à mesure que les projets se développent, les gens oublient d’écrire des commentaires, supposent que leur logique est évidente pour un nouveau développeur, ou ils manquent simplement de temps pour s’occuper de ces choses.

Regardez la base de code dans son ensemble

Si vous êtes perdu et que vous ne savez pas par où commencer, posez-vous ces questions :

• Quel est le but de l’application?
• Comment les données circulent-elles dans l’application ?
• Comment votre fonctionnalité s’intègre-t-elle dans l’application ?

Lorsque vous pouvez avoir une idée de la situation dans son ensemble, il est plus facile de trouver la meilleure façon de résoudre le problème. Vous devez peut-être créer un nouveau fichier et créer un nouveau composant. Peut-être avez-vous besoin d’écrire une fonction utilitaire et de la tester. Quoi qu’il en soit, comprendre le contexte plus large de votre problème est une bonne première étape pour trouver une solution.

Testez l’application manuellement et avec des tests unitaires dans la mesure du possible

Casser temporairement une application tout en ajoutant une nouvelle fonctionnalité est une fatalité, quel que soit votre niveau de développeur. C’est normal et attendu, surtout si vous débutez dans le travail, travaillez dans une base de code héritée avec une pile inconnue, ou une combinaison des deux.

La meilleure façon d’éviter que ces pannes ne deviennent des problèmes à long terme est de tester votre application à fond avec des tests unitaires et des tests manuels. Avoir ces tests en place et savoir exactement quel type de couverture vous en tirez vous fera gagner beaucoup de temps, vous et les futurs développeurs. De plus, des tests rigoureux rendent l’application plus évolutive et vous donnent également une petite poussée de dopamine chaque fois que vos tests sont propres.

Pour les tests unitaires, vous pouvez utiliser des frameworks de test comme Jest ou Jasmine.

Pour les tests manuels, vous voudrez développer une matrice de test et vous assurer que le document est accessible aux futurs développeurs. Pour la matrice, vous voudrez définir un ensemble d’actions, le comportement attendu, le comportement réel lorsque vous le testez, et tout autre détail important, comme ceci:

Je vais expliquer comment implémenter efficacement les deux types de tests dans votre flux de travail dans un futur article de blog.

Demandez de l’aide

En supposant que votre projet a été écrit par un employé actuel ou ancien sur votre lieu de travail, quelqu’un d’autre sait probablement ce qui se passe dans l’application, ou du moins en sait assez pour vous décoller. Apprendre à avaler votre fierté et à demander à quelqu’un d’autre est une étape inconfortable pour certains, mais nécessaire pour grandir en tant que développeur, et peut-être que votre collègue peut vous apprendre quelques nouvelles astuces.

Une bonne façon d’utiliser efficacement votre temps (et le leur) est de formuler des questions éclairées. Essayez de revenir à la base de code dans son ensemble et de comprendre les lacunes dans votre compréhension. Non seulement cela les aidera à mieux comprendre ce qu’est votre problème, mais cela montre que vous avez pris l’initiative d’essayer de résoudre le problème par vous-même en premier.

Sachez quand réduire vos pertes

Si vous passez trop de temps à essayer de mettre le pied dans la porte et que vous n’avez pas fait de progrès sérieux vers l’implémentation de la fonctionnalité après avoir essayé les étapes ci-dessus, il pourrait être utile de refactoriser le code autour de votre fonctionnalité. N’abandonnez pas trop facilement, mais gardez également à l’esprit quels sont vos délais et ce que votre chef de projet attend de vous.

Cela dit, il y a des inconvénients à s’y prendre de cette façon:

• La réécriture du code peut introduire des bogues, bien que cela puisse être quelque peu contourné avec de bons tests unitaires.
• La réécriture du code peut supprimer les fonctionnalités cachées, bien que cela puisse également être contourné avec de bons tests unitaires.
• Si vous êtes pressé par le temps, écrire du code en dehors de votre fonctionnalité en plus de votre fonctionnalité peut en fait prendre plus de temps que de simplement construire autour de celle-ci.

Dans l’ensemble, utilisez votre meilleur jugement. Il y a des avantages et des inconvénients pour l’un ou l’autre choix, et tout dépend de votre situation individuelle et du budget du projet.

Comment gérer le code hérité au niveau psychologique

Photo de Simon Migaj sur Unsplash

Maintenant que nous avons couvert les aspects techniques du traitement du code hérité, parlons de la façon de le gérer en utilisant nos compétences non techniques. Après tout, les développeurs sont des gens, pas seulement des robots de codage, et faire face à des problèmes difficiles sur des projets qui nécessitent de la créativité et de la paternité peut être émotionnellement éprouvant, non seulement pour vous, mais aussi pour vos collègues.

Soyez humble et gentil

C’est quelque chose que j’admettrai timidement que j’ai besoin de pratiquer davantage. Quand on m’a assigné le projet modal de filtre pour la première fois, j’ai été assez vocal sur la façon dont le code était janky et peu attrayant alors que l’auteur original du code était assis à 15 pieds de moi. Je voulais que mes commentaires soient une blague, mais avec le recul, je reconnais que j’étais arrogant et blessant, et que j’aurais dû être plus empathique.

Il y a beaucoup de facteurs qui peuvent conduire à ce que le code hérité semble « éteint » et que vous devez prendre en compte avant de commencer à critiquer l’auteur ou à supposer le pire à leur sujet (Ceci est vaguement lié à l’erreur d’attribution fondamentale!).

L’auteur original a peut-être eu ses raisons d’écrire du code comme il l’a fait.

Les contraintes de temps et les contraintes technologiques peuvent amener une personne à écrire du code qui fonctionne mais qui n’a pas nécessairement la meilleure convention. Si vous vous imaginez dans une situation avec pas assez de temps, des outils obsolètes et une liste de tâches d’un kilomètre de long, vous n’écririez probablement pas non plus le meilleur code!

Les conventions changent.

Dans les anciens projets Olio Apps, la convention pour le code utilise des guillemets simples pour déclarer des chaînes, et deux espaces étaient égaux à un onglet. Nous avions plusieurs petits composants React imbriqués dans un seul fichier. Dans notre convention actuelle, nous utilisons des guillemets doubles et quatre espaces, et chaque composant React, aussi petit soit-il, vit dans son propre fichier .tsx dans le répertoire component. Et dans plusieurs années, je suis sûr que cela changera aussi.

Tout le code devient éventuellement hérité

Cela revient au point précédent: votre code finira par être hérité. Au fur et à mesure que vous gravissez les échelons de l’ancienneté, de nouveaux développeurs seront embauchés et devront maintenir votre ancien code. Vous pouvez écrire du code propre, impeccable et SEC, mais une fois que les conventions changent ou que les tendances changent, ces nouveaux développeurs peuvent voir votre code de la même manière que vous voyez le code hérité des autres.

Soyez fier des petits succès

Il n’est pas facile de travailler en dehors de vos conventions habituelles; il y a une raison pour l’énorme trésor de mèmes et de blagues sur le traitement du code hérité. Si vous avez déjà appris une langue en dehors de votre langue maternelle, vous savez ce que cela fait d’oublier un mot ou un terme dans votre langue seconde, mais souvenez-vous-en dans votre langue maternelle et ne pouvez pas traduire de l’autre côté. Il en va de même pour le changement entre les conventions modernes et anciennes. Parfois, il suffit d’une minute pour retrouver ses repères.

En étant capable de naviguer avec succès dans le code hérité, vous montrez votre capacité d’adaptation, ce qui est une compétence importante qui vous profite à votre emploi actuel et à tous vos emplois futurs, que ces emplois soient dans le domaine de la technologie ou non. Le code hérité est le terrain de jeu idéal pour pratiquer cette compétence.

En conclusion:

Utilisez ce temps pour renforcer votre propre écriture de code

Maintenant que vous avez eu l’expérience de travailler dans une base de code héritée, vous devriez en sortir avec une meilleure idée de ce que vous aimez et n’aimez pas en termes d’outils et de conventions. Ce sont des choses que vous pouvez poursuivre dans de futurs projets et vous aider à mieux réviser le code des autres, à offrir des critiques constructives et à donner du mentorat.

Développez des applications pour l’utilisateur et le futur développeur

Que vous ayez eu l’expérience de la documentation et des commentaires de code ou de l’absence de documentation ou de commentaires de code, vous pouvez voir comment la documentation et les commentaires sont des outils puissants pour aider les futurs développeurs à naviguer dans le projet. Vous partagez un objectif commun de vouloir une application fluide, fonctionnelle et SÈCHE; maintenir la documentation et laisser derrière vous des commentaires de code informatifs est un bon moyen de combler cette lacune.

Rappelez-vous que votre code sera également hérité un jour

Je l’ai déjà mentionné à quelques reprises, mais il est important de réitérer que votre code sera également hérité, peu importe à quel point votre code et votre logique sont SECS et vierges.

Le plus important à retenir est d’être flexible, humble et que vous puissiez certainement apprendre de nouvelles astuces à partir de l’ancien code.