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

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

La code review n'est pas une simple formalité, mais une étape cruciale du développement. Surtout en Go, où la simplicité et la lisibilité du code sont ancrées dans la philosophie du langage. Pour les développeurs débutants, cela peut sembler intimidant : comment critiquer le code des autres quand on n'est pas encore sûr de soi ? En réalité, la code review est le meilleur moyen d'apprendre. Dans cet article, nous allons voir sur quoi se concentrer lors de la révision du code Go et comment donner un retour qui soit utile, et non blessant.

1. Principes de base : que rechercher en premier lieu

Avant d'entrer dans les détails, retenez la règle principale : la révision concerne le code, pas la personne. Votre objectif est de trouver des problèmes potentiels et d'améliorer la qualité du produit, pas de prouver que vous êtes plus intelligent. Commencez par les choses simples :

• Erreurs logiques : les cas limites sont-ils correctement traités ? Par exemple, que se passe-t-il si la slice est vide ?
• Paniques potentielles : avez-vous oublié le nil ? Vérifiez que vous n'appelez pas de méthodes sur un pointeur nul.
• Code inutilisé : en Go, cela provoque une erreur de compilation, mais il arrive que des variables ou des imports morts subsistent.

Exemple d'erreur typique de débutant :

func getFirstElement(s []int) int {    return s[0] // Panique si la slice est vide !}

Ce qu'il faut suggérer dans la révision : ajouter une vérification de la longueur de la slice et retourner une erreur.

func getFirstElement(s []int) (int, error) {    if len(s) == 0 {        return 0, fmt.Errorf("slice is empty")    }    return s[0], nil}

2. Idiomes Go : comment écrire « à la go »

Go n'est ni Java ni Python. Il a son propre style, qu'il faut respecter. Lors de la révision, faites attention aux points suivants :

• Nommage : en Go, les noms courts sont de mise (par exemple, r pour reader, w pour writer). Il ne faut pas nommer une variable myReader — juste r.
• Gestion des erreurs : n'ignorez pas les erreurs ! Si une fonction retourne une error, elle doit être vérifiée. L'exception est fmt.Println et similaires, mais il est préférable de les journaliser.
• Interfaces : elles doivent être petites. Une méthode c'est bien, deux c'est déjà trop. Ne créez pas d'interfaces « en prévision ».

Exemple de code « non-go » :

func ProcessData(data []string) (bool, error) {    var result bool    for _, item := range data {        if item == "error" {            result = false            return result, errors.New("found error")        }    }    result = true    return result, nil}

Ici, result n'est pas nécessaire — on peut directement retourner true ou false. Il est également préférable d'utiliser fmt.Errorf pour le formatage.

func ProcessData(data []string) (bool, error) {    for _, item := range data {        if item == "error" {            return false, fmt.Errorf("found error in item: %s", item)        }    }    return true, nil}

3. Performances et mémoire : à quoi faire attention

Bien que Go soit assez rapide, un mauvais code peut tout gâcher. Lors de la révision, vérifiez :

• Évitez les allocations inutiles : si vous connaissez la taille de la slice, utilisez make en spécifiant la capacité.
• Copie de structures : les grandes structures doivent être passées par pointeur pour éviter de les copier à chaque fois.
• Goroutines : vérifiez que vous n'avez pas oublié de fermer un canal ou d'attendre la fin d'une goroutine (utilisez sync.WaitGroup).

Exemple de mauvaise gestion d'une slice :

func appendItems(items []int) []int {    var result []int    for _, v := range items {