Last night I was watching Sandi Metz’s podcast on Bikeshed and one question in the QnA striked me.

Q. I am working on a legacy codebase. The code is a mess and I cannot stand by it.
   I want to refactor it but we are a small team and there are so many deadlines.
   Any tips for how to go about cleaning up the mess without affecting the ongoing work?

Sandi gave 2 tips for this which I am listing here with some of my analogous views mixed in:

1. Leave it:

If you know the code is never ever going to change (and since it is in use, it obviously works!), it will be wise leave it as is. Going ahead and refactoring it will lead to unnecessary overhead.

2. Chisel Refactoring:

When you change/work on something, take the chance to refactor the code while you are at it. Only the code you see around there. And make sure it works.

Most probably a bad legacy codebase will have zero tests or few badly written failing tests. So to make sure it works you can either test it manually or add tests only for that part (including your change). The later one is better since this way you will gradually build up test suite for the code that is likely to change.

You don’t need to decide upfront what code won’t change in the first tip. You will automatically start refactoring only the code that matters.

For a full refactoring (aka. rewrite) you will need permission from someone, but for this you won’t need any permission, just shove it into your PRs and you’re done!

Moreover, full rewrites are likely to lead to failed attempts often. But that is highly unlikely for chisel refactoring only because they are so small.