Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 77

French Code Review Leadership

Recommended resources

Bonjour !

In our last lesson, we practiced how to defend a technical approach during a planning meeting. You learned to structure your arguments, express opinions, and disagree professionally. This was about advocating for your own ideas.

Today, we'll flip the script. We'll focus on a crucial collaborative skill for any senior engineer or project manager: giving feedback on someone else's work. Our goal is to lead a segment of a mock code review, explaining your feedback in French. A code review (une revue de code) is more than just finding bugs; it's a key process for ensuring quality, sharing knowledge, and building a collective sense of ownership over the codebase.

By the end of this lesson, you'll have the frameworks and the specific French vocabulary to provide feedback that is constructive, respectful, and effective.

1. The Philosophy of a Good Code Review

Before diving into phrases, it's essential to understand the mindset behind a successful code review. It's a dialogue, not a judgment. The goal is to improve the code, not to criticize the author.

Let's watch a video from a French senior developer who explains this philosophy very well. He discusses how a code review transforms "your code" into "the team's code" and outlines the principles of giving good feedback.

Ce que les Développeurs Seniors ne vous Disent PAS sur la Revue de Code

The video 'Ce que les Développeurs Seniors ne vous Disent PAS sur la Revue de Code' from the channel Codeur Senior offers an excellent perspective on the human and technical aspects of code reviews.

Please watch the beginning of the video, from 00:00 to 03:24. Pay attention to these key ideas: The core purpose of a code review: votre code devient le code de l'équipe (your code becomes the team's code). The negative impact of unhelpful feedback like just writing rework. The three essential parts of good feedback he introduces.

As the video explains, all constructive feedback should accomplish three things:

  1. Explain the problem (expliquer pourquoi c'est un problème).
  2. Suggest a solution (donner la solution).
  3. Be respectful (être respectueux).

Keeping these principles in mind will be the foundation for everything we practice today.

2. Frameworks for Structuring Feedback

To ensure your feedback is always constructive, you can use established communication frameworks. These models help you structure your thoughts and avoid language that might put your colleague on the defensive.

A. The Non-Violent Communication (NVC) Model

The NVC model is excellent for focusing on objective facts and personal perspective, rather than making accusatory statements.

Communication : 50 phrases d'entretien d'embauche & exemples

The article 'Communication : 50 phrases d'entretien d'embauche & exemples' provides a great introduction to the Non-Violent Communication framework.

Please read the first part of the article, down to the second example about washing dishes. Focus on the five steps presented in the table: Observation (J'ai remarqué que...) Sentiment du moi (Your feeling) Besoin du moi (Your need) Demande (Request) Question participative (Participatory question)

In a code review context, you might simplify this. The key takeaway is to start with an objective observation: "J'ai remarqué que..." (I noticed that...) instead of "Tu as fait une erreur ici." (You made a mistake here).

B. The Situation-Behavior-Impact (SBI) Model

The SBI model, often associated with the "Radical Candor" philosophy, is very popular in tech environments. It's direct, clear, and action-oriented.

Entretien avec un développeur de logiciels : 6 exemples de feedbacks

This article, 'Entretien avec un développeur de logiciels : 6 exemples de feedbacks', explains a powerful feedback model tailored for developers.

First, read the section 'Radical Candor : La méthode de feedback qui fonctionne mieux pour les développeurs de logiciels' to understand the concept. Then, study the section 'Modèle de feedback pour les développeurs de logiciels basé sur Radical Candor' which details the SBI model (Situation, Behavior, Impact).

Here’s how you can adapt the SBI model for a written code review comment:

  • Situation: Briefly mention the specific line or block of code.
  • Behavior (Observation): Describe what the code does objectively. "This function fetches data and then processes it."
  • Impact: Explain the consequence. "This makes the function harder to test and reuse."
  • Action (Next Steps/Suggestion): Propose a change. "Could we split it into two separate functions?"

3. Key Phrases and Strategies for Code Review

Now that we have the frameworks, let's learn the specific vocabulary. There are different ways to deliver feedback, from a gentle question to a direct suggestion.

Developer Performing Code Review
A code review is a systematic examination of computer source code, intended to find and fix mistakes, improve code quality, and share knowledge among a development team.

The "Codeur Senior" video we watched earlier outlines three excellent strategies for commenting. Let's explore them.

Ce que les Développeurs Seniors ne vous Disent PAS sur la Revue de Code

Let's return to the 'Codeur Senior' video to learn about three distinct types of comments you can make in a code review.

Watch the segment from 03:24 to 10:15. The speaker details three ways to give feedback, in increasing order of directness. Focus on understanding the purpose of each: Poser une question (Asking a question): To clarify your understanding when you lack context. Partager une réflexion (Sharing a thought): To propose an idea without imposing it. Suggérer une modification (Suggesting a modification): To propose a concrete change when you are confident.

Here is a summary of useful phrases for each strategy, including examples from our other resources.

Strategy Purpose Example Phrases
1. Poser une question To understand the "why" behind the code. Perfect when you're unsure or new to a codebase. - Je ne suis pas sûr de comprendre cette partie. Pourrais-tu m'expliquer le raisonnement ? (I'm not sure I understand this part. Could you explain the reasoning?)
- Est-ce qu'il y a une raison particulière pour laquelle tu as choisi cette approche ? (Is there a particular reason you chose this approach?)
2. Partager une réflexion To propose a potential improvement as an idea, not a command. It invites discussion. - Juste une réflexion : et si on extrayait cette logique dans un service à part ? Ça pourrait être réutilisé ailleurs. (Just a thought: what if we extracted this logic into a separate service? It could be reused elsewhere.)
- Je me demande si on ne pourrait pas simplifier cette condition. (I wonder if we couldn't simplify this condition.)
3. Suggérer une modification To recommend a specific change. Use this when you're confident about the improvement. - Je suggère de renommer cette variable en 'isUserActive' pour plus de clarté. (I suggest renaming this variable to 'isUserActive' for clarity.)
- Il serait utile de faire des suggestions plus concrètes pour que tes collègues comprennent mieux comment améliorer le code. (This is a meta-comment you can adapt). Ici, il serait utile d'ajouter un commentaire pour expliquer ce calcul complexe.

The article "Communication : 50 phrases d'entretien d'embauche & exemples" also provides excellent, direct examples. Under the subsection "Commentaires sur la section : Revues de code", you can find this gem for when feedback is too brief:

"J’ai remarqué que ton feedback dans les revues de code est souvent très succinct. Il serait utile que tu fasses des suggestions plus concrètes..."

This shows how you can even give feedback on the feedback process itself!

4. Practice Scenario: Mock Code Review

It's time to put all this into practice.

The Context:
You are reviewing a pull request from a junior colleague, Lucas. The code is for a new feature that displays user profile information. The code works, but you see some areas for improvement.

The (simplified) code has these issues:

  1. A very long function: A single function fetchAndDisplayUser() is over 100 lines long. It fetches data from an API, formats three different data fields, and then updates the UI. This violates the Single Responsibility Principle.
  2. An ambiguous variable name: The function uses a variable named d to hold the user data object. This is not very descriptive.
  3. A magic number: The code includes the line if (user.status === 2). Nobody knows what 2 means. It should be a named constant (e.g., STATUS_ARCHIVED).

Your Task:
Write three separate comments in French for Lucas's pull request, one for each issue. Use the frameworks and phrases we've learned. Aim for a supportive and collaborative tone.

  1. Address the long function. (Try using a question or a reflection).
  2. Address the ambiguous variable name. (A direct suggestion would work well here).
  3. Address the magic number. (A question would be a great way to point this out).
Click here to see a model answer

Here are some examples of how you could write your comments. Your own versions are perfectly fine as long as they are constructive and clear!

1. For the long function (using a reflection/question):

Salut Lucas, merci pour ton travail sur cette feature ! En lisant le code, je me suis fait une réflexion sur la fonction fetchAndDisplayUser(). Elle est assez longue et gère plusieurs responsabilités (la récupération des données, le formatage, et l'affichage). Qu'en dirais-tu de la diviser en plusieurs fonctions plus petites, par exemple fetchUserData(), formatUserProfile(), et displayProfile() ? Cela pourrait rendre le code plus facile à lire et à tester.

2. For the ambiguous variable name (using a suggestion):

Petite suggestion pour améliorer la lisibilité : je propose de renommer la variable d en userData. Ce sera plus explicite pour la prochaine personne qui lira ce code.

3. For the magic number (using a question):

Ici, je vois user.status === 2. Pourrais-tu m'éclairer sur ce que signifie le statut 2 ? Peut-être qu'on pourrait définir une constante (par exemple const STATUS_ARCHIVED = 2) pour rendre cette condition plus compréhensible.

Conclusion

Excellent travail ! You've just practiced one of the most important communication skills in software development. Giving effective feedback not only improves code quality but also helps mentor junior developers and strengthens team collaboration.

Key Takeaways:

  • A code review is a collaborative process aimed at improving the code, not judging the author.
  • Frameworks like NVC and SBI help you structure feedback constructively, focusing on objective observations and impacts.
  • You can modulate your feedback by choosing to ask a question (poser une question), share a thought (partager une réflexion), or suggest a modification (suggérer une modification).
  • Always be respectful and aim to start a dialogue.

Preview of the Next Lesson:
In our next lesson, we'll continue with high-stakes professional communication, but in a different context. We will prepare for the tech job interview by learning how to respond spontaneously to common questions from a mock job interview.

À bientôt