This is a short but informative introduction to peer reviews

1. Why, What, How ?
17thJune2013
CharutaJoshi

2. •None of the material
presented in this
presentation is original.
•It bears strong resemblance
to the ideas presented in
“Best Secrets of Code
Review” by Jason Cohen
http://www.amazon.com/gp
/product/1599160676
•The resemblance is
intentional to get practical
advice about benefits & uses
of peer code reviews.

3. •Study conducted for 3 months
for 10000 line project with 10
developers.
Result:
•Code review would have saved
HALF the cost and uncovered 162
additional bugs
•$1 billion bug
•Challenger fiasco
WHY

4. WHY: BENEFITS
Improved Code
Quality
Fewer defects in
code
Improved
Knowledge
transfer
Education of junior
programmers
Direct

5. WHY: BENEFITS
Shorter
development/test
cycles
Reduced impact
on technical
support
More customer
satisfaction
More maintainable
code
Indirect

6. •Peer Code reviews are GREAT..FOR OTHERS
•WHY?
But we don’t really like them..

7. •Because we are NOT
machines.
•We take our code
personally.
•Our work represents our
creativity and we are not
always open to critique
But we don’t really like them..

8. •Hurt Feelings
• I am not the ONLY one to do that.
• You could say it a nicer way.
• It was a genuine mistake.
• Can you even do it yourself?
•Treat reviews as an opportunity to
learn from each other.
•Have fun, don’t make it personal
•The “Big-Brother” effect
•My manager will track my defects.
•My peers might have less defects than me.
•This will definitely impact my performance
review
WHY : -ve Social Impacts

9. WHY : But it is NOT ALL bad

10. •Begins even before first round
•Want to take pride in our work
•Create a reputation
•Accountability
WHY : +ve impacts – The “Ego Effect”
Nobody wants to be this
NPE guy !!

11. •Peer Reviewer Question : Why is the constant on left side while
comparing?
•Programmer Answer : I avoid Null Pointers if status is null
•Reviewer learns a new trick right away. Both had fun doing it !
(anyways more fun than writing & reading a coding guideline document
;) )
WHY : +ve impacts – Old Habits Die Easy

12. •Peer reviews highlight our mistakes
common programming with minimum
of impact
•If we maintain a list and avoid those, we
are on our way.
•You learn both ways, as a reviewer or if
your work is being reviewed
•PSP style experiment.
WHY : +ve impacts – Systematic Personal
Growth

13. WHAT: Types of Peer Code Review
Formal
Inspection
Process
Over The
Shoulder
Reviews
Email Pass
Around
Interviews
Tool assisted
reviews
Pair
Programming

14. •WHEN: Complete dev coding AND unit testing
•Setup a review session with a team peer of your
choice. Let your lead know.
•Should not be more than 30 minutes.
•Be friendly
•Closely look at code, boundary conditions.
•Ask questions
•Fix small issues
•Follow-up on big ones
•Identify doubts for main reviewer
•Run all unit tests again and ensure that they PASS
•Use a review tool (later)
HOW : Over the shoulder

15. •makes code reviews easy
and efficient for developer
teams
•Receiving feedback on their work
without reviewers altering their work.
•Keeping track of all the feedback and
the disposition of each comment.
•Learning from each other by seeing
comments from others – and
commenting on the work of other
team members
•Interacting in real-time, if they
happen to be reviewing the work at
the same time
•http://smartbear.com/products/
software-development/code-
review
•30 day free trial
HOW : Code Collaborator

16. Presented By: Charuta Joshi
Ref: “Best Secrets of Code Review” by Jason Cohen
http://www.amazon.com/gp/product/1599160676