Article original : How to Work With a Large Legacy Codebase Like a Pro
Par Ogundiran Ayobami
Apprendre à coder est difficile, mais comprendre une codebase legacy est un tout autre niveau de difficulté, même pour les développeurs de logiciels expérimentés. Aujourd'hui, je vais vous montrer comment l'appréhender comme un professionnel.
Lorsque vous rejoignez une nouvelle entreprise, vous avez la chance de l'aider à améliorer considérablement certains de ses processus grâce à votre regard neuf. Mais dans la plupart des cas, d'après mon expérience, cela se passe rarement ainsi.
Pour vous donner les meilleures chances d'aider et d'être efficace, il est important de savoir comment naviguer dans une large codebase legacy et comment travailler avec les autres sur celle-ci.
Le code est un sous-produit humain
La codebase legacy sur laquelle vous travaillez est le résultat des décisions prises par l'entreprise, les leaders techniques et les développeurs de votre société. Cela signifie que vous devez être prudent en la manipulant, car on l'appelle "codebase legacy" pour ces raisons précises.
On dit souvent que "Le code que vous avez écrit n'est pas une extension de vous-même". Mais la vérité est que nous nous sentons souvent encore piqués au vif lorsque les gens parlent défavorablement de notre code.
Ou bien nous n'aimons pas inconsciemment faire face aux conséquences des décisions d'une autre personne sous la forme d'une codebase legacy. C'est pourquoi vous devez être prudent lorsque vous rejoignez une entreprise.
Si vous rejoignez une entreprise qui valorise les processus, vous serez probablement guidé par de la documentation ou des collègues comprenant le contexte de la codebase. Et si vous rejoigniez une entreprise qui n'a pas encore priorisé de tels processus ? Qu'ils vous guident ou non, voici ce que vous devrez faire.
Soyez curieux, ne soyez pas critique
Comprendre la codebase legacy fait partie de votre travail. Être critique pourrait faire penser à vos collègues (développeurs et managers) que vous les réprimandez. En réalité, la plupart des développeurs professionnels expérimentés ont déjà écrit du code legacy.
Soyez donc curieux, pas critique. Soyez empathique. Au lieu de dire quelque chose comme "Ce code est nul" ou toute autre plainte, soyez curieux. Soyez prêt à apprendre les histoires derrière la codebase. Je sais, c'est plus facile à dire qu'à faire – mais vous devez le faire de toute façon pour réussir dans votre travail.
Cherchez à savoir pourquoi ils ont procédé ainsi. Demandez à vos collègues de vous expliquer les choses. Observez-les pendant qu'ils travaillent dessus. Essayez de comprendre comment cela fonctionne.
Ne codez pas encore – Utilisez la plateforme
Il est tentant de se précipiter dans le code, mais non – essayez d'abord d'explorer la plateforme. Vérifiez tout sur la plateforme, de la vitesse à l'UI/UX.
Pourquoi est-ce important ?
Votre travail est de construire pour les utilisateurs, et vous ne pouvez pas comprendre ce qu'ils ressentent si vous ne vous mettez pas à leur place. Alors, mettez-vous à leur place d'abord. Utilisez la plateforme pour ressentir ce que l'utilisateur final ressent.
Pourquoi est-ce votre travail de construire pour les utilisateurs ? Eh bien, ceux qui vous embauchent veulent que vous livriez des solutions basées sur les plans qu'ils ont en main. Mais indirectement, ils font tout pour les utilisateurs finaux. Votre compréhension des points de douleur des utilisateurs pourrait vous aider à transformer leurs idées en produits ou à améliorer leurs décisions sur ce qu'il faut construire et comment le construire.
Voyez-vous, il est facile d'expliquer les choses avec des connaissances, de l'exposition et de l'expérience. Mais le temps a montré maintes et maintes fois qu'il vaut mieux vérifier la plateforme pour voir ce que l'on ressent au lieu de se fier à ses suppositions.
L'expérience que vous accumulez en utilisant la plateforme vous aidera à connecter la codebase aux fonctionnalités de la plateforme et vous donnera une meilleure compréhension de la codebase. C'est une autre raison pour laquelle vous devriez utiliser la plateforme avant de plonger profondément dans le code.
Lisez la partie la plus importante de la codebase
Le principe de Pareto (également connu sous le nom de règle des 80/20) s'applique presque partout. Il peut aussi vous aider à naviguer dans une codebase.
Au lieu de bricoler la codebase au hasard, demandez à vos collègues ayant une grande expérience de la codebase quels sont les fichiers et dossiers qu'ils utilisent presque tout le temps.
Vous pourriez vous concentrer sur ces fichiers et dossiers, et de là, vous pourrez passer à d'autres selon les besoins des tâches qui vous sont confiées. Vérifiez ensuite d'autres fichiers plus critiques qui peuvent vous aider à comprendre comment la codebase est assemblée, tels que :
- Fichiers de Config
- Structures de dossiers
- Fichiers de test (si applicable)
Il est important de lire ces parties de la codebase car elles révèlent les opérations importantes qu'elle contient. Lire les fichiers de Config et autres peut être vraiment ennuyeux, vous n'avez donc pas à tout comprendre d'un coup. Vous pourrez toujours y revenir plus tard. C'est la clé.
Étudiez les workflows dans la codebase
Prenez votre temps pour comprendre le workflow des parties les plus importantes de la codebase.
Découvrez comment ceci se connecte à cela. Vérifiez ce qui se passe si vous connectez ou déconnectez telle ou telle partie. En traçant le flux des opérations au sein d'une codebase, vous avez une chance d'en apprendre davantage sur celle-ci. Cette expérience vous aidera à agir avec précision lorsque vous implémenterez des fonctionnalités ou corrigerez des bugs.
Attendez ! Vous vous demandez comment faire ? D'accord, vous pouvez commencer par une fonction. Lisez-la, puis lisez et comprenez les autres fonctions ou composants qui l'utilisent. Vous pouvez répéter ce processus avec des modules, des classes et d'autres éléments jusqu'à ce que vous ayez une compréhension solide de la codebase.
Vous pouvez également analyser comment la codebase gère les requêtes et les réponses si applicable. Surtout, trouvez comment tout est connecté pour comprendre la codebase.
Recherchez les bibliothèques et les Frameworks
Vous allez probablement trouver du code hardcoded, des bibliothèques et des Frameworks (internes ou externes) au sein d'une codebase legacy. Les bibliothèques et Frameworks ne sont peut-être plus d'actualité. Vous devrez donc faire des recherches sur eux et comprendre comment ils sont utilisés, particulièrement dans le cadre de votre codebase. Vous pouvez faire cela en cherchant leurs versions sur Google.
Parfois, les bibliothèques peuvent avoir été conçues au sein de votre organisation. Dans ce cas, vous devrez solliciter l'aide de collègues qui comprennent le contexte des Frameworks et bibliothèques.
Honnêtement, il peut être difficile de demander de l'aide si ces personnes sont désormais vos subordonnés. Mais en vérité, demander de l'aide ne signifie pas que vous n'êtes pas compétent pour accomplir votre travail. Rappelez-vous qu'ils ont le contexte de la codebase. Ils ont écrit le code, ils sont donc responsables de vous aider à comprendre la codebase et pourquoi ils ont pris ces décisions. Vous n'avez pas à vous sentir mal de chercher de l'aide dans ce cas. Même si vous vous sentez mal à ce sujet, il est normal de demander de l'aide.
Comprenez le code hardcoded
D'ici là, vous aurez entendu ou expérimenté vous-même que certains codes ne peuvent pas être touchés bien qu'ils semblent ne rien faire. D'après mon expérience, j'ai appris que ce genre de code est essentiellement du code de contrôle ou des expressions mathématiques.
Voici ce que je veux dire :
Un morceau de code peut sembler ne rien faire, mais une autre partie du code vérifie s'il est disponible avant de prendre une décision. Alors, que se passerait-il si vous supprimiez le code vérifié par l'autre partie ? Eh bien, tout casserait ou vous obtiendriez des résultats inattendus.
La plupart du temps, le code hardcoded n'est que des expressions mathématiques inconnues des développeurs traitant le code.
Cela me rappelle ce qui m'est arrivé récemment. Je construisais un package JavaScript pour convertir GitHub en une Base de données Serverless. Les structures des données que j'avais en main imposaient l'utilisation de boucles for imbriquées, mais je ne pouvais pas le faire car les navigateurs n'ont pas la capacité d'exécuter des opérations complexes comme le serveur.
J'ai donc décidé de proposer des expressions mathématiques qui ont permis de réaliser tout ce que je voulais sans boucles imbriquées. Je savais que l'expression paraîtrait hardcoded pour d'autres développeurs, mais elle faisait le travail sans perte de vitesse.
Quoi qu'il en soit, j'y ai ajouté du contexte – j'ai expliqué ce qu'elle fait, comment elle le fait et pourquoi j'ai choisi de procéder ainsi.
Tout ce que je dis, en substance, c'est que la plupart des codes hardcoded sont des flux de contrôle ou des expressions mathématiques inconnus des développeurs travaillant sur une codebase. Savoir cela vous mettra sur la bonne voie chaque fois que vous devrez gérer du code hardcoded.
Étendez d'abord, et refactorez lentement
Le premier instinct que nous avons en tant que développeurs quand nous voyons une codebase legacy est de la réécrire ou de la refactorer. Mais nous oublions toujours que l'étendre devrait être la priorité car cela permet à l'entreprise de continuer à fonctionner – cela répond aux intérêts des chefs d'entreprise.
Par étendre une codebase legacy, j'entends utiliser ses APIs pour construire de nouvelles fonctionnalités. Mais nous devons nous assurer que les fonctionnalités que nous ajoutons n'ont pas les mauvais traits que nous voyons dans les codebases legacy. Oui, je sais, c'est plus facile à dire qu'à faire. Parfois, les circonstances vous forceront à répéter ce mauvais trait que vous détestez. Yolo ! Vous n'êtes pas seul.
De plus, vous devez refactorer lentement. Par là, je veux dire que vous ne devriez pas vous précipiter pour refactorer une codebase legacy. Soyez patient jusqu'à ce que vous compreniez la codebase et ses contextes. Étendez d'abord, et refactorez lentement.
Documentez votre parcours pour comprendre une codebase legacy
Si votre organisation apprécie les processus et l'empathie, il est bon de documenter votre parcours à mesure que vous commencez à comprendre la codebase – de sa configuration à l'exploration de chaque partie.
Vous pourriez améliorer le processus d'onboarding de votre entreprise si le chemin pour configurer vos codebases et les comprendre est clairement documenté. En même temps, cela facilitera la vie des personnes venant après vous et aidera même les personnes avant vous ou votre futur moi.
Documentez tout, y compris les défis possibles et comment les résoudre. N'oubliez pas d'encourager les autres à améliorer votre documentation pour faciliter les choses pour les autres, comme cela a été fait pour eux.
Faire cela peut vous présenter comme un leader et vous offrir des opportunités de leadership. Quoi qu'il en soit, ne forcez pas les choses. Ne le faites que si c'est autorisé dans votre organisation ou si vous savez comment les aider à l'adopter.
Conclusion
Apprendre à coder est difficile, et comprendre une codebase legacy est un tout autre niveau de difficulté. Mais vous pouvez toujours trouver votre chemin pour livrer les fonctionnalités requises par vos responsables et les utilisateurs finaux. Tout ce que vous avez à faire est de suivre les conseils fournis dans cet article. À une prochaine fois et soyez bienveillants.
Je prévois de partager beaucoup de conseils de programmation et de tutoriels en 2023. Si vous avez du mal à construire des projets ou si vous voulez rester connecté à mes écrits et vidéos, rejoignez ma liste sur YouTooCanCode ou suivez-moi sur Twitter à Ayobami Ogundiran.