Code Review

Code quality is product quality.

If there are defects in the software, a user will find it. That’s why we promote code quality reviews with every single new feature or bugfix that is developed. It’s not an afterthought, either: new code simply doesn’t get released until multiple sets of eyes have seen it. A single developer can miss defects, but two developers will miss a lot less. Along with our focus on quick iterations and small changes, code review is another tool we use to ensure a high-quality product.

Code that is used, must be maintained.

Software maintenance can be hard, if the code looks like spaghetti. With code review set up early in the development process, the right design patterns can be in place early and enforced along the way, to make sure your codebase is flexible and that maintenance is easy and straightforward for any developer on the team. An ounce of code review saves a ton of headache for the next developer.

Standards matter.

Developers shouldn’t work in silos. If code is authored with others in mind from the very beginning, it will automatically be more friendly and self-describing. Peer review is a way of ensuring that developers are all using understandable (and proven) design patterns that have stood the test of time.

Modern, informal, tool-based and asynchronous.

Our asynchronous workflow means developers can be working on multiple features at once, waiting on a code review, so the code review process doesn’t slow them down. And because we use standardized tools from industry leaders, those reviews can be done very quickly. We’re always looking for new patterns and practices to make us better at our craft. Code review is a way of sharing knowledge in an informal way and keeping all developers on the cutting edge.

Code Inspection

If a codebase hasn’t gone through regular review, it may be necessary to to do a formal Code Inspection first. While we prefer an ongoing, asynchronous code review process, there are cases where we are called to perform a more formal, one-time inspection on other teams’ codebases. We follow a standard process:

  1. Planning. What are the expectations of the product owner? What is the expertise of the developers involved? Are all the right “players” behind the effort? Does the effort have institutional support?
  2. Overview. What level of inspection is going to take place? What kind of defects are expected to be uncovered?
  3. Preparation. Where is the code? What dependencies exist? What initial notes and questions do the inspectors have? The team takes time on their own to draft their own recommendations at this point.
  4. Inspection meeting. The whole group gets together to review recommendations from the team and decide next steps.
  5. Reworking. This is an opportunity for the owners of the codebase to perform the work, based on the recommendations.
  6. Follow-up. If desired, the team can reconvene and make judgements on the success of the effort.