Plusieurs équipes de développement, dont celle de Mirego, appliquent la règle du scout, c’est-à-dire qu’on vise à laisser un endroit dans le code toujours plus propre après notre passage que lors de notre arrivée. C’est particulièrement tentant de le faire dans un contexte où on se retrouve dans du code écrit par des gens qui avaient des pratiques différentes, une philosophie différente, des opinions différentes et potentiellement même des compétences différentes.

C’est toutefois une pratique qui peut vite se retourner contre nous. En ne connaissant pas le système existant en profondeur, on peut rapidement mettre un doigt dans l’engrenage et se retrouver à effectuer des modifications très risquées au code par souci de le rendre plus propre. Il est donc primordial de bien identifier la portée de ces changements, et si ça s’avère trop risqué, il sera préférable de prendre en note les améliorations potentielles, discuter de celles-ci avec les intervenant·es du projet, et potentiellement les attaquer ultérieurement via une tâche bien ciblée et comprise par tous.

Chez Mirego, la qualité du code est généralement aussi importante que la qualité de la fonctionnalité livrée. Par contre, dans un contexte de reprise, il faut focaliser ses efforts sur le résultat final, quitte à parfois devoir faire certains compromis sur le code.

D’ailleurs, il n’y a pas que la personne chargée d’écrire le code qui doive accepter ce certain inconfort. Les membres de l’équipe qui révisent les changements doivent aussi accepter que ceux-ci ne respecteront possiblement pas toutes les lignes directrices. Il est généralement préférable de garder une certaine constance dans le code, quitte à reproduire certains patrons suboptimaux. 

Dans un contexte de reprise de projet, il est critique pour l’équipe de développement de faire preuve de curiosité, et ce dès le tout début. Ça commence par prendre le temps d’apprendre tout sur le produit existant, sur ses fonctionnalités et ses utilisateur·rices. Il faut avoir une excellente idée de ce qui fonctionne bien et moins bien dans le produit avant même d’écrire la moindre ligne de code. Ça peut paraître évident, mais quand une équipe est habituée à démarrer des projets de zéro, c’est une étape qui peut être omise sans qu’on ne le réalise vraiment.

Une excellente façon de bien comprendre les subtilités d’un produit est de concevoir un plan de test rigoureux et de l’exécuter. Cette étape devrait être prise en compte dans le budget de reprise, puisqu’elle sera essentielle à la compréhension du produit et limitera les risques de régressions lorsqu’on commencera à introduire des changements.

Il faut aussi poser des questions au client et à ses utilisateur·rices. C’est déjà bien de comprendre ce que le produit fait, mais c’est encore mieux de comprendre pourquoi il le fait. La raison d’être d’une règle d’affaires n’est pas toujours évidente. Il est facile de simplement prendre pour acquis qu’elle est désuète, mais mieux vaut poser des questions pour affiner notre compréhension du produit dans son contexte. En validant toutes nos hypothèses, on empêche plusieurs problèmes futurs de se matérialiser.

Lorsqu’un projet de reprise démarre, il ne faut pas négliger l’importance de mettre de bons outils en place. Notamment, on devrait configurer tous nos environnements, les pipelines d’intégration continue et de déploiement en continu ainsi que les outils de validation de style (code linting). Dans certains cas, on devra probablement ignorer plusieurs règles qui demanderaient trop d’effort à respecter, mais d’avoir l’outil en place est déjà un bon début.

On devrait ensuite prioriser rapidement un premier déploiement en production, avec peu ou pas de changements au niveau du code. Le premier objectif est de s’assurer que tout soit en place si le besoin de corriger rapidement quelque chose en production survient. Cela permet aussi de valider que rien n’est brisé au système existant lors de la configuration des outils et environnements. On souhaite éviter que la première mise en production contienne des changements majeurs. Plus le changement est important, plus difficile il devient d’identifier la cause de problèmes ou d’effets de bord indésirables.

L’équipe réalisera probablement en cours de route qu’elle doit manuellement exécuter certaines commandes plusieurs fois par jour ou par semaine. Si tel est le cas, il faut s’assurer de les rendre disponibles à tous via un Makefile ou une solution équivalente. Cela permettra à tous les membres de l’équipe de sauver du temps et d’éviter certaines erreurs.