Grooming your code base
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.
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.
2 thoughts on “Grooming your code base”
Nice article. One question though. How do you ensure that the code is “green”? Manual inspection?
Therefore, we use StyleCop and Code Analysis (FxCop) that we can integrate into the build.
Good point. As far as I know there is no way to use ReSharper on the build server (continuous integration server). So, currently we just using this rule (trust every developer that he does the ckeck, and we do also some code reviews). As a second step we plan to use StyleCop as well, also because there is a very nice integration in ReSharper. And as you already mention, you could use StyleCop on the build server.
Thanks again for your comment and thoughts.