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

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>