Submitting code to a codebase is a regular occurrence as a software engineer. However, how code is written, reviewed, and submitted varies from company to company. Throughout my experience of working at small startups and large tech companies, I’ve seen a variety of processes around reviewing, submitting and shipping code.
Today we’ll discuss three of the most valuable lessons I’ve learned with code reviews:
1. Review Your Code
You are your first reviewer. Before requesting a review from anyone else, make sure that you review your changes. If you would approve your code changes, then and only then should you request a review from your teammate(s). Doing this ensures that the review you receive is as effective and as efficient as possible.
This allows your reviewer to focus on the “meat” of your changes since you’ve already covered the basics like missing dependencies, failing tests, misspelt variables, etc.
2. Update Your Code Change’s Description
The description of your code change should summarize what your changes are responsible for accomplishing. Your description is the initial context that your reviewer will turn to to understand what it is that they’re reviewing. I’ve found that the most helpful descriptions contain two elements:
A single sentence stating what the change is responsible for (i.e. “Removes all references to the fully launch frontend flag, `enable_checkboxes`”).
Any additional information that might be helpful for the reviewer (i.e. the “why” for the change is being made, links to design documents, screenshots or recordings of the changes running locally).
Maintaining a consistent format for descriptions keeps changes organized which is useful when trying to understand the history of a repository.
3. Ensure Test Coverage
All changes should include tests. Any change that does not include tests is incomplete. After all, tests are an integral part of the development process. Unit tests ensure isolated “units” of software work as expected. Similarly, integration tests ensure that dependent units of software function properly when glued together.
Tests can be expensive to develop and maintain but pay dividends over time by giving you consistent assurance that your systems are behaving as intended. Remember, all code is eventually tested either by you or the user — prefer the former.
Drop a like ❤️ and comment below if you made it to the end of the article.