A developer opens a pull request that adds a discount calculation to a checkout service. The tests pass and the diff is short. A reviewer approves it in two minutes with "LGTM". Three months later a teammate needs to change the same function and discovers that it mixes pricing rules, rounding and database access in one place. Nobody can say with confidence what it is allowed to do.
This is an illustrative scenario, not a documented incident. It shows what peer code review has to produce when it is working as a learning activity: a reviewer who can see a plausible change, spot the concern that is not a bug yet, and explain it in a way the author can act on.
This guide is for engineering enablement leads and engineering managers. It shows how to design code review exercises that build that skill on purpose, instead of hoping reviewers pick it up from the queue. It covers the performance problem, the gaps to diagnose, how to structure preparation and practice, one worked example, and how to check the skill carries over to real reviews. Have senior engineers validate every case, defect and criterion before you use it.
What are code review exercises?
Code review exercises are structured practice tasks in which a developer reviews a prepared change, explains what they found and why it matters, and gets feedback on the quality of that explanation. They are different from the reviews your team does every day. The change is chosen in advance, the concerns in it are known, and the aim is to improve the reviewer rather than to ship the change.
त्वरित तथ्य
| सवाल | संक्षिप्त जवाब |
|---|---|
| कार्य क्या है? | Explain review findings and give feedback the author can act on. |
| आपका स्कोर क्या है? | Accuracy of the findings and how useful the explanation is. |
| Is counting defects enough? | No. Reviews are about more than defects, so an exercise that rewards only the bug count trains the wrong habit. |
| संज्ञानात्मक आवश्यकता क्या है? | Analyse and evaluate a design, then create a better suggestion. |
| इस मामले की पुष्टि कौन करता है? | An engineering manager or senior engineer who owns the codebase. |
| What can exercises not fix? | Review time, unclear ownership and pressure to merge quickly. |
| आपको कैसे पता चला कि यह काम कर गया? | A new, unseen change reviewed against agreed criteria, plus a follow-up on real reviews. |
1. प्रदर्शन संबंधी समस्या का वर्णन करें।
Start with the task, in one sentence: given a change, the reviewer explains what they found, why it matters and what the author could do about it. "Explains" is the important word. Spotting an issue is half the skill. Saying it so that a colleague with a different view can understand it, weigh it and act is the other half.
Research on modern code review supports looking beyond bug-hunting. In a study at Microsoft, Bacchelli and Bird observed, interviewed and surveyed developers and managers. They found that finding defects was still the main motivation for review, but that reviews were less about defects than people expected. They also delivered other benefits, such as knowledge sharing, team awareness and alternative solutions, and the researchers described code and change understanding as the key aspect of review (Bacchelli and Bird, ICSE 2013). It is a study of one company's teams, so use it as a reason to design for understanding, not as a rate for yours.
Google's published review standard points the same way. It tells reviewers to favour approving a change once it definitely improves the overall health of the code, even if it is not perfect, and it says that review can teach developers something new, so comments that help someone learn are welcome (Google Engineering Practices). Both sources describe review as a place where judgment is exercised and passed on. That is what your exercises should rehearse.
2. सीखने और संदर्भ संबंधी कमियों का निदान करें
Compare the task with what your current programme practises and assesses.
- क्या वर्तमान कार्यप्रणाली में वास्तविक कार्य का उपयोग किया जाता है? If new reviewers learn by reading a style guide and then reviewing live pull requests, they practise on real work with no safe place to be wrong. If assessment is a quiz on review etiquette, it measures recall of the rules, not the ability to apply them to a change.
- संज्ञानात्मक आवश्यकता क्या है? In the revised Bloom's taxonomy, judging whether a design is sound and weighing its trade-offs sits at the analyse and evaluate levels, and proposing a better structure reaches the create level. If your exercises only ask "what does this code do?", they stop at understanding. Our guide to ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना shows how to match the activity to the level.
- क्या कौशल के अलावा कोई और चीज बाधा बन रही है? Check review time, tooling, ownership and team norms. If reviewers have five minutes per pull request, no exercise will produce a thoughtful explanation. If authors take every comment as criticism, reviewers will soften their findings until they say nothing. Report these causes to the people who can fix them.
3. Design preparation, practice and feedback
Give each stage a separate job.
तैयार करना। Check what reviewers need before they start: the team's review checklist, the design principles it relies on, and how to read a diff in your tooling. Keep this self-paced and short. A recall check confirms prerequisites only, and it is not evidence that someone can review.
अभ्यास करें. Use prepared changes with a small number of seeded concerns of different kinds: a correctness bug, a maintainability problem such as the mixed responsibilities in the opening example, an unclear name or missing test, and some code that is fine. Ask the reviewer to write the comment they would leave, rank the concerns and say what further information they would want. CodeRefinery's hands-on lesson shows the shape: people open a pull request containing a small typo and a larger mistake, then review it as a peer (CodeRefinery, Practicing code review). Build yours from your own codebase so the conventions and trade-offs are real.
प्रतिक्रिया। Link it to the decisions the reviewer made. "You noticed the rounding problem but your comment said 'this looks wrong' without saying what input breaks it" is more useful than "found 2 of 4".
लाइव इनपुट या अतुल्यकालिक समीक्षा? Live input adds most value when a concern is ambiguous and reviewers learn from hearing a senior engineer say why they would raise it, or let it go. Asynchronous review is enough for comparing comments with an annotated expert review.
4. एक वास्तविक उदाहरण के माध्यम से काम करें
उदाहरण के तौर पर। इंजीनियरिंग मैनेजर को उपयोग करने से पहले मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।
मामला। A change adds a discount calculation to a checkout service. It passes its tests. In one function it applies percentage and fixed discounts, rounds the result, writes to the database and sends an event. It has one test, for a single percentage discount.
कार्य। The reviewer writes the comments they would leave, ranks their concerns and says what they would need to know before approving.
पहला प्रयास। "Looks fine, the test passes. Maybe split it up?" The reviewer has noticed something but has not said what, why it matters or what to do. The author cannot act on this.
प्रतिक्रिया दें और पुनः प्रयास करें। The facilitator asks: what would a future change to this function risk breaking? What would you ask the author to add before you approve? The retry asks for a specific comment on each concern, with the reason and a suggestion.
एक और मजबूत प्रयास। "The function applies two kinds of discount, rounds, saves and publishes an event, so a change to rounding could alter what we store and what we publish at the same time. I would ask for the pricing rules to move into a pure function we can test on its own. The single test covers a percentage discount only. I would ask for a fixed discount and an order that brings the total to zero. I am not sure whether the event is meant to fire when the total is zero, so I would ask the author." Notice that this comment names the concern, gives the reason, makes a concrete suggestion and states what the reviewer does not know.
5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं
Evidence of capability is performance on a new change the reviewer has not seen. Score the accuracy of the findings and the usefulness of the explanation. A simple rubric uses a 0 to 2 scale per criterion:
| कसौटी | प्रत्यक्ष साक्ष्य |
|---|---|
| कार्य निष्पादन | Finds the relevant concerns in the change and records the evidence for each one. |
| विचार | Explains why each concern matters, offers an alternative and says what remains uncertain. |
| सीमाएँ | Follows the team's review rules and asks for help or information when authority or context is missing. |
Anchors: 0 means absent or unsupported, 1 means partial with relevant omissions, and 2 means complete and justified against agreed criteria. Define critical errors separately, for example approving a change with a data-loss risk, so that a good overall score cannot hide one. Adapt the criteria with the engineering manager; this rubric is a starting proposal, not a validated readiness standard. For more on scoring reasoning, see our guide to उपयोगी प्रतिक्रिया के साथ इंटरैक्टिव अभ्यास डिजाइन करना.
Plan for transfer. After the exercise, check a sample of the reviewer's real reviews a few weeks later, using the same criteria. Compare with a baseline taken before training and define the population and timing up front. Look at other changes that happened in the same period, such as a new review tool or a staffing change, before crediting the exercises.
6. Run the exercise live or self-paced with AhaSlides
You can run the exercise in a workshop or let reviewers work through it on their own. In a live session, show the prepared change and use interactive slides for the discussion:
- उत्तर उठाओ for "which concern would you raise first?", with the seeded concerns as options. Show the spread before you reveal your own ranking.
- ओपन एंडेड for "write the comment you would leave". Reviewers can compare their wording with others, which is where the explanation skill shows.
- रेटिंग स्केल for "how severe is this?", so the group can see where judgments differ and talk about why.
For reviewers who cannot attend, the same sequence can be used self-paced, with the annotated expert review shown after each response. Treat any claim about code execution, integrations or AI features as unconfirmed until you have tried it with your own material.
If you also train reviewers on AI-written code, see our companion guide on AI-generated code review training. That post is about auditing generated output. This one is about how people review each other's work, and how they explain what they find.
वे बाधाएं जो बनी रह सकती हैं
- समीक्षा का समय। A thoughtful comment takes longer than "LGTM", and deadlines push towards the short version.
- Team norms. If feedback is read as a personal criticism, reviewers will soften or drop their findings.
- मामले का विवरण। One exercise shows a few kinds of concern. A score does not describe a reviewer's judgment in general.
- स्थानांतरण। Performance in a workshop is not the same as performance on a busy queue, so check real reviews as well.
Name these to sponsors early and plan separate fixes. Exercises improve what a reviewer can see and explain. They do not create the time or the norms.
ज़्यादातर पूछे जाने वाले सवाल
What are code review exercises?
They are prepared practice tasks in which a developer reviews a change with known concerns, writes the comments they would leave and gets feedback on accuracy and usefulness. The aim is to build the reviewer's skill, not to ship the change.
How do you assess whether a reviewer's judgment has improved?
Give a new change they have not seen and score the findings and the explanation against agreed criteria. Then check a sample of real reviews some weeks later. A quiz on review rules confirms prerequisites only.
Is peer code review mainly about finding bugs?
Finding defects is still a main motivation, but one study at Microsoft found that reviews were less about defects than expected and also delivered knowledge sharing and team awareness. Design exercises that reward explanation and understanding as well as the defect count.
कहा से शुरुवात करे
Pick one kind of change your team reviews often. Write the performance statement, ask a senior engineer to prepare one change with three or four seeded concerns, and draft a three-criterion rubric with a 0 to 2 scale and a list of critical errors. Pilot it with a small group, then compare their next real reviews with a baseline.
To see how a review exercise could run live with your own team, and be reused self-paced afterwards, explore AhaSlides.
