The Science of Code Reviews

We all make mistakes, as much as we try to write flawless code, every now and then an error slips through. In order to reduce this number we do code reviews to ensure the code meets certain standards and to see if the feature was properly implemented. But how do you do a good code review? How do you handle technical discussions? How do you keep your reviews focused and your discussions relevant? In this talk I would like to show you how you can do proper code reviews, what to look out for when doing them, how to give feedback to the developer and a bunch of other tips to improve this process.

Transcript

1. T H E S C I E N C E O F C O D E R E V I E W S
   R I C K K U I P E R S / @ R S K U I P E R S
   

   View Slide

2. @RSKUIPERS
   RICK KUIPERS
   DEVELOPER
   @PHPAMERSFOORT
   SPEAKER
   @PHPSTORMTIPS
   GAMER
   @ENRISE
   

   View Slide

3. MEETSPIRE
   UP IN
   +
   

   View Slide

4. View Slide

5. W E W E R E N O L O N G E R J U S T L E A R N I N G F R O M O U R O W N M I S TA K E S ,
   B U T A L S O F R O M E A C H O T H E R ' S M I S TA K E S .
   

   View Slide

6. A formal assessment of code with the intention of instituting change if necessary.
   CODE REVIEW
   

   View Slide

7. ! Readability
   ! Architecture
   ! Sharing knowledge
   ! Bugs
   WHY?
   

   View Slide

8. View Slide

9. PULL REQUEST REVIEW
   

   View Slide

10. PAIR PROGRAMMING
    DRIVER
    NAVIGATOR
    

    View Slide

11. MOB PROGRAMMING
    DRIVER
    NAVIGATOR
    NAVIGATOR
    NAVIGATOR
    

    View Slide

12. DO YOU HAVE COLLEAGUES REVIEW YOUR CODE?
    17%
    73%
    Yes
    Only when I ask
    We use pair programming as a form of code review
    No, we only rely on automated tools
    No, a tester only functionally tests the code
    No
    

    View Slide

13. DO YOU FEEL LIKE YOU LEARN A LOT FROM GIVING AND
    RECEIVING CODE REVIEWS
    4%
    96%
    Yes No
    

    View Slide

14. DO YOU ENJOY GETTING YOUR CODE REVIEWED?
    13%
    87%
    Yes
    Usually, but sometimes I find it hard to accept feedback or deal with criticism
    No
    

    View Slide

15. EGOLESS PROGRAMMING
    "Developers need a robust enough ego to trust and defend their work, but not so
    much ego that they reject suggestions for better solutions. Similarly, the egoless
    reviewer should have compassion and sensitivity for their colleagues, if only
    because their roles will be reversed one day.”
    Source: Humanizing Peer Reviews, Karl E. Wiegers.
    

    View Slide

16. THE TEN COMMANDMENTS OF
    EGOLESS PROGRAMMING
    1. Understand and accept that you will make mistakes.
    2. You are not your code.
    3. No matter how much "karate" you know, someone else will always know more.
    4. Don't rewrite code without consultation.
    5. Treat people who know less than you with respect, deference, and patience.
    6. The only constant in the world is change.
    7. The only true authority stems from knowledge, not from position.
    8. Fight for what you believe, but gracefully accept defeat.
    9. Don't be "the guy in the room.”
    10. Critique code instead of people – be kind to the coder, not to the code.
    

    View Slide

17. ! Unhappy paths
    ! Tests added
    ! Feature implemented according to specs
    ! Performance
    ! Security
    WHAT TO LOOK FOR DURING A CODE REVIEW
    

    View Slide

18. C O D E R E V I E W E T I Q U E T T E
    

    View Slide

19. DON’T JUMP TO CONCLUSIONS
    

    View Slide

20. COMMUNICATE CLEARLY
    

    View Slide

21. USE EXAMPLES
    

    View Slide

22. THANK YOU
    

    View Slide

23. GIFS
    

    View Slide

24. View Slide

25. You own the code…
    With code reviews…
    As a team!
    

    View Slide

26. We should …
    I think we should …
    

    View Slide

27. What do you think?
    

    View Slide

28. ! Introduce branching
    ! Automate menial tasks like code style checks and linting
    ! Let everyone participate
    ! Give everyone the right to merge
    GETTING STARTED
    

    View Slide

29. ! Code and functional reviews
    ! Get a 3rd opinion
    ! Keep changes small
    ! Don't trust the developer
    ! Review using your favourite tool
    ! Shared vision
    IMPROVING CODE REVIEWS
    

    View Slide

30. ARCHITECTURAL EXPLORATION
    1 HOUR
    !
    " PRESENT AND DISCUSS
    # TAKE NOTES
    $ SCHEDULE A MEETING
    

    View Slide

31. WHY AREN'T CODE REVIEWS PART OF YOUR COMPANIES
    WORKFLOW?
    4%
    28%
    30%
    38%
    We have never discussed this
    We feel our projects are too small to do code reviews
    Management thinks it's a waste of time/money
    As a developer, I don't see the value in doing code reviews
    

    View Slide

32. 1. Start the trend
    2. Return the favour
    3. Measure the impact
    4. Show your boss
    CONVINCING YOUR COMPANY
    IN 4 EASY STEPS
    ! Increased customer satisfaction
    ! Developers learning from each other
    ! Takes 15 minutes per feature
    ! Part of the price
    

    View Slide

33. View Slide

34. T H E E N D
    R I C K K U I P E R S / @ R S K U I P E R S
    

    View Slide