Tag Archives: Existing Code

Talk: Easier to change CODE

Talk: Easier to change CODE

This is a talk from I T.A.K.E. Unconference 2016, Bucharest.

It is a hands-on talk, where I refactor some code live with the help of the audience.

Techniques

During this talk you will see techniques that are useful for tackling legacy code issues. You will be able to see how, with the help of the audience, the code can be improved to become easier to change. We want to change existing code in just a few situations: solve bug, add feature, improve the testability of the system. Remember that when you change existing code you understand what is the reason to do this.

Before changing the code is important to have some tests as a safety net. For that I am using Characterization Tests. Only after having these characterization tests, we can start to refactor the code, but with care in order not to introduce defects. Even though we have a safety net, it is not enough and bugs might appear. So to make sure we have more trust in tests the first refactoring steps are made with the purpose to be able to add unit tests.

Adding unit tests gives me better quality feedback, because if I introduce a defect I will know better what I have done wrong. A characterization test is too big, and I might need to dig a while to find the reason.

Changing legacy code needs to be done with care, in small steps and try to always remain with the tests on green. The longer I stay on red, the riskier is that I introduce defects and I lose my refactoring direction.

Easier to change CODE means the total opposite of the Legacy Code is Fear concept. I have my toolbox with legacy code techniques. I know how to use them,  and so I am able to make the code to be easier to change.

Video

 

Talk: Java User Group Łódź – Legacy Code is Fear

Talk: Legacy Code is Fear (Łódź, Poland)

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

This is a talk from last year, before Global Day of Coderetreat Lodz.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

This talk is about how our unknowns make us feel frightened. We need to get passed that and learn techniques, practice them, understand how and when to use them. Only with more knowledge we will be able to tackle legacy code. But how do we acquire knowledge? We need to read, try, experiment, fail, and many more with some learning code base. Then we need do the same with production code. My advice is to never try these legacy code techniques on your legacy code base at work. You will be disappointed in the beginning because they will be difficult to apply. That is why it is important to start small, with an easier to understand code base in order to learn. And only after you can refactor that simpler code base, it is the time to start using the legacy code techniques on the bigger code base from work.

 

Here are the slides for the talk:

Legacy Coderetreat: Episode 13 – Document Possible Bugs with Tests – Code Cast

Document Possible Bugs with Tests – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. Then we wrote some unit tests in the following episode. But some of the behaviours seemed strange, and we thought they might be bugs.

Because we are never sure when working on existing code if some behaviour is a bug or a feature, we want to document all the suspicious cases. In order to do that, I am presentin three methods: use an annotation, prefix the test, use a diffent class.

Bug or feature? Check out the code cast to see all of them in action.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 12 – Unit Testing on Legacy Code – Code Cast

Unit Testing on Legacy Code – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. But that is not enough, we want to continue adding other types of tests to understand the system better.

This is why during this episode you will see how to add unit tests to code extracted from a legacy code class. These tests have a small granularity level than the characterization tests we already have. This is the moment to dive more into details.

See this video to understand how you can document the current state of the system, by unit testing on legacy code.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 11 – Extract Class – Code Cast

Extract Class – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we restructured some parts of the code base. We also extracted pure functions and applied The Rule of Three when restructuring the code.

Because we have extracted some pure functions, now we need to think if those pure functions belong to new classes. So we structure the functions in a way that they belong together from the point of view of their responsibilities. After structuring the functions we extract the class.

Learn from this video how to extract a class in legacy code in such a way that you do not introduce side-effects to the existing behaviour.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 10 – Refactoring the Rule of Three – Code Cast

Refactoring the Rule of Three – code cast

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.

Code Cast

This is a code cast in Java.

When refactoring legacy code we need to make sure the structures we extract have a correct meaning. This is why The Rule of Three is very useful: extract to a new structure only when you find an identical duplication three times. Usually we do not have identical duplication, so in that case we need to make the duplication clear, check that it exists three times and only after that perform the extraction.

This code cast will show you also when it is not a good idea to extract a new variable, even if you see it duplicated many times. This is a mechanical kind of refactoring, but reasoning is very important even when we want to get fast by getting mechanical refactorings into our tool bag.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 9 – Extract Pure Functions – Code Cast

Extract Pure Functions – code cast

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.

Code Cast

This is a code cast in Java.

In the first episode we wrote some characterization tests with the purpose to create a basic safety net. Now we continue to refactor the code, starting from there. We already have some tests running and we want to have methods that do only one thing; we want to apply the Single Responsibility Principle. A really good tool that can help is using pure functions. We extract functions, make them static and then make sure the function does not have any side effects. These functions help me clean the code and help me start structurig the code according to clear responsibilities. At a later time we will extract all these functions that have similar responsibilities to a new class.

Read here more about this concept in my blog post.

 

Legacy Coderetreat: Episode 8 – Use Mocking Framework – Code Cast

Use Mocking Framework – code cast

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.

Code Cast

This is a code cast in Java.

In this code cast you can see how to start using mocking framework on an existing code base. Once we have an interface, we can start using the mocking framework to test external dependencies.

After extracting new and clear methods from the messy code and after extracting classes, we now have a code base with clearer dependencies. However, once we understood how to do dependency inversion, testing the core system becomes a bit more difficult. We need to write tests to show how the core system collaborates with the dependencies we inverted. For testing collaboration with inverted dependencies we use mocking framework.

Read here more about this concept in my blog post.

 

Legacy Coderetreat: Episode 7 – Extract and Override – Code Cast

Extract and Override – code cast

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.

Code Cast

This is a code cast in Java.

Extract and Override is a very useful technique to break static dependencies. Whenever we cannot write tests for a piece of code, it is often because we have static dependencies. In the code cast below you can see how to use extract and override having a random number generator very tightly coupled. Because of that, we cannot have the same output for some clear steps. The solution found in this video is to extract the random to a new method and then override the random generator, just for tests. In this way we have predictability for tests.

Read here more about this concept in my blog post.

 

Legacy Coderetreat: Episode 6 – Dependency Inversion – Code Cast

Dependency Inversion – code cast

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.

Code Cast

This is a code cast in Java.

During this code cast you will see how to use the concept of Dependency Inversion on a legacy code base. Dependency Inversion is one way of transforming a tightly coupled system into a system that has a core and many small external dependencies. These external dependencies can be called also plugins. Read more about this concept in my previous blog post.

 

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.