COLLABORATIVE CODE CONSTRUCTION: CODE REVIEWS AND PAIR PROGRAMMING

download COLLABORATIVE CODE CONSTRUCTION: CODE REVIEWS AND PAIR PROGRAMMING

of 31

  • date post

    11-Feb-2016
  • Category

    Documents

  • view

    40
  • download

    0

Embed Size (px)

description

COLLABORATIVE CODE CONSTRUCTION: CODE REVIEWS AND PAIR PROGRAMMING. CSCE 315 – Programming Studio Spring 2010. Collaborative Construction. Working on code development in close cooperation with others Idea Developers don’t notice their own errors very easily - PowerPoint PPT Presentation

Transcript of COLLABORATIVE CODE CONSTRUCTION: CODE REVIEWS AND PAIR PROGRAMMING

  • COLLABORATIVE CODE CONSTRUCTION:CODE REVIEWS AND PAIR PROGRAMMINGCSCE 315 Programming StudioSpring 2010

  • Collaborative ConstructionWorking on code development in close cooperation with othersIdeaDevelopers dont notice their own errors very easilyOthers wont have the same blind spotsThus, errors caught more easily by other peopleTakes place during construction process

  • Benefits to Collaborative ConstructionCan be much more effective at finding errors than testing alone35% errors found through testing through low-volume Beta level55-60% errors found by design/code inspectionFinds errors earlier in processReduces time and cost of fixing themProvides mentoring opportunityJunior programmers learn from more senior programmers

  • More BenefitsCreates collaborative ownershipNo single owner of codePeople can leave team more easily, since others have seen codeWider pool of people to draw from when fixing later errors in code

  • Some Types of Collaborative ConstructionFormal inspectionsWalkthroughsCode readingPair programming

  • Code ReviewsMethod shown to be extremely effective in finding errorsratio of time spent in review vs. later testing and error correction ranges from 1:20 to 1:100Reduced defect correction from 40% of budget to 20%Maintenance costs of inspected code is 10% of non-inspected codeChanges done with review: 95% correct vs. 20% withoutReviews cut errors by anywhere from 20% to 80%Several others (examples from Code Complete)

  • Reviews vs. TestingFinds different types of problems than testingUnclear error messagesBad commentingHard-coded variable namesRepeated code patternsOnly high-volume beta testing (and prototyping) find more errors than formal inspectionsInspections typically take 10-15% of budget, but usually reduce overall project cost

  • Formal InspectionCharacteristicsFocus on detection, not correctionReviewers prepare ahead of time and arrive with a list of what theyve discoveredDont meet unless everyone is preparedDistinct roles assigned to participantsHold to these roles during reviewData is collected and fed into future reviewsChecklists focus reviewers attention on common past problems

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people max

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people maxKeeps review movingNot too fast or slowTechnically competentHandles all meeting detailsdistributing design/codedistributing checklistSetting up roomReport and followup

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people maxPlays minor roleDesign/Code should speak for itselfShould explain parts that arent clearBut this alone can be a problemExplain why things that seem to be errors arentMight present overview

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people maxInterest in code but not authorFind errors during preparationFind more errors during meeting

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people maxRecords errors found and action assigned or plannedShould not be moderator or author

  • Roles during InspectionModeratorAuthorReviewer(s)ScribeManagement

    3 people min~6 people max Usually should not be involvedChanges from technical to political meetingMight need to see results of meeting

  • Stages of Inspection PlanningAuthor gives code/design to moderatorModerator then: chooses reviewersensures code is appropriate for reviewe.g. line numbers printeddistributes code and checklistsets meeting time

  • Stages of Inspection OverviewIf reviewers arent familiar with code at all, can have overviewAuthor gives a brief description of technical requirements for codeSeparate from review meetingCan have negative consequencesGroupthinkMinimize points that should be more important

  • Stages of Inspection PreparationReviewers work alone to scrutinize for errorsChecklist can guide examinationDepending on code, review rate varies125 to 500 lines per hourReviewers can have varied rolesbe assigned perspectivee.g. evaluate from users view, or from designers viewevaluate different scenariose.g. describe what code does, or whether requirement is metread code/design in certain order/waye.g. top-down, or bottom-up

  • Stages of Inspection Inspection MeetingA reviewer chosen to paraphrase design or read codeExplain all logic choices in programModerator keeps things moving/focusedScribe records errors when foundRecord type and severityDont discuss solutions!Only focus is on identifying problemsSometimes dont even discuss if it actually is an error if it seems like one, it is oneNo more than 1 per day, about a 2 hour limit

  • Stages of Inspection Third Hour meetingDepending on interest/stake of reviewers, possibly hold a separate followup meetingImmediately after inspection meetingFocus here is to discuss possible solutions

  • Stages of Inspection Inspection ReportModerator produces report shortly after meetingList of defects, types, and severityUse this report to update checklist to be used in future inspectionsList main types of errors commonly foundNo more than 1 page total lengthCollect data on time spent and number of errorsHelps evaluate how well things work, justify effort

  • Stages of Inspection ReworkModerator assigns defects to someone to repairUsually the author

  • Stages of Inspection Follow-UpModerator verifies that work assigned was carried out.Depending on number and severity of errors, could take different forms:Just check with author that they were fixedHave reviewers check over the fixesStart cycle over again

  • Adjusting Inspections Over TimeOrganizations will have characteristics of code unique to themDensity of code determines how fast reviewers and inspection meeting can go (application tends to be faster than system code/design)Checklists highlight common problemsMeasure effect of any changesEvaluate whether they actually improved process

  • Inspections and EgosPoint is to improve codeNot debate alternative implementationsNot discuss who is wrong/rightModerator needs to control discussionAuthor needs to be able to take criticism of codeMay have things mentioned that arent really errorsDont debate and defend work during reviewReviewers need to realize the code is not theirsUp to author (or someone else) to determine fix

  • WalkthroughsAlternative to formal code inspectionVague term, many interpretationsLess formal than inspections, thoughUsually hosted and moderated by authorChance for senior and junior programmers to mixLike inspection:Preparation requiredFocus on technical issuesGoal is detection, not correctionNo management

  • Walkthrough EvaluationIn best cases, can match formal code inspections in qualityIn worst cases, can lower productivity, eating more time than savedCan work well for large groupsCan work well when bringing in outsiders

  • Code ReadingAlternative to inspections and walkthroughsAuthor gives out code to two or more reviewersThey read independentlyMeeting held for everyoneReviewers present what theyve found, but dont do a code walkthrough

  • Code Reading EvaluationMost errors tend to be found in individual reviewReduces effort and overhead of managing group dynamics at inspection meetingMaximizes productive effort per person time not wasted in meetings where others are speakingWorks well for geographically distributed reviewers

  • Pair ProgrammingBasic idea: One person codes with another looking over the shoulder.Person at keyboard writes codeSecond person is active participantWatch for errorsThink strategically about codeWhats next?Is code meeting overall goal/design?How to test this code

  • Successful Pair ProgrammingStandardize coding styleDont force pairs for easy tasksRotate pairs and work assignments frequentlyUse good matchesAvoid personality conflictsAvoid major differences in speed/experienceSet up good work environmentAt least one pair member should be experienced

  • Evaluating Pair ProgrammingSeems to achieve quality level similar to formal inspectionTends to decrease development timeCode written faster, fewer errorsTends to be higher quality codeHolds up better during crunch time fewer shortcuts taken that come back to hauntAll the traditional collaborative benefits