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