Introduction to Code Reviews

If you’ve never participated in a code review before, it can be tough to know where to start. This talk aims to give you the tools you’d need to start using code reviews as part of your team or even on your own. It covers the benefits of code reviews, some items to check, and how to go about performing them.

Transcript

1. INTRO TO CODE REVIEWS KEVIN LONDON www.kevinlondon.com @kevin_london
2. What are code reviews?
3. A discussion.
4. Why bother?
5. http://bit.ly/ms-code-reviews
6. maybe find bugs
7. Share knowledge
8. Improve solutions
9. Grow as a developer
10. “Talk with other programmers; read other programs. This is more important than any book or training course.” -Peter Norvig, "Teach Yourself Programming in Ten Years"
11. What should I check?
12. Find what matters for your team
13. Areas I check:
14. Does it solve the problem?
15. Does it have good design?
16. Does it have good tests?
17. Is it well-documented? http://bit.ly/teach-dont-tell
18. Is it secure? http://bit.ly/owasp-review-top-9
19. Is it secure? http://bit.ly/owasp-review-top-9 • Pickle?
20. Is it secure? http://bit.ly/owasp-review-top-9 • Pickle? • DEBUG=True?
21. Is it secure? http://bit.ly/owasp-review-top-9 • Pickle? • DEBUG=True? • Memory leaks?
22. Is it secure? http://bit.ly/owasp-review-top-9 • Pickle? • DEBUG=True? • Memory leaks? • Subprocess shell=True?
23. Style http://bit.ly/beyond-pep8
24. “I’ve seen quite a few code reviews where someone commented on formatting while missing the fact that there were security issues or data model issues.”
25. More suggestions: http://bit.ly/cr-best-practices
26. How should we do them?
27. asynchronous
28. asynchronous and informal
29. Make them part of your normal process
30. Keep the feedback loop short
31. As a Reviewer:
32. Ask questions
33. Be kind. Who the hell wrote this? Oh, I did.
34. You will not catch everything.
35. Aim for 300-400 lines of code / hour http://bit.ly/smartbear-best-practices
36. Positive criticism It’s about the code, not the developer.
37. Point out good things
38. No “why”s
39. No “why”s No “just”s
40. No “why”s No “just”s No shaming http://bit.ly/giving-technical-help
41. As a Developer:
42. Ask questions
43. Pre-review your code git add <yourfiles> git diff —staged
44. Be open to feedback
45. Rotate reviewers
46. Provide context
47. COMMUNICATION AND COLLABORATION YIELD USEFUL CODE REVIEWS
48. IF YOU’RE NOT DOING CODE REVIEWS YET: TRY THEM! Slides: http://bit.ly/code-reviews-ladjango