Stage 4 · Lesson 1 of 8
Keeping pull requests small
A asks your team to review a change and it into the main code. Some platforms call it a merge request. Each one should do one thing and be small enough for a reviewer to understand properly in one sitting, often a few hundred lines at most.
A small pull request gets reviewed faster and more carefully, is easier to test, and is easy to undo (revert) if something goes wrong. Split big work into steps that each leave the code working. For example: first a that tidies existing code, then the new function, then the code that connects it.
Keep formatting changes separate from logic changes. Everything else in this stage builds on this.
Common trapsitting on a large for two weeks to present a finished feature, then waiting days for a review nobody wants to start.
A question to check yourself, an AI practice session and 1 cheat sheet entry come when you add the roadmap to your account. Add it
Resources for this stage
Start with· follow one of these
- GuideFreeGoogle Engineering Practices
Google · Intermediate
Google's guides for change authors and reviewers: small changes, good descriptions and handling comments
- BookPaidThe Missing README: A Guide for the New Software Engineer
Chris Riccomini and Dmitriy Ryaboy (No Starch Press) · Beginner · $29.99 print, $23.99 ebook
The testing, code review, delivery and on-call chapters written for a new engineer