Blog post series
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
A bit of history
On 26 November 2011 I had the honour of being an attendee at the second ever Legacy Coderetreat, which was supposed to be the first one in the world. But my friend Johan Martinsson from Grenoble beat Erik and me to it. Anyway I was part of the second ever Legacy Coderetreat in the world, facilitated by JB Rainsberger. JB had come with this concept of using the Coderetreat format, but for legacy code.
At the beginning of the day he presented us the problem, like in any other coderetreat. The problem was an ugly trivia game and you can find the sources here. At that time the code base was translated, from Java, only in a couple of other languages. Now you can find almost any language you want, thanks to the worldwide community of passionate developers who translated the code base.
JB facilitated the event like you could find in here, with a lot of details. But in short we would start with a free session, then follow with Golden Masters, continue with Subclass to Test, Replace Inheritance with Delegation and then Pure Functions. After each iteration we deleted the code like in any other coderetreat and swapped the pairs.
I liked a lot the fact that JB started this idea, because I am a big lover of working with legacy code. And this Legacy Coderetreat is such a good way to practice. But I had some other ideas on how to make it different.
My idea of a Legacy Coderetreat
Something felt a bit forced in JB’s format, so I thought it over and changed the format. My idea of a format was to expose the audience with session that would go from outside of the “black box”, with integration tests, toward “white box” and would end up with having unit tests. Each session would show how to dive into an unknown code base, depending on the level of abstraction you are. As for any other coderetreat I had prepared more sessions than needed, and chose them on the spot, depending on the audience’s preference.
So we could start with “black box” testing sessions and then, once we have our safety net, we would start with “white box” sessions. Of course, during each of the sessions, we would write a lot of automated tests and we would do a lot of refactoring.
Types of automated tests to write
But all these tests are written on existing code, so all of them are characterization tests. This means that we use all these types of tests for the purpose to understand what the existing code does.
For each one of the sessions below I will write a blog post and create a code cast. The sessions will appear in the list as I will create the blog posts and the code casts. So here they are:
I recommend you to attend a Legacy Coderetreat, and then you will see legacy code with different eyes. But remember: coderetreat is for practice, it is not a workshop. If you ever want to organize a Legacy Coderetreat I will be happy to help. If you want to learn these and other techniques in a formal way, please check my workshop Working FAST and Safe with Existing Code.
Image credit: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basic_computing_language_for_Atari_8-bit_computers.jpg