A Boring Code Review is a Good Code Review

A ubiquitous part of the software development lifecycle (SDLC), code review is the ceremony of having peers read, evaluate, and provide feedback on changes to source code prior to integrating the changes in to the application.

In my experience, teams that have effective software development processes and practices have boring code reviews. Boring code reviews are achieved through a combination of automated tooling and having robust peer-review throughout the entire SDLC.

Automated Tooling

Effective teams leverage automated tooling to automate away trivial tasks like formatting and simple code style preferences. Automated code review tasks also help to eliminate personal biases and preferences by standardizing many common aspects of writing code. Adding a linter, an automatic source code formatter, and automated static analysis tool to catch potential bugs and code smells streamlines the feedback and discussions during code reviews.

The Hierarchy of Peer Review for Software Development

Inspired by Maslow's Hierarchy of Needs, the Hierarchy of Peer Review in software development outlines the key areas and relative importance of peer review throughout the SDLC.

1. Data Schema and Access Patterns How is data shaped? How is data generated? How is data stored? How is the data used?
2. Infrastructure How does data flow through a system? What kinds of databases and devices does the system need to run on? How do system components communicate? How does the application scale to increased demand?
3. Algorithms What calculations and logic need to be implemented? What business logic and functionality needs to be built in to the application?
4. Code Architecture What programming language and runtime will be used to implement the software? How will the application code be structured? What design patterns and paradigms will be used?
5. Implementation Does the code that was written actually do what was discussed in previous steps? Is it well tested? Is it easy to read? Is it extensible for future use cases?

By the time a pull request is submitted for code review, effective teams have already thoroughly peer reviewed everything except the implementation. While there may be minor feedback about code style or teaching people about helpful ways to write code, the rest of the content of a code review should not have anything surprising. In other words, code review on highly effective teams are boring.

Leveraging automated tooling and building peer-review in to the entire SDLC are powerful tools for streamlining code reviews. What kinds of processes and tools have helped your teams make the code review process more effective?