The immediate benefit for code review is (surprise!) code review is much easier if there is less code to review and its all intended to make a single idea work. The reviewer can more easily understand the complete set of changes. Note that this benefit extends to future engineers who can also more easily look at a series of easily-understandable changes than giant, hairy sets of changes. Further, this ease of change management can pay even more future dividends - consider reverting changes from production - which becomes easier if the changes are smaller and map to singular ideas. Consider launching a new product that integrates with your search service in one giant checkin. Wouldn't it be nice to be able to just roll back the particular commit that landed the search integration rather than the whole product? Even more ideally (perhaps), wouldn't it be nice to roll back the commit that turned on the integration to the search service? In reality, your organization is likely launching multiple updates in a given release, and such flexibility in reverting parts of the release could quickly prove invaluable to maintaining overall forward momentum.
Description
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Invalid | None | T10440 Sample Process | ||
Invalid | None | T10442 What should code review look like to the reviewer? |