Why Change Lists Should Be Small and How to Keep Them Small

In "Continuous Delivery 2.0" four core principles—do less, decompose continuously, get feedback, and improve continuously—are highlighted, and their application to code submission and code review is described as the principle of atomicity: each change list (CL) should contain a single, indivisible task, feature, fix, or refactor.

Why a CL must be small

Faster reviews: Reviewers can more easily find a 5‑minute slot for a small CL than a 30‑minute slot for a large one.

More thorough reviews: Smaller CLs reduce the chance that important comments are missed.

Lower bug risk: With fewer changes, both author and reviewer can better assess impact and spot bugs.

Less wasted work: If a large CL is rejected, the author loses more effort; a small CL limits wasted work.

Easier integration: Large CLs cause more merge conflicts; small CLs merge cleanly.

Better design decisions: Improving a small CL’s design is simpler than tackling a massive change set.

Continuous flow: After submitting a small CL, developers can start the next atomic task while waiting for feedback.

Simpler rollback: Small CLs involve fewer files, making rollback operations less complex.

Reviewers may outright reject an oversized CL, asking the author to split it into smaller changes.

Recommended CL size

Aim for fewer than 800 lines of change, preferably under 400 lines, and ideally under 100 lines. Studies suggest reviewers can handle about 500 lines per hour, with 400 lines per review being optimal.

How to shrink a CL correctly

Make each CL address a single, tiny change that solves one problem.

Keep the CL as a part of a larger feature rather than the whole feature; find a team‑agreed size.

Include related test code, or add a TestPlan in the description if automation is not possible.

Provide all context needed for the reviewer within the CL description and related code.

Ensure the CL does not break the build or production after merging.

Avoid making the CL so small that the code becomes hard to understand; include necessary usage examples for new APIs.

There is no strict industry rule for what constitutes “too large,” but roughly 100 lines is reasonable, while 1,000 lines is generally too big. The number of affected files also matters.

When large CLs are acceptable

If an entire file is deleted, the change can be treated as a single line.

If a trusted automated refactoring tool generates a large CL, reviewers may accept it, provided normal merge and testing requirements are met.

Techniques for splitting CLs

Split by files: Group changes that require different reviewers into independent CLs.

Separate refactoring from feature work: Keep refactorings in their own CLs, separate from bug fixes or new features.

If a CL must remain large, consider adding a preceding refactor‑only CL to pave the way, and discuss alternatives with the team.

Other considerations

Ensure each CL does not cause the build to fail; dependent CLs should keep the system functional after each submission.

Every CL should include appropriate test code; new behavior requires new tests, and pure refactor CLs should have existing tests to verify unchanged behavior.

When adding or modifying tests, place them in a dedicated CL if possible, and verify coverage of important logic.