When you’re doing Test Driven Development (TDD), it’s in the process: Red-Green-Refactor. Refactoring doesn’t only mean to improve your new code, it is also important to make your existing code nicer.

If you are a .NET Developer, then you should have the Visual Studio Add-on ReSharper. With this tool you get a marker bar which you see right hand side of your editor. On top of this marker bar you have a little square which shows the worst found item (error or warning). In our company we introduced recently this tool and we also introduced a new rule: "Check-in only green code!"
This rule means that the square has to be green: no errors and no warnings are allowed in the current file.

Reality check

New tools and rules are nice, but we know all the pearl of wisdom "A fool with a tool still a fool". You aren’t immediately a better software developer when you do TDD or using ReSharper. You have to know how to use it.
All of us have in our code base a lot of legacy code, I mean really bad code and a remarkable collection of anti-patterns: god object, Swiss army knife, etc. and the ReSharper shows tons of warnings and errors. Now you can start to fix that code base, but be honest, that will be a project of its own. So, should we just resign or try to improve our code base?

Grooming your code base

When you know Scrum, then you know also the term grooming the product backlog. It is essential to make progress and to do the right things. The same goal we should have with our code base. We want to implement fast new features or change quickly with no risk breaking current behaviour.
The word risk here is critical: Don’t try to improve your code base at once, it’ll be a huge task (or even a project) and maybe you will fix things which will change in the near future. So, the right way is step by step or just following the boy scout rule: "Leave your code better than you found it".
If you doing TDD, then try during the refactor step to groom your code base. If not, then just clean up the code you touch and make it green (ReSharper marker bar). Don’t try to fix a whole class, just improve the needed methods.

Make the field a bit more green

In a classical brownfield project, there will be just bad legacy code. So it is important to plan some bigger refactoring tasks to make the code base better and decrease the technical debt. If the code coverage is very low then those tasks are a good start to increase the number of tests and the code coverage. But be aware of those tests: They could document wrong behaviour as correct.