•None of the materialpresented in thispresentation is original.•It bears strong resemblanceto the ideas presented in“Best Secrets of CodeReview” by Jason Cohenhttp://www.amazon.com/gp/product/1599160676•The resemblance isintentional to get practicaladvice about benefits & usesof peer code reviews.
•Study conducted for 3 monthsfor 10000 line project with 10developers.Result:•Code review would have savedHALF the cost and uncovered 162additional bugs•$1 billion bug•Challenger fiascoWHY
WHY: BENEFITSImproved CodeQualityFewer defects incodeImprovedKnowledgetransferEducation of juniorprogrammersDirect
•Peer Code reviews are GREAT..FOR OTHERS•WHY?But we don’t really like them..
•Because we are NOTmachines.•We take our codepersonally.•Our work represents ourcreativity and we are notalways open to critiqueBut 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 tolearn 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 performancereviewWHY : -ve Social Impacts
•Begins even before first round•Want to take pride in our work•Create a reputation•AccountabilityWHY : +ve impacts – The “Ego Effect”Nobody wants to be thisNPE guy !!
•Peer Reviewer Question : Why is the constant on left side whilecomparing?•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 mistakescommon programming with minimumof impact•If we maintain a list and avoid those, weare on our way.•You learn both ways, as a reviewer or ifyour work is being reviewed•PSP style experiment.WHY : +ve impacts – Systematic PersonalGrowth
WHAT: Types of Peer Code ReviewFormalInspectionProcessOver TheShoulderReviewsEmail PassAroundInterviewsTool assistedreviewsPairProgramming
•WHEN: Complete dev coding AND unit testing•Setup a review session with a team peer of yourchoice. 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 easyand efficient for developerteams•Receiving feedback on their workwithout reviewers altering their work.•Keeping track of all the feedback andthe disposition of each comment.•Learning from each other by seeingcomments from others – andcommenting on the work of otherteam members•Interacting in real-time, if theyhappen to be reviewing the work atthe same time•http://smartbear.com/products/software-development/code-review•30 day free trialHOW : Code Collaborator
Presented By: Charuta JoshiRef: “Best Secrets of Code Review” by Jason Cohenhttp://www.amazon.com/gp/product/1599160676