Software Development

The Code Review Problem for Migration

The larger the code change, the harder it is to review. So what happens when we’re doing a code migration? Technically there’s a huge set of changes to make to get the code from its original state into a new form. How do we manage that?

What the What?

A couple of definitions before we get into the detail here.

Firstly, let’s review the idea of reviewing. Some teams prefer not to do code reviews, considering the work of a mob or a pair to be better than an asynchronous peer review. That’s fine, but I would suggest that even a mob or pair should have some mechanism to check their changes before final commit. I don’t just mean test automation, which they should also have, I mean reading the diffs to ensure that there’s no surprise.

Peer review is, in some ways, less powerful than reviewing something yourself. My preference is to review something myself, knowing that someone else will be looking at it. The fact that it will be reviewed by someone else makes me see my own code differently at the diff-reviewing stage. I review my own diffs even on solo projects.

The second definition is a code migration. Let’s assume that sometimes there’s a project that was made in a different version of the technology we use, and we’re about to update it to the latest version. Let’s assume that there’s no half measures here; we’re lifting and shifting in some way shape or form, and the old build can’t be gently evolved to the new world.

Avoiding a Huge Migration Review

Depending on the type of migration, we have a few options for how to make our changes reviewable. The key consideration is whether the review could be understood by a person easily. This means either:

  • A small amount of change, which can go quite deep
  • Only trivial changes, which are easy to understand without much reading
  • Additional of boilerplate, which may be extensive, but can be treated as a boilerplate block – thus avoiding the bootstrap review problem

Here some code migration ideas, optimised for reviewability:

  • Ignore buildability, and make a series of thin changes to the code as a whole until it complies with the new standard – each thin change targets one improvement/fix for the new world
  • Build the new project from zero and import the old code a piece at a time, fixing as you go
  • Do a hybrid migration where the old code is imported as a library to the new platform somehow, and is then rolled across a module at a time with minor changes

Incremental Wins

For reducing risk, increasing teamwork, and making it easy to understand, working in small batches is consistently the best aim.

We can forgive ourselves a batch that has lots of line changes that are, essentially, the same.

Fundamentally, though, the challenge of any big code migration is working out how to slice it into increments so that it can be managed easily and understood at every step of the way.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: The Code Review Problem for Migration

Opinions expressed by Java Code Geeks contributors are their own.

Ashley Frieze

Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button