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.

Code Review Pyramid

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.

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    🩺
    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>