About code reviews and BUGS

Adopting code review into the software development practice is a good way to drive high quality code, improve team communication and knowledge sharing. We'll look at the best strategies to adopt it and continue to use it in the most proficient way.

Presentation held during an #apericoder of the montacchiello.dev group.

Transcript

1. About code reviews and BUGS
2. Famous software in history • 1962 - NASA Mariner 1 mission, spacecraft destroyed ◦ 18 million USD • 1988 - Morris Worm experiment at MIT ◦ 50.000 USD • 1994 - Pentium FDIV ◦ 475 million USD • 2010 - Mt. Gox bitcoin exchange ◦ 850.000 bitcoins • 2012 - Knight Capital Group investments ◦ 440 million USD
3. The cost of a
4. Test failure while coding, immediate fix 1 €
5. A colleague spots a bug during code review, few minutes fix 10 €
6. During QA testing, receive a vague bug report, spend time reproducing it, write the fix and release after an hour 100 €
7. In production, different users spot the a bug “it just don’t work”, 8 hours of work 1000 €
8. Too many defects, release postponed by few weeks 10.000 €
9. Too many defects and missing features, release postponed by months 100.000 €
10. Release to production even with many defects and missing features: bad user experience, loss of credibility project failure
12. Good to have practices to the rescue • Source code VC • Bug tracker • Dependency Management • Configuration Management • Automated deployment • Continuous Integration • Data management • Continuous delivery • Code reviews
13. CODE REVIEWS
14. 1. Write code 2. Ask for feedback 3. Repeat until OK
15. WHY
16. Find bugs before your customers do
17. Meets specifications
18. Shared ownership
19. Keep the bar high
20. Leave a written trail
21. Mentorship by default
22. Asynchronous feedback
23. HOW (as a submitter)
24. Avoid wall of diff
25. Contain not interesting changes
26. Solve one thing at a time
27. Provide context
28. Highlight most interesting points
29. Respect for your colleagues time
30. HOW (as a reviewer)
31. Be polite
32. Learn context before starting
33. Give feedback that helps
34. Look for missing tests and edge cases
35. Pay attention to what tools can’t find
36. our process