Les premiers jours sur une base de code inconnue, je ne lis pas le code au hasard. Voici dans quel ordre je procède.
1. Je traverse, je ne lis pas. Je pars d'une fonctionnalité que je peux exécuter, et je la suis de bout en bout : la route, le contrôleur, le modèle, la requête, le rendu. Une traversée complète apprend plus que dix fichiers survolés.
2. Je cherche où le code fait mal, dans l'historique. Les fichiers les plus modifiés sont souvent ceux que l'équipe évite de toucher. C'est là que vivent beaucoup de règles métier, et de bugs :
git log --format=format: --name-only | grep -v '^$' | sort | uniq -c | sort -rn | head -20 3. Je regarde ce qui protège l'application. Les tests qui passent encore, la façon de déployer, un environnement de test fiable, la surveillance des erreurs. On ne corrige bien que ce qu'on voit.
4. Ma première contribution est petite. Une petite pull request valide tout le reste : que j'ai compris les conventions, que je sais lancer les tests, que le déploiement passe. Les sujets larges viennent après.
5. Je ne réécris pas ce que je ne comprends pas encore. Une ligne étrange a souvent une raison qui n'est plus dans le code, mais dans la tête de quelqu'un. Je demande avant de supprimer.
Ensuite, j'avance par petits lots : chaque intervention part en pull request testée, relue et déployée. L'application s'améliore sans jamais cesser d'être livrable.
Amine Affif, développeur full-stack à Paris. amineaffif.com
