3 étapes pour prendre soin de votre base de code | de Scott Pickthorn | janvier 2023

Nettoyez le code dans lequel vous travaillez au quotidien, en étant vigilant.

Nous construisons des logiciels basés sur notre compréhension actuelle du problème, des exigences et de la technologie à portée de main. Les ingénieurs logiciels sont tous (pour l’instant) humains, ce qui signifie que nous faisons des erreurs. Cela conduit à des bogues manqués et à des odeurs de code. Même les petits désordres s’aggravent avec le temps, laissant un énorme désordre de code enchevêtré. Si vous ne travaillez pas activement à garder votre base de code propre, vous vous retrouverez avec un système bâclé et difficile à entretenir.

C’est ce qu’on appelle la pourriture du code.

Au fur et à mesure qu’une base de code change avec chaque nouvelle fonctionnalité ou refactorisation, cela peut entraîner un code inutilisé, des messages d’avertissement manqués et un code étroitement couplé. S’ajoutant à un gâchis chronophage pour comprendre ou changer. Nous essayons de tout régler, mais les délais s’accumulent et la dette technologique est poussée vers des objectifs commerciaux. Alors, comment pouvons-nous anticiper ce gâchis et garder notre base de code exempte de pourriture ?

La règle des 20% pour le traitement de la dette technologique. Allouez du temps dans votre sprint pour régler la dette technologique.

Il y a une guerre qui se déroule dans une base de code, la lutte entre le pompage de fonctionnalités et la dette technologique. Il peut être difficile de convaincre votre chef de produit que le traitement de la dette technologique peut réellement profiter à l’équipe et augmenter la productivité, mais la tige de code est réelle et se propagera à moins qu’elle ne soit résolue.

Souvent, il est difficile de remarquer que vous avez une dette technologique alors que de plus en plus de mains plongent dans la base de code. Nous ne pouvons surveiller qu’une partie des demandes d’extraction et même si nous le faisons, il y a des effets secondaires inaperçus qui provoquent des erreurs de console, du code inutilisé ou des bogues qui peuvent prendre des mois à apparaître.

Une fois que nous avons déterminé que la pourriture du code est réelle, nous devons trouver comment l’éliminer de notre système. Cela peut être fait de plusieurs façons et selon le propriétaire du produit, vous pourriez avoir plus de mal à le faire que les autres.

Chez Google, ils ont la règle des 20 % qui vous permet de passer 20 % de votre temps à travailler sur quelque chose qui profite à l’entreprise en dehors du travail normal sur le produit. C’est une règle qui montre qu’ils apprécient l’autonomie d’un employé pour travailler sur quelque chose qui l’intéresse et aide l’entreprise en même temps.

Il s’agit d’une règle que vous pouvez appliquer à votre base de code pour prendre un certain temps de votre journée pour régler la dette technologique ou la pourriture du code. Ceux-ci incluent des refactorisations plus petites, débarrassant votre application des messages d’avertissement ou d’erreur, ou même ajoutant des tests unitaires. L’objectif est de petites victoires qui garderont votre application en bonne santé et votre équipe fière de ce que vous possédez.

J’entends certains d’entre vous demander si mon responsable ou propriétaire de produit ne veut pas prioriser ces tâches. Eh bien, c’est votre travail en tant qu’ingénieur de faire comprendre à quel point une base de code propre et bien entretenue est importante. Si vous ne pouvez pas vous attaquer à la dette technologique, cela empêchera l’équipe de mettre en œuvre le travail sur les fonctionnalités et de repousser les délais du projet, car il est plus difficile d’apporter des modifications simples.

Dans l’une de mes équipes, nous avions un accord pour allouer 20 % des points d’histoire à la dette technologique (éléments non liés au produit). Tant que nous avions des tickets étiquetés et pointés, nous pouvions les utiliser dans notre sprint pour aborder les éléments auxquels nous voulons accéder. Nous permettant de maintenir la propreté, l’infrastructure ou même les outils de développement de notre application.

20% est une idée.

Peut-être que 20 % est trop élevé, et 10 % est tout ce dont vous avez besoin pour votre application. L’idée est que vous et votre équipe donnez la priorité à la santé de votre application afin que vous puissiez coder facilement sans distractions techniques

Celui-ci est plus difficile à mettre en œuvre car vous devrez identifier des moyens d’empêcher la pourriture du code d’entrer dans la base de code, mais cela vous fera gagner du temps à l’avenir.

J’ai déjà fait partie d’une équipe où nous avions à plusieurs reprises des problèmes d’erreurs de console et d’avertissements qui s’accumulaient. Je parle de dizaines d’avertissements anodins et d’erreurs potentiellement problématiques entrant continuellement dans l’application. Cela a rendu difficile le développement car il était difficile de distinguer si ces erreurs sont « attendues » car elles le sont déjà dans la base de code.

En conséquence, l’équipe s’est réunie pour identifier le problème et essayer de le corriger. Faisant désormais partie de notre processus d’assurance qualité, nous avons ajouté la vérification de la console afin d’empêcher les erreurs et les avertissements de se faufiler dans l’application.

Ceci, bien sûr, est un processus manuel et chaque fois que nous pouvons automatiser quelque chose, nous gagnons du temps et ajoutons un niveau de cohérence à la vérification.

Les tests d’intégration sont un excellent moyen d’empêcher les bogues et autres problèmes d’entrer dans la base de code. Exécutez-les sur chaque PR pour éviter qu’ils ne soient fusionnés.

un autre exemple de mesures préventives est le peluchage.

Les linters sont le moyen le plus courant d’empêcher certaines odeurs de code de pénétrer dans votre système. Eslint pour javascript, autopep8 pour python et presque toutes les langues ont des packages intégrés ou tiers pour le linting qui peuvent être adaptés aux directives et au style de code de l’équipe. Il s’agit d’une exigence pour empêcher la fusion d’odeurs de code simples.

« Vérifiez toujours un module plus propre que lorsque vous l’avez extrait » – Robert C Martin (Oncle Bob)

Oncle Bob, l’auteur de Clean Code, a fait une analogie avec la règle des Boy Scouts de toujours laisser un camping plus propre que vous ne l’avez trouvé. Il propose d’appliquer cela à votre base de code comme un moyen proactif de lutter contre la pourriture du code.

Au fur et à mesure que vous implémenterez des fonctionnalités, vous verrez sans aucun doute des problèmes qui doivent être résolus.

Nous devrions rechercher les changements qui sont manqués, un des plus courants est la documentation.

JSDoc est un moyen pratique d’ajouter des informations sur une fonction afin de donner plus de contexte aux entrées et aux valeurs de retour. Mais cela peut devenir obsolète rapidement car il est modifié.

Même si vous ne modifiez pas les paramètres de la fonction, la correction d’une faute de frappe ou d’une valeur incorrecte aidera les futurs développeurs qui cherchent à comprendre ce qui se passe.

Cela a ses limites.

Lorsque nous nettoyons la base de code, nous devons équilibrer notre travail sur les fonctionnalités avec le nettoyage. S’il y a trop de modifications non liées, vos réviseurs auront du mal à comprendre ce qui se passe et cela entraînera un processus de révision plus long et de la confusion.

Mon expérience personnelle est que si les changements de nettoyage augmentent suffisamment pour confondre le but du PR, alors les écoles seront divisées entre le travail de fonctionnalité et le nettoyage du camping.

Votre travail en tant qu’ingénieur consiste à résoudre les besoins de l’entreprise. Cela signifie que si vous voulez réussir, vous devez le rendre durable en créant des processus et en planifiant à maintes reprises comment atteindre ces objectifs. Nous voulons garder notre base de code propre et facile à entretenir afin que vous puissiez fonctionner au niveau attendu par votre entreprise.