Code review en Go : quoi vérifier et comment donner un retour aux débutants

Code review en Go : quoi vérifier et comment donner un retour

Code review (révision de code) — ce n'est pas seulement une vérification formelle avant de fusionner une pull request. C'est un outil puissant pour améliorer la qualité du code, partager les connaissances au sein de l'équipe et prévenir les erreurs dès les premières étapes. Pour les développeurs Go débutants, participer à une révision peut sembler stressant : on craint de recevoir des remarques ou, au contraire, de laisser passer une erreur critique. Dans cet article, nous allons voir à quoi faire attention lors de la révision de code Go et comment donner un retour qui soit utile, sans être blessant.

Pourquoi le code review est-il important en Go ?

Le langage Go a été conçu en mettant l'accent sur la simplicité, la lisibilité et la fiabilité. Cependant, la simplicité de la syntaxe n'annule pas la complexité de la logique. Les problèmes typiques dans les projets Go : l'ignorance des erreurs, une mauvaise gestion des goroutines, des fuites de ressources. Une bonne code review permet de détecter ces problèmes et d'autres avant qu'ils n'atteignent la production.

Que vérifier dans le code Go : une checklist pour les débutants

Pour que la révision soit systématique, utilisez une checklist. Voici les points principaux à vérifier dans chaque pull request.

1. Gestion des erreurs (error handling)

En Go, les erreurs sont des valeurs, on ne peut pas les ignorer. Vérifiez que chaque fonction qui retourne une error la traite ou la transmet explicitement vers le haut.

// Mauvais : on ignore l'erreur\nfile, _ := os.Open("config.yaml")\n\n// Bon : on traite l'erreur\nfile, err := os.Open("config.yaml")\nif err != nil {\n    log.Fatalf("cannot open config: %v", err)\n}\ndefer file.Close()

Vérifiez également que les erreurs sont encapsulées avec fmt.Errorf("...: %w", err) pour transmettre le contexte, et non simplement journalisées et avalées.

2. Nommage et lisibilité

En Go, on utilise des noms courts pour les variables (par exemple, r pour reader, w pour writer) et des noms longs pour les fonctions exportées. Vérifiez que :

\n
• Les fonctions, types et variables exportés ont des commentaires (commençant par le nom de l'entité).
\n
• Les noms de variables reflètent leur fonction (pas a, b, tmp).
\n
• Il n'y a pas d'abréviations inutiles (calc est mieux remplacé par calculate).
\n

3. Gestion des goroutines et de la concurrence

Les goroutines sont un outil puissant mais dangereux. Vérifiez :

\n
• Y a-t-il un mécanisme de synchronisation (canaux, mutex) pour les données partagées.
\n
• Ne crée-t-on pas des goroutines « fuyantes » (goroutine leak). Utilisez le contexte (context.Context) pour l'annulation.
\n
• La goroutine n'est-elle pas bloquée indéfiniment (deadlock).
\n

// Exemple de travail sécurisé avec une goroutine\nfunc worker(ctx context.Context, jobs <-chan int, results chan<- int) {\n    for {\n        select {\n        case job, ok := <-jobs:\n            if !ok {\n                return\n            }\n            results <- job * 2\n        case <-ctx.Done():\n            return\n        }\n    }\n}

4. Gestion des ressources (defer)

Vérifiez que tous les fichiers ouverts, connexions réseau, transactions de base de données sont fermés via defer. Cela doit être fait immédiatement après l'ouverture réussie de la ressource.

// Correct : on ferme immédiatement\nconn, err := net.Dial("tcp", "example.com:80")\nif err != nil {\n    return err\n}\ndefer conn.Close()

5. Tests

Les débutants oublient souvent les tests. Assurez-vous que des tests unitaires sont écrits pour la nouvelle logique. Vérifiez :

\n
• Les tests couvrent non seulement le chemin heureux (happy path), mais aussi les cas limites.
\n
• t.Run est-il utilisé pour les sous-tests.
\n
• Il n'y a pas de tests qui dépendent de ressources externes (base de données, réseau) sans mocks.
\n

Comment donner un retour : 5 règles pour les débutants

La partie technique n'est que la moitié du travail. L'autre moitié est la capacité à communiquer. Voici comm