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

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

MEETSPIRE UP IN +

No content

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 .

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

! Readability ! Architecture ! Sharing knowledge ! Bugs WHY?

No content

PULL REQUEST REVIEW

PAIR PROGRAMMING DRIVER NAVIGATOR

MOB PROGRAMMING DRIVER NAVIGATOR NAVIGATOR NAVIGATOR

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

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

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

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.

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.

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

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

DON’T JUMP TO CONCLUSIONS

COMMUNICATE CLEARLY

USE EXAMPLES

THANK YOU

GIFS

No content

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

We should … I think we should …

What do you think?

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

! 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

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

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

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

No content

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