Code Reviews FTW!

About a year ago, we started to use code reviews in some teams in SUSE. What experience we gained and what benefits do we see? How does a good review look like? What should a reviewer focus on and what should he/she avoid? And do code reviews make sense for you? We will try to answer all these questions.

Presented at Prague Ruby meetup.

Details:
http://srazy.info/prvni-streda-ruby-on-rails/3081
https://www.facebook.com/events/371737466254694/

Transcript

1. Code Reviews FTW! Prague, 6th February 2013 Josef Reidinger David Majda &
2. Why? 1
3. better code better design bus factor learning feel for quality social pressure
4. How? 2
5. Code Change Pull Request Review Merge Accept Reject
6. Checklist 3
7. 1. Is it easy to read? 2. Do I understand what it does? 3. Boy scout rule 4. Can I make it better?
8. Code Quality 4
9. Have I Already Seen This?
10. Easy to Extend?
11. Covered by Tests?
12. Are Errors Handled?
13. Follows Coding Style?
14. Has Proper Level of Abstraction?
15. Is The Change Isolated?
16. Bugs Are Social!
17. Overengineering!
18. Social Aspects 5
23. Challenges 6
24. Big Branches
25. The Never Ending Story
26. Act like you start maintaining it tomorrow!