Exploratory Refactoring - Understanding Legacy Code

Remember how Neo can see people and places and events behind the code? Well. Not all of us mortals can see the shape of things at first glance of code. Actually, "He's the One".

Martin Fowler suggests refactoring code when trying to understand it. Also Michael Feathers describes lots of techniques to work with legacy code. This post is about step zero: understanding the legacy code.

Exploratory Refactoring is the act of applying a series of refactorings to legacy code merely to understand what it does. That's it. There is no magic here. After you understood the inner workings of the code in question, you typically throw away all of that refactoring and start to really and seriously work on the code. With end-to-end tests, unittests and the whole shebang. But I'm getting ahead of myself.
I typically start off with simple refactorings, like Extract Method, Decomposing Conditional, Rename Method, Rename Variable, Introduce Explaining Variable. This phase is like when an archeologist hand-cleans stuff during excavation. She might already have ideas of what each part is, was, but that's not the point. In this phase she just wants to make the parts as apparent as possible.
In our case however, you don't have to be very careful - as this is a throw-away refactoring - in extreme cases you could just pseudo refactor the code. However the closer you get to real-life refactoring, the more you can learn from it. You will get to see unexpected inter-dependencies, which  can influence your real refactoring later on.
Once you have done that, you can start to fit the pieces together and you can continue to dig deeper - or go higher in terms of abstraction  - , and use more complex refactorings which help you to unveil the intrinsic structure of the code, like Consolidate Duplicate Conditional Fragments, Remove Control Flag, Split Loop, Reverse Conditional. It could be that after quite a few refactoring, you still don't see structure or intention: Worry not! You will see it soon. Just keep on factoring each small bit of information back to the code.

One last bit of advice:

Don't make the typical mistake of dissing and cussing the author(or the poet we like to call them) of the legacy code. Not because it's simply bad manners, and not because we all have legacy skeletons in our careers  closets, but more importantly, because that way you distance yourself from the poet of that code, making it that much harder to see what he meant to say, when he for example named a variable $last_element. 
(Whilst if you try to indentify with him, you might realize, he really meant $previous_element )
Read full post...

TDR - Test Driven Review

We all did it a couple of times, but it wasn't until recently that I found out how useful and efficient it was. Our fresh hires start working on production code relatively soon after their first day. Nevertheless we want to review their work before check-in.
Getting up to speed
I always start with, "Let me see the tests". It is only partially to emphasise the importance of tests, the real reason is that for me it's easier and quicker to engage in the task he has just solved. And this gives me the chance to profoundly review the code itself and how it looks.
Defining
Sometimes we don't even continue to the code, because it turns out that he misinterpreted the task at hand, and solved something else. But that's okay too, for through the tests I can very easily and clearly explain what the real task is. If we were to do this via the implementation, it would be less unambiguous.
Demonstrating
Finally, I can show him couple of coding tricks, again without being too superficial, yet being quite quick. What I mean is I can quickly refactor his code on the spot, without saying things like "... and you can imagine the rest" - no, at the end of the demonstration we have a still working code(checked by the help of the tests), but with me already having made my points on coding as we know it: expressive and duplication free.
Read full post...