Focus your code reviews on identifying hard-to-change-later items

I recently read this post on the The Code Review Pyramid by Gunnar Morling which provides a nice visual representation of the different areas you should focus on when performing a peer code review and which you should delegate to automation.

Image credit: Gunnar Morling

The left-hand-side of the diagram includes an axis labelled “effort for later changes” which is subtle but I think is an important point to draw closer attention to. Engineers’ time is very expensive so time spent now identifying issues which will require significant effort to change in the future is time well spent.

When building serverless apps on AWS, I find the following items fall into the harder-to-change-later semantics categories:

• GraphQL schema and REST API contract design — once clients (internal or external) start consuming these, they become very difficult to change
• DynamoDB data models — what tables, GSIs, composite fields etc, to create (see Handling future changes to your DynamoDB access patterns)
• Cognito user pool attributes— very inflexible to change these without blowing away user pool
• CloudFormation stack design — what resources live in what stack
• Additions of any third-party services into the architecture (see Integrating a third party service into your AWS application)
• Any infrastructure or configuration change which negatively affects the ability for a fully automated deployment of the application to an environment (either to an individual developer’s environment or a CI/CD deployment to staging/prod).

I’m not saying that uncovering items such as these should be the sole focus of code reviews and you should also be on the lookout for other issues such as security or performance concerns (which may be quickly resolvable with a one-line change). But approaching a peer code review with the primary motivation of minimising future rework for you and your team is arguably the highest form of value you can provide in terms of the TCO of your product.