Pendant le sprint, vous allez écrire et modifier beaucoup de code en équipe. Sans quelques règles simples de qualité, le projet devient vite difficile à comprendre et à faire évoluer, même pour vous.

Cette page te propose des bonnes pratiques accessibles pour garder un code lisible et cohérent au jour le jour, sans transformer ce cours en module complet de génie logiciel.

Nommage clair et cohérent

Le nommage est l’un des aspects les plus importants de la qualité du code : un bon nom explique déjà une partie du comportement.

• Choisis des noms explicites pour les variables, fonctions, classes et fichiers (on doit deviner leur rôle sans lire tout le code).
• Évite les abréviations obscures ou les noms trop génériques comme data, tmp, doStuff.
• Adopte une convention simple en équipe (par exemple CamelCase pour les classes, camelCase pour les méthodes et variables) et essaie de t’y tenir.

Fonctions courtes qui font une seule chose

Des fonctions trop longues ou qui font « un peu de tout » sont difficiles à comprendre, à tester et à réutiliser.

• Essaie d’écrire des fonctions qui ont une responsabilité principale claire (un rôle bien identifié).
• Quand une fonction devient trop longue ou trop compliquée, vois si tu peux extraire une partie du code dans une nouvelle fonction auxiliaire.
• Évite de mélanger trop de niveaux d’abstraction dans une même fonction (par exemple logique métier et détails d’interface utilisateur).

Commentaires utiles (pas redondants)

Les commentaires doivent apporter une information que le code ne montre pas déjà facilement.

• Utilise les commentaires pour expliquer le « pourquoi » (la raison d’un choix, d’un cas particulier), pas pour réécrire le « quoi » que l’on voit déjà dans le code.
• Si tu te surprends à devoir écrire un long commentaire pour expliquer une fonction, demande-toi si tu peux la simplifier ou la découper.
• Pense à mettre à jour ou supprimer les commentaires qui ne sont plus corrects après une modification du code.

Organisation des fichiers et des dossiers

La qualité du code, ce n’est pas seulement l’intérieur des fichiers, c’est aussi la façon dont tu organises ton projet.

• Regroupe les fichiers par rôle ou par fonctionnalité (par exemple par couche ou par module), plutôt que de tout laisser à la racine du projet.
• Donne à tes fichiers des noms cohérents avec ce qu’ils contiennent (par exemple ClientService, CommandeController, etc.).
• Évite de dupliquer du code : si tu copies-colles plusieurs fois les mêmes blocs, envisage d’extraire une fonction ou une classe commune.

Relire le code des autres (et le sien)

Une courte relecture par un coéquipier peut éviter des bugs et améliorer la qualité globale du projet.

• Quand c’est possible, demande à un membre de l’équipe de jeter un œil à ton code avant de fusionner une branche importante.
• Lors d’une relecture, concentre-toi sur la lisibilité (est-ce que je comprends ce que ça fait ?) autant que sur la correction technique.
• N’hésite pas à améliorer un peu le code que tu touches (renommer une variable, extraire une fonction) tant que tu ne changes pas le comportement sans en parler à l’équipe.

Ce que vous pouvez décider en équipe

• Une petite liste de règles de nommage communes (classes, méthodes, variables, fichiers).
• Quelques bonnes pratiques simples (taille des fonctions, organisation des dossiers) que tout le monde s’engage à respecter.
• Dans quels cas vous faites une relecture rapide avant de fusionner une branche (par exemple pour les changements importants ou risqués).