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
2. @RSKUIPERS RICK KUIPERS DEVELOPER @PHPAMERSFOORT SPEAKER @PHPSTORMTIPS GAMER @ENRISE
3. MEETSPIRE UP IN +
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 .
6. A formal assessment of code with the intention of instituting change if necessary. CODE REVIEW
7. ! Readability ! Architecture ! Sharing knowledge ! Bugs WHY?
9. PULL REQUEST REVIEW
10. PAIR PROGRAMMING DRIVER NAVIGATOR
11. MOB PROGRAMMING DRIVER NAVIGATOR NAVIGATOR NAVIGATOR
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
13. DO YOU FEEL LIKE YOU LEARN A LOT FROM GIVING AND RECEIVING CODE REVIEWS 4% 96% Yes No
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
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.
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.
17. ! Unhappy paths ! Tests added ! Feature implemented according to specs ! Performance ! Security WHAT TO LOOK FOR DURING A CODE REVIEW
18. C O D E R E V I E W E T I Q U E T T E
19. DON’T JUMP TO CONCLUSIONS
20. COMMUNICATE CLEARLY
21. USE EXAMPLES
22. THANK YOU
23. GIFS
25. You own the code… With code reviews… As a team!
26. We should … I think we should …
27. What do you think?
28. ! Introduce branching ! Automate menial tasks like code style checks and linting ! Let everyone participate ! Give everyone the right to merge GETTING STARTED
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
30. ARCHITECTURAL EXPLORATION 1 HOUR ! " PRESENT AND DISCUSS # TAKE NOTES $ SCHEDULE A MEETING
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
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
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