Over the last while I’ve learned a bit about refactoring. During that time I’ve also been working on implementing TDD. During my time I’ve come to realize something. Personally while these two concepts require a lot of changes in the techniques and skills, the biggest change is in pace of work. I will admit to being one of those people who when given an assignment speeds through it as fast as possible. Spend a little bit of time thinking about the change.. write the code.. verify it works (On My Machine!) and check it in.
Now a completely different mindset and pace is required. When writing a new feature things go a bit more like this…
1. Find existing code related to the new feature.
2. Use Resharper Ctrl + F7 to find existing code that references that code, and more importantly existing unit tests.
3. Look at the unit tests. If there aren’t any write some that validate the existing functionality. I’m still up in the air about writing tests against functionality I know will change. On one hand it helps validate your understanding of the code and what it does. On the other hand it can be unnecessary help. I think its a situational judgement call.
4. Look at the code. Get an idea of how the existing functionality is going to be used. How is the change going to affect it. Sometimes this step is the easiest but other times its the hardest. Of course when its hard and the change has a big effect throughout the system then that is a probable code smell.
5. Start the TDD cycle. Red.. Green.. Refactor. Of course as you do so you may touch existing stuff in which case you should start at step 1 on that stuff.
All in all this new pace is about much more then “Getting Shit Done (GSD-mode)”. It’s a huge change but one that I believe will lead to much more reliable, maintainable code.