Collaborative Code Construction: Code Reviews and Pair ProgrammingCommunication is KingTypes of CollaborationCollaborative ConstructionBenefits to Collaborative ConstructionMore BenefitsSome Types of Collaborative ConstructionCode ReviewsReviews vs. TestingFormal Inspection CharacteristicsRoles during InspectionSlide 12Slide 13Slide 14Slide 15Slide 16Stages of Inspection – PlanningStages of Inspection – OverviewStages of Inspection – PreparationStages of Inspection – Inspection MeetingStages of Inspection – “Third Hour” meetingStages of Inspection – Inspection ReportStages of Inspection – ReworkStages of Inspection – Follow-UpAdjusting Inspections Over TimeInspections and EgosWalkthroughsWalkthrough EvaluationCode ReadingCode Reading EvaluationPair ProgrammingSuccessful Pair ProgrammingEvaluating Pair ProgrammingCollaborative Code Construction:Code Reviews and Pair ProgrammingCPSC 315 – Programming StudioSpring 2009Communication is King•The mythical man month argument–Communication takes time/effort–The larger the team the more time is spent communicating/coordinating•Expect miscommunication–There are multiple interpretations to almost any communicative act–Teams need to be resilient•Plan on fixing problems due to miscommunication at integration time•Avoid the blame game and work together to fix the problem•Don’t jump immediately into the “I will do it all” responseTypes of Collaboration•Coordinating Effort–Prioritizing and sequencing–Assigning tasks•Collaboration can occur:–Asynchronously•Working on same code serially–Synchronously•Working on different code simultaneously•Working on same code simultaneouslyCollaborative Construction•Working on code development in close cooperation with others•Idea–Developers don’t notice their own errors very easily–Others won’t have the same blind spots–Thus, errors caught more easily by other people•Takes place during construction processBenefits to Collaborative Construction•Can be much more effective at finding errors than testing alone–35% errors found through testing through low-volume Beta level–55-60% errors found by design/code inspection•Finds errors earlier in process–Reduces time and cost of fixing them•Provides mentoring opportunity–Junior programmers learn from more senior programmersMore Benefits•Creates collaborative ownership–No single “owner” of code–People can leave team more easily, since others have seen code–Wider pool of people to draw from when fixing later errors in codeSome Types of Collaborative Construction•Formal inspections•Walkthroughs•Code reading•Pair programmingCode Reviews•Method shown to be extremely effective in finding errors–ratio of time spent in review vs. later testing and error correction ranges from 1:20 to 1:100–Reduced defect correction from 40% of budget to 20%–Maintenance costs of inspected code is 10% of non-inspected code–Changes done with review: 95% correct vs. 20% without–Reviews cut errors by anywhere from 20% to 80%–Several others (examples from Code Complete)Reviews vs. Testing•Finds different types of problems than testing–Unclear error messages–Bad commenting–Hard-coded variable names–Repeated code patterns•Only high-volume beta testing (and prototyping) find more errors than formal inspections•Inspections typically take 10-15% of budget, but usually reduce overall project costFormal InspectionCharacteristics•Focus on detection, not correction•Reviewers prepare ahead of time and arrive with a list of what they’ve discovered–Don’t meet unless everyone is prepared•Distinct roles assigned to participants–Hold to these roles during review•Data is collected and fed into future reviews–Checklists focus reviewers’ attention on common past problemsRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people maxRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people max•Keeps review moving–Not too fast or slow•Technically competent•Handles all meeting details–distributing design/code–distributing checklist–Setting up room–Report and followupRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people max•Plays minor role–Design/Code should speak for itself•Should explain parts that aren’t clear–But this alone can be a problem–Explain why things that seem to be errors aren’t•Might present overviewRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people max•Interest in code but not author•Find errors during preparation•Find more errors during meetingRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people max•Records errors found and action assigned or planned•Should not be moderator or authorRoles during Inspection•Moderator•Author•Reviewer(s)•Scribe•Management•3 people min•~6 people max• Usually should not be involved–Changes from technical to political meeting•Might need to see results of meetingStages of Inspection – Planning•Author gives code/design to moderator•Moderator then:– chooses reviewers–ensures code is appropriate for review•e.g. line numbers printed–distributes code and checklist–sets meeting timeStages of Inspection – Overview•If reviewers aren’t familiar with code at all, can have overview•Author gives a brief description of technical requirements for code•Separate from review meeting•Can have negative consequences–Groupthink–Minimize points that should be more importantStages of Inspection –Preparation•Reviewers work alone to scrutinize for errors–Checklist can guide examination•Depending on code, review rate varies–125 to 500 lines per hour•Reviewers can have varied “roles”–be assigned “perspective”•e.g. evaluate from user’s view, or from designer’s view–evaluate different scenarios•e.g. describe what code does, or whether requirement is met–read code/design in certain order/way•e.g. top-down, or bottom-upStages of Inspection – Inspection Meeting•A reviewer chosen to paraphrase design or read code–Explain all logic choices in program•Moderator keeps things moving/focused•Scribe records errors when found–Record type and