Reviews Before Big Changes

Schedule Reviews Before Big Changes

Sometimes a bug or group of related bugs will result in a change that affects large sections of the codebase, or significant changes to one component.

Therefore:

Before the programmer commits the changes to the team source repository, assign the bug report(s) to a reviewer, typically a team lead, senior programmer, or module owner. The reviewer can examine the proposed fix for compatibility, suitability, and overall conformance with direction of development. Reviewers should be timely in their responses, and reassign the reviewed bug back to the programmer with approval or suggestions for changes. Once reviewed, the programmer can go ahead and integrate the fix. Related to AtLeastTwoReviewers.

Caution : reviewing only before "big" changes is an antipattern. If you're going to review at all, ReviewBeforeSmallChanges?. Especially changes that are "only one line", and changes that "can't possibly go wrong" - experience proves these are the ones that will most often go wrong.

Perhaps it would be more to the point to say that before big changes, there should be extra careful, additional reviews before committing. If you are doing ContinuousIntegration and RefactoringMercilessly?, there should very few times there are "big" changes. When you do see them, it's usually in the context of some kind of delayed integration, such as a version control branch merge where the team couldn't practice UseOneCodeLine, or an upgrade to a new and backwards-incompatible version of some third-party software.

See: CoordinateEfforts

DefectTrackingPatterns