Before diving into a new feature, I always tell my team to scout the parts of the codebase that will need to change. As we explore, refactor for clarity.
These cleanup changes get their own pull request1 (PR) before we touch the new feature. This PR shouldn’t change functionality, just tidy up the existing code.
This gives us a few big wins:
- Better estimates: We can estimate the feature’s timeline more accurately now that we have a much better sense of what’s about to change.
- Smoother reviews: Campground PRs are quicker to review, since no functionality has changed. Importantly, you don’t clutter your feature PR with refactors or distracting changes — prompting the ire of code reviewers.
- Codebase quality: You gradually increase the code quality of your codebase — especially the parts that won’t get touched by your feature PR but could use the love.
This is not a new concept , you’ve probably seen versions of it before:
- Boy Scout Rule: Leave your codebase cleaner than you found it.
- Broken Windows: Fix small issues before they proliferate through your code base become big.
I haven’t found a popular name for this specific concept, so I’ve started calling them “Campground PRs”.
Don’t just leave the code better after your feature, do it before hand.
Got a better name? Let me know!
-
Or merge request (MR), for the Gitlab folks. ↩︎