9 façons de maîtriser un code horrible, fast

On vous a confié la tâche d’implémenter une nouvelle fonctionnalité sur une ancienne base de code, mais le code a l’air horrible. Comment pouvez-vous le comprendre le plus rapidement possible? Voici plusieurs raccourcis pour vous aider à apprendre les parties importantes du nouveau code sans vous perdre dans les détails non pertinents.

En tant que programmeurs, nous devons souvent rejoindre de nouveaux projets, et la qualité du code peut être partout. Même avec une équipe organisée, maintenir la qualité du code cohérente tout au long d’un projet de taille moyenne à grande est un défi.

C’est pourquoi comprendre rapidement un code médiocre peut être une compétence précieuse. Cela peut vous aider à devenir très productif en peu de temps et à réduire le stress qui accompagne généralement le fait d’être le nouveau gars et de devoir jouer au rattrapage. Être en conversation avec un collègue et ne pas savoir de quoi cette personne parle la moitié du temps est un sentiment terrible.

D’un autre côté, c’est une excellente occasion de montrer à votre client ou à votre patron votre valeur et que vous pouvez vous mettre au courant rapidement et les impressionner. La plupart des développeurs mettent des semaines à des mois pour devenir vraiment productifs avec une base de code qu’ils n’ont pas construite eux-mêmes.

Voici comment maîtriser rapidement un code horrible.

Demandez de l’aide. C’est la stratégie la plus efficace

D’autres personnes ont déjà appris comment fonctionne le code, alors pourquoi ne pas les interroger à ce sujet? Vous pourriez penser que cela vous fait ressembler au débutant, mais faire preuve de curiosité peut avoir un fort impact sur votre image en tant qu’employé. Si l’attente de votre patron était que vous deveniez productif rapidement sans poser de questions, c’est une erreur de jugement de sa part.

Tout le monde prend le temps de se mettre au courant. Posez des questions et vous impressionnerez les personnes qui ont la bonne attitude pour le travail d’équipe.

Dans de nombreux cas, les développeurs originaux auront pris des décisions étranges ou inattendues, et c’est là que parler du code sera beaucoup plus précieux que de le lire. C’est encore plus le cas si la documentation fait défaut. N’oubliez pas que les développeurs existants ont de précieuses connaissances sur les projets qui ne sont écrites nulle part.

Faites une liste de concepts qui n’ont pas de sens pour vous

Il peut y avoir des concepts commerciaux qui sont nouveaux pour vous ou qui sont trop complexes. Il est important d’obtenir des éclaircissements à leur sujet avant d’essayer de travailler sur du code qui gère ces concepts, pour éviter les malentendus qui pourraient prendre un certain temps à comprendre.

Il se peut même que ces idées soient mal étiquetées ou représentées de manière inattendue dans une base de données. Évitez donc de vous stresser à envelopper votre cerveau autour de cela, et allez simplement à la source et demandez à vos collègues de travail à ce sujet.

Dans la même veine, il peut y avoir des modules, des classes ou des entités qui n’ont pas de noms appropriés. Prenez-en note. Des éléments mal nommés peuvent entraîner une grande confusion, alors documentez-les tôt, ainsi que toute autre chose qui affectera négativement votre capacité à réfléchir au fonctionnement du code.

Facilitez la reproduction des bogues

En ajoutant la gestion des versions de code et une machine virtuelle telle que Docker ou Vagrant, vous réduirez considérablement le temps nécessaire pour reproduire un bogue et tester votre travail sur une nouvelle fonctionnalité.

Tout malentendu sur le fonctionnement du code pourrait vous conduire à construire la mauvaise chose, soit parce que ce que vous construisez est peut-être déjà là et que vous ne l’avez pas vu, soit parce que les choses ne fonctionnent tout simplement pas comme vous le pensiez.

À ce stade, vous souhaitez avoir le contrôle de version Git dans votre projet. De cette façon, vous pourrez revenir à une version stable, ou même simplement travailler sur des branches séparées qui peuvent être supprimées si nécessaire.

Il est même possible d’obtenir une plus grande reproductibilité avec Git, car vous pouvez utiliser le cache pour ajouter du code de test ou de débogage pendant que vous creusez un problème difficile à suivre.

Pour en savoir plus sur l’architecture de votre projet, prenez en charge les tâches de configuration et de documentation dès le début.

On peut en dire autant des machines virtuelles et de la reproductibilité. Ils sont devenus omniprésents pour toute équipe de développement moderne, mais vous rencontrerez certainement des projets qui ne les utilisent pas ou même prêts à fonctionner en interne. Parfois, votre première étape en tant que nouveau membre de l’équipe consiste à documenter les étapes que vous avez suivies pour faire fonctionner un environnement, et éventuellement à transformer ces étapes en un script de configuration de machine virtuelle.

Construire un diagramme des composants

Une carte mentale des concepts métier, un diagramme entité-relationnel (ERD) des tables de base de données et un diagramme simple des composants de code peuvent grandement aider à réduire la douleur de la compréhension du nouveau code. Vous ne vous souvenez pas comment quelque chose fonctionne? Gardez cette ERD ouverte.

En fait, tout outil graphique qui vous aide à digérer rapidement les informations et à avoir une vue de dix mille pieds d’un projet sera précieux. D’autres exemples d’outils qui pourraient vous aider sont des graphiques de dépendance, des journaux et une carte de la pile technologique du projet.

L’un des plus grands consommateurs de temps dans le développement est le point d’intégration entre les systèmes. Avoir une vision globale du paysage du projet vous aidera à identifier les points d’intégration intéressants à examiner. Ce sont les endroits qui ont le plus de travail, et le plus de bugs.

D’autre part, la technologie évolue rapidement et il pourrait y avoir des opportunités de remplacer de grandes parties de la base de code par des solutions plus modernes et correctement intégrées. Un ancien framework aurait pu développer une nouvelle façon officielle de résoudre un problème, ou une bibliothèque entièrement nouvelle aurait pu être développée avec une meilleure compatibilité à l’esprit.

Utilisez des outils de visualisation et de modélisation pour avoir une vue d’ensemble.

Préparez-vous aux tests automatisés

Avant de commencer à casser des choses, il est toujours prudent d’ajouter des tests unitaires pertinents. Le problème avec les tests et le mauvais code est que le mauvais code est généralement étroitement couplé et difficile (voire impossible) à tester. Vous ne pouvez pas isoler des composants qui sont entrelacés et indivisibles.

Dans ces cas, prenez du recul et testez de plus loin. Habituellement, cela signifie faire des tests d’intégration, pour lesquels de nombreux outils sont disponibles. Les applications Web peuvent être testées par rapport aux requêtes HTTP, il est donc au moins possible de vérifier que le système répondra de la même manière aux mêmes entrées.

Les tests d’intégration ont cependant des performances bien pires que les tests unitaires. Chaque fois que vous le pouvez, implémentez des tests unitaires afin d’avoir un retour plus rapide sur les modifications de code. Si ce n’est pas possible, optez pour des tests fonctionnels ou même d’intégration.

Cette étape devrait éclairer les parties du code qui nécessitent un travail. S’il y a une grande quantité de code étroitement couplé, c’est une bonne cible pour la refactorisation une fois les tests d’intégration effectués, puis pour les tests unitaires plus tard.

Identifier des stratégies de codage inhabituelles ou inadéquates

Il est temps de commencer à refactoriser, mais par où commencez-vous?

Habituellement, le meilleur endroit est celui où les choses semblent étranges ou où les meilleures pratiques de développement n’ont pas été suivies. Pour le développement Web, cela pourrait signifier des contrôleurs fat avec un code de modèle étroitement couplé.

Gardez à l’esprit que les mêmes stratégies pourraient être utilisées ailleurs. Donc, si, par exemple, vous identifiez que des contrôleurs fat sont présents, il est probable que les développeurs précédents n’aient pas tenté d’avoir des contrôleurs minces. Vous pouvez également vous attendre à voir le même problème dans d’autres contrôleurs, car cela reflétait le style ou les lacunes du processus de développement avant maintenant.

Au début, travailler sur une petite tâche

Corriger un petit bug sur une fonctionnalité conceptuellement simple sera très éclairant et vous aidera à vous sentir productif dès le début.

C’est une idée similaire à ce qu’Andy Hunt et Dave Thomas appellent des “balles traceuses” dans le Programmeur pragmatique. La logique sous-jacente est la même: Travailler sur quelque chose de bout en bout pour vous prouver que c’est possible, puis améliorer progressivement ce travail initial.

L’approche “balle traceuse”. Crédit: Le programmeur pragmatique

Un bon exemple du genre d’amélioration simple que vous pouvez apporter est de prendre de petites étapes de refactorisation avec du code simple. Identifier une pratique de programmation courante qui n’est pas suivie et l’appliquer.

L’un de mes favoris pour cela est l’imbrication des blocs conditionnels. Donc, au lieu d’avoir plusieurs blocs if-if-if, l’un dans l’autre, annulez le premier et retournez, et faites de même pour toutes les vérifications de type de validation que vous pouvez trouver. Cela peut être aussi simple que d’inverser une vérification “si” et de déplacer du code, de sorte que le risque est presque inexistant et que le code plat sera plus facile à lire.

Assurez-vous d’abord de travailler sur des fonctionnalités de refactorisation faciles à tester, car même si les modifications sont à faible risque, c’est toujours une bonne idée de pouvoir valider votre code avant de l’envoyer en production.

Entrez en terrain familier avant de vous attaquer au code critique

Apprenez toujours comment le projet est mis en place en premier, et ensuite seulement plongez dans le côté architectural. Les éléments de code métier et d’intégration les plus critiques sont les plus difficiles à comprendre et à modifier. Évitez d’avoir des ennuis tôt.

En règle générale, évitez les problèmes commerciaux qui vous obligeraient à en savoir plus que ce que vous faites actuellement sur le projet ou sur le côté commercial. Cela signifie généralement rester à l’écart des transactions, des paiements ou du code lourd en mathématiques jusqu’à ce qu’il commence à devenir un terrain familier.

Une fois que vous êtes productif, que vous êtes à l’aise avec le style de codage du projet et que vous n’avez aucun mal à résoudre des problèmes simples, il est temps de travailler sur les choses les plus difficiles — mais pas avant.

Même s’il y a urgence à résoudre les problèmes de paiement, par exemple, ce genre de tâche peut être incroyablement risqué. Une erreur là-bas pourrait coûter cher au projet, et cela vous incombera également. Refusez absolument de travailler sur des tâches à haut risque dès le début si possible.

Comment gérer une pile technologique inconnue

Pour le dernier point, un problème courant que j’ai rencontré est que chaque nouveau projet inclut généralement une technologie que je ne connais pas.

Lorsque cela se produit, j’ai quelques stratégies qui m’aident à me mettre rapidement au point. La voie évidente pour l’apprentissage consiste à lire de la documentation et à se familiariser avec la nouvelle technologie. Mais bien que vous en appreniez beaucoup sur la structure, ce chemin ne vous aidera pas à apprendre les cas de coin, qui viennent généralement avec de l’expérience. (“Cas de coin” est un terme d’ingénierie qui fait référence à une situation qui se produit en dehors des paramètres de fonctionnement normaux.)

Une façon d’accélérer ce processus d’acquisition d’expérience est de prendre des ressources basées sur des questions telles que Stack Overflow et Quora et de les lire comme un livre. Trouvez les questions les plus populaires sur la bibliothèque que vous apprenez et voyez quels types de problèmes les autres rencontrent généralement. Vous n’allez pas nécessairement les rencontrer vous-même, mais le simple fait de savoir ce qui est possible revient à éclairer votre carte mentale de ces nouvelles idées.

Tirez parti des questions de dépassement de pile pour acquérir de l’expérience rapidement. Crédit: Stack Overflow

Pour une approche plus ciblée, trouvez des informations sur les fonctionnalités de bibliothèque utilisées spécifiquement dans votre nouveau projet. Examinez ceux qui sont nouveaux pour vous et apprenez-les à l’avance, avant de devoir toucher ce code du tout.

Partagez vos idées