Why, What, How ?
17th
June
201
3Ch
arut
a Jo
shi
•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 Cohenhttp://www.amazon.com/gp/product/1599160676
•The resemblance is intentional to get practical advice about benefits & uses of peer code reviews.
•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
WHY: BENEFITS
Improved
Code Quality
Fewer defects in code
Improved Knowledge
transfer Education of junior programmers
Direct
WHY: BENEFITS
Shorter development/t
est cycles
Reduced impact on technical
support
More customer satisfaction More maintainable code
Indirect
•Peer Code reviews are GREAT..FOR OTHERS•WHY?
But we don’t really like them..
•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..
•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
WHY : But it is NOT ALL bad
•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 !!
•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
•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
WHAT: Types of Peer Code Review
Formal Inspection
Process
Over The Shoulder Reviews
Email Pass Around
Interviews
Tool assisted reviews
Pair Programming
•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
•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
Presented By: Charuta Joshi
Ref: “Best Secrets of Code Review” by Jason Cohenhttp://www.amazon.com/gp/product/1599160676