Code Review Patterns

This is a PatternLanguage (under development) on CodeReviewing. Applying this pattern language should generate a code reviewing system within a software development organization. Note that InformalCodeReview is outside the scope of this language.

Please feel free to add to and change these patterns - this should really be a collaborative effort!

• Read PeerReviewsInSoftware
• DoInspections
• FormalStandards (are these the same as CodingConventions?)
• FormalReviewProcess
• ReviewProblemAreasFirst
• ArchitectReviewsEverything
• AtLeastTwoReviewers
• CodeReviewTeam?
• InvolveNewbies
• InvolveExperts
• DefectSeeding
• PeerReview
• HighlightChanges
• CodeWalkthrough
• AllowRedesign?
• MakeReviewsFun
• MakeReviewsConstructiveNotCaustic
• ReviewBeforeCheckin
• ReviewsBeforeBigChanges
• CodeReviewDay

---

This is a lot of fun. A few comments:

1) I think the distinction between Forces and Context should be made explicit. 2) We need to ensure that the Forces are forces. 3) Having a Patterns Connections section, will help to identify the connections among the patterns in the pattern language.

-- Mike Beedle MichaelBeedle

---

Okay, good points! Really, this is the first time I've seen several people co-develop a pattern language on Wiki. One additional point:

• Be cognizant of the order of the patterns in the language, don't just add one to the end.

---

Point taken about the order, InvolveExperts should be near to InvolveNewbies. As for explicitly stating it, the rationale is that it is useful to involve experts from other projects and domains. Often the people on the project cannot look at it with new eyes, and although Newbies help, getting another expert to attend the review definitely identifies the interesting areas that have been hidden.

-- PeteMcBreen

I added your rationale into the pattern, and moved it back into the language -- DavidHooker

---

CategoryCoding CategoryPattern