Bigger tasks require a lot of code changes, sometimes resulting in huge pull requests which are nearly impossible to review properly.
How can we mitigate that? The first thing which comes to mind is to not let it happen in the first place. How? By diving the task into smaller tasks and implement them step by step. Although preferable, this approach is not always possible.
A prime example for that is a major upgrade of a framework or a library which used all over the place. In case that upgrade happens to introduce a lot of breaking changes, it renders the aforementioned approach useless.
A solution for such a case is to structure your commits in a way that makes it easier to review. GitHub, for example, provides a feature which allows the reviewer to review the pull request commit by commit.
At first it sounds cumbersome, because in addition to the implementing the actual task you also have to keep in mind the way in which you commit your changes. Instead of committing you code at random, or event worse - not committing at all until your finished, you have to make your commits thoughtfully.
But this is actually an advantage if you look at it from the right angle. While this approach is definitely more demanding it has the advantage of forcing you to create a high level plan, to approach you task thoughtfully. This forces you to think of your implementation as a sequence of steps which you need to take to the solution. This prevents you to just start hacking away and finding yourself afterwards with a bunch of unrelated changed files, having a hard time coming up with a commit message.
You can even go step a further. You will probably agree that formatting changes can obfuscate the real changes that were made in order to accomplish the task at hand. In order to mitigate that we can make ourselves commit changes in formatting in separate commit. If we mark these commits as "formatting changes only" they can safely be ignored by the reviewer, and we will further ease the reviewing process.
Keep in mind that someone will eventually have to review the code you're writing and try to ease the work of the reviewer. The reviewer is you friend :)
Top comments (0)