Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • Connection - 10'
  • Concepts - 10'
  • How to do it ?
  • Who ?
  • When ?
  • Why ?
  • Different Workflows
  • Anti-patterns (List from Trisha Gee)
  • Use a checklist
  • Concrete Practice - Code vengers 30'
  • Debriefing round 1 :
  • Lets do a second round
  • Conclusion - 10'
  • Resources

Was this helpful?

  1. Software craftsmanship
  2. Practices

Code Review

PreviousPair ProgrammingNextCo-designs

Last updated 3 years ago

Was this helpful?

Connection - 10'

  • Describe what are your objectives when you review peer’s code ?

  • How do you do it ?

  • Share in pair

Concepts - 10'

How to do it ?

  • Don't review anything that we can automate

    • Spell check

    • Code beautifier

  • Small batches

    • No more than 200 to 400 lines of code (LOC) at a time

    • Brain cannot process and detect errors if too much data

  • At least two developers sitting together

    • Junior Dev should pair with a more experienced one

    • Whole team when the feature is risky or complex

Who ?

  • Everyone code can be reviewed

    • Any Dev can review

    • The code of the most senior is also reviewed

  • The reviewer

    • should be :

      • Humble

      • Give feedback

      • Don’t blame

    • Need to get knowledge of the functional analysis

    • Checkout the code on his/her workstation and run it

When ?

  • Could be on-demand

  • Or, if the CI quality gate not passed

  • And anyway, before a story can be considered “Done”

Why ?

  • Better code

    • Ensure code meets standards

    • Find bugs

    • Ensure code does what it’s supposed to

    • Check code is understandable

  • Share Knowledge

    • Spread code Ownership

    • No better way to learn the right practices and promote the company’s code guidelines and requirements

  • Collaborate on Design

  • Improve communication inside the team

    • Every team members talk to each others

    • Foster companionship and improve team cohesion

  • Motivate to progress

    • If you keep in mind that your code will be reviewed by some colleagues, you will put more care into it

    • You will take the time to properly :

      • Name identifiers

      • Write tests

      • Introduce well-fitted abstractions

      • Use carefully the enterprise wide patterns

Different Workflows

A developer :

  • Picks up or is assigned a task

  • Implements the code to the best of his/her ability

  • Submits it for review

The reviewer checks the code and, if everything is OK : the code is merged into the main development branch.

  • Learning at the center of the process

  • The purpose is not to check if the code is correct

  • But to share with other developers what changes have been made

Early Design Feedback

  • A collaborative and iterative approach to

    • Check the code frequently while it’s being built

    • So design feedback comes at the right time

Anti-patterns (List from Trisha Gee)

  • My job as a Reviewer is to find problem

    • When you try to find problems, you will always find more problems

    • Always remember that you bring you own preferences / biases

  • Nit picking

    • Spacing is wrong / Formatting

    • Automate this kind of check

    • Waste of time for a human

  • Design changes when the code works

    • You find it too late

    • Design must be discussed early on

  • Inconsistent feedback

    • Feedback biased because I have followed a security training

    • Next week it will be on compliance for example…

    • To avoid this :

      • Have clear guidelines

      • Use checklists

  • The Ghost Reviewer

    • No time for it

    • The bigger the code review, the more likely it will receive a green check

  • Ping Pong Reviews (Between reviewer and author)

    • Happens when you goal is to find problems

    • Have a Definition of Done

    • Clear guidelines

Use a checklist

Example

Concrete Practice - Code vengers 30'

  • Form groups of 3

  • Each team member take :

    • A role card : keep it secret

    • A checklist

    • A code sample

  • 5’ in solo :

    • Prepare a code review as a code-venger : role-play based on your role card.

  • Review time :

    • Each member explains his/her discovery in the code to the two others.

    • They have to guess who is the code-venger

      • And keep note how they feel during the review

Here are the cards

Debriefing round 1 :

  • Who was who in your group ?

  • How did you feel during feedback session ?

Explain things to avoid during code review

  • Judgmental questions :

    • Avoid to say : Why didn’t you just do ___ here?

    • Try it : What do you think about ___, which has the benefit of____?

  • Being sarcastic

    • Avoid to say : Did you even test this code before you checked it in

    • Try it : This breaks when ___. Can you please address this case?

  • Passing off opinion as fact

  • Avoid to say : This component should be ___.

  • Try it : Since this component ___, it could be made ___. This will improve___

Lets do a second round

  • Prepare once again the review of the code by being yourself

    • Try to avoid behavior sentences explained before

Conclusion - 10'

  • Bootstrap your team check-list

    • What / When to review ?

Don’t let code reviews be an ego match

“Being the most senior person on the team does not imply that your code does not need review...”

Resources

Gateway review
Knowledge Sharing
Code Review Best Practices by Trisha Gee
The Code Review Pyramid
Async Code Reviews Are Killing Your Company’s Throughput
Code Review Worflows
Code Review Guidelines by Patrick Smacchia
Ebook "What to look for in a code review"
Video
86KB
code-review-cards.pdf
pdf
Download pdf cards here
959KB
code samples for code review.zip
archive
Code samples for code reviews