The document discusses best practices for code reviews. It notes that code reviews should be collaborative, focus on the code quality and functionality rather than personal critiques, and maintain a constructive environment. Effective code review methods include pair programming for continuous feedback, pull requests to facilitate discussion, and focusing comments on improving code rather than criticizing authors. The goal is to maximize productivity while ensuring code quality.

1. Code Reviews

2. Code Review
• At least three problems?
– You hate being critiqued that way
– You’d much rather write more code in that
time
– Project manager says “last time you guys got
together for review, fight ensued and one guy
quit, no more code reviews for you…”
– Venkat Subramaniam Caring About Code Quality

3. Assumption
From the Principles behind the Agile
Manifesto
– Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

4. Why
There are known knowns. These are things
we know that we know. There are known
unknowns. That is to say, there are things
that we know we don't know. But there are
also unknown unknowns. There are things
we don't know we don't know.
--Donald Rumsfeld (February 2002)

5. Known knowns
– Things that you know that you know
– Code it!

6. Known unknowns
– Things you know that you don’t know
– Research
– Ask questions (gasp)

7. Why
Unknown unknowns
– Things you don’t know you don’t know

8. Discussion
Purpose or Goal of a Peer Code Review

9. Purpose
1. Does code accomplish task?
2. Catch bugs early
– Those not found in unit testing
3. Find coding inefficiencies
– Remove unnecessary code
– Avoid code smells
4. Share knowledge
– Team Collaboration
– Increased bus factor
5. Meets standards

10. The buck stops with the code review
process, whereby a change is
accepted for inclusion into the code
base by the developers who control
access to the canonical source
repository. If unit tests are not
required by a code reviewer, then
cruft will pile on top of cruft.
- Martin Fowler Goto Fail, Heartbleed, and Unit Testing Culture
(2014)
Unit Tests!

11. Methods
Ways to do code reviews

12. Methods
• Fagan Inspection
– Developed at IBM
– Code Inspection
– Seven phases
– Four Participants
– …
• see http://www.professionalqa.com/fagan-inspection

13. Just Kidding. Do not do Michael Fagon Method
see http://www.methodsandtools.com/archive/archive.php?id=66

14. Methods
• Self-Review (you talk to the object)
• Also Called Rubber Duck Debugging

15. Methods
• Pair Programming
– Continuous Code Review

16. Discussion
Pull Requests, Pros and Cons

17. The fear of big merges also acts as a deterrent to
refactoring. Keeping code clean is constant effort,
to do it well it requires everyone to keep an eye out
for cruft and fix it wherever they see it. However
this kind of refactoring on a feature branch is
awkward because it makes the Big Scary Merge
much worse. The result we see is that teams using
feature branches shy away from refactoring which
leads to uglier code bases.
Indeed I see this as the decisive reason why
Feature Branching is a bad idea. Once a team is
afraid to refactor to keep their code healthy they
are on downward spiral with no pretty end.
- Martin Fowler, Feature Branch (2009)

18. How to

19. As code author
• Review your own code
• Commit small changes
• Document – self documenting – code
• Provide meaningful commit message

20. As a reviewer
• Do not postpone
– Our culture requires reviews frequent reviews
• Spent sufficient time
– Can be 10 minutes
– Max 60 to 90 minutes
• Know the requirements
• Add expertise

21. Discussion
What to look for in a review

22. Human Factor

23. Human Factor
You are not your code
So criticism of code should not bother you

24. Human Factor
• Code represents work
• Work is time and effort
• Changes to code requires more work
– We all have deadlines
• Code represents expertise
– We all are reviewed

25. Human Factor
Scathing and/or never ending code reviews hurt

26. Human Factor
• Communicate clearly
– Use constructive phrases
– Give examples/suggestions
• Listen to concerns
• Code review is not a place for coding style
wars
– Decide ahead of time what code style is
– Use linters

27. The first rule in decision-making
is that one does not make a
decision unless there is
disagreement.
-Peter Drucker The Effective Executive

28. Tips

29. Keep it Small

30. Tips
• Keep pull request to a single idea
• Tie goes to the runner
– The author of the code is responsible for the
final decision
• Move comments from review to inside of
code
– comments explain why, not what
• In teams, use @specific_person for review
where specific_person has expertise

31. Tips
• Don’t over-do or under-do time on review
• Don’t procrastinate doing review
• “Looks good” is not a code review

32. Goal
Maximize Productivity and Code Quality
You can’t be agile if your code sucks
- venkat subramaniam

33. See Atlassian Article
https://www.atlassian.com/agile/software-development/code-reviews