Une partie de ma formation (un stage en fait) où j'ai le plus appris niveau qualité du code, c'est dans une boîte qui pratique les revues de code systématique de tous les commit.
Ca signifie que pour qu'un bout de code intègre le projet, il faut qu'un autre ingénieur le relise. Outre trouver des bugs, ça permet aussi d'avoir une discussion sur la façon d'implémenter les choses, d'éviter l'over-engineering ("pourquoi y'a besoin de 3 factory et 4 proxy alors qu'une fonction suffirait ?"), etc…
Mais l'effet le plus intéressant, c'est que ça force à relire son code avant d'envoyer pour une revue, à vérifier que les commentaires sont là où il faut, à virer tous les trucs deg qu'on fait quand on développe dans sons coin (genre les log de debug à moitié commentés).
La deuxième chose, c'est d'écrire des tests unitaires. C'est très chiant d'écrire des tests pour du code spaghetti avec 45 dépendances dans tous les sens. Si on arrive à écrire des petits tests unitaires sur chaque fonction/classe, c'est qu'en général, le code est déjà bien découpé.
Après, y'a le style de code. Ca, c'est un peu les goûts et les couleurs, mais si le code passe une revue de code et des tests unitaires, c'est qu'il devrait être compréhensible.
# Code review
Posté par Jux . En réponse au journal Du code propre, c'est quoi ?. Évalué à 10.
Une partie de ma formation (un stage en fait) où j'ai le plus appris niveau qualité du code, c'est dans une boîte qui pratique les revues de code systématique de tous les commit.
Ca signifie que pour qu'un bout de code intègre le projet, il faut qu'un autre ingénieur le relise. Outre trouver des bugs, ça permet aussi d'avoir une discussion sur la façon d'implémenter les choses, d'éviter l'over-engineering ("pourquoi y'a besoin de 3 factory et 4 proxy alors qu'une fonction suffirait ?"), etc…
Mais l'effet le plus intéressant, c'est que ça force à relire son code avant d'envoyer pour une revue, à vérifier que les commentaires sont là où il faut, à virer tous les trucs deg qu'on fait quand on développe dans sons coin (genre les log de debug à moitié commentés).
La deuxième chose, c'est d'écrire des tests unitaires. C'est très chiant d'écrire des tests pour du code spaghetti avec 45 dépendances dans tous les sens. Si on arrive à écrire des petits tests unitaires sur chaque fonction/classe, c'est qu'en général, le code est déjà bien découpé.
Après, y'a le style de code. Ca, c'est un peu les goûts et les couleurs, mais si le code passe une revue de code et des tests unitaires, c'est qu'il devrait être compréhensible.