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…
Legacy Coderetreat: Part 16 – Refactor Conditionals by Decomposing Conditional
Refactor conditionals by Decompose Conditional
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.
Purpose
We often see code with conditionals that are hard to understand. The purpose of this technique is to make the code look readable by extracting a function with the condition. It will be easier to test the code if the condition is extracted and injected as a dependency.
This technique is useful when having good variable names is not enough to explain the condition. We can have some of the following reasons for wanting to extract a function with the condition:
- The condition is duplicated in several parts of the class
- The condition is duplicated along different classes
- Test the condition in isolation, because of its complex nature
- Test the code without understanding how the conditions work (inject conditions as stubs)
Legacy Coderetreat: Part 15 – Refactor Conditionals by Explaining Variable
Refactor conditionals: Explain Variable
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. 
Purpose
When you try to read a code base that has many conditionals, often the problem is that the condition itself is very hard to understand. This technique improves the conditionals by making them clear and very easy to read.
Talk: Agile Lean Europe 2014 – Legacy Code is Fear
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. You are a programmer. Someone from the company…
Legacy Coderetreat: Part 14 – Document possible Defects with tests
Document possible Defects with Tests
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.
Purpose
When writing unit tests on legacy code, we often discover behaviours of the system that seem wrong. The main rule is: DO NOT change the production code without being absolutely sure that the change does not introduce defects. Instead we need to mark all the tests that characterize a possible defective behaviour. Let’s look at some ways to document possible defects with tests.
Legacy Coderetreat: Part 13 – Unit Testing on Legacy Code
Unit Testing on Legacy Code
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.
Purpose
In the previous episode post we extracted a class. The code we just extracted is tested at this moment only with System Tests. Now it’s the time to start writing unit tests, considering that we already have some system tests in place.
Legacy Coderetreat: Part 12 – Extract class
Extract Class
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.
Purpose
When working with existing code we need to look at the responsibilities of existing classes. If one class is too big, we need to extract new classes from that initial class. A class too big means that it’s not respecting the Single Responsibility Principle.
Legacy Coderetreat: Part 11 – Refactoring Rule of Three
Rule of Three
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.
Purpose
The rule of three says:
Extract duplication only when you see it the third time.
This concept is extremely useful when you want to improve legacy code, refactor in the TDD cycle or just improve existing code that is covered by tests.
The Rule of Three brings higher coherence and more clarity to the system, because the duplicated code starts to be moved into specialized areas. In this way we optimize the code base for changeability.
The Rule of Three prevents from prematurely extracting possible duplication and defers the duplication minimization until we have enough proof.
Legacy Coderetreat: Part 10 – Extract pure functions
Extract Pure Functions
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.
Purpose
We have some class that is very big. We want to divide the existing code into more methods and classes so that we have in the end some code that is easier to understand. If the methods are small, they are easy to change. In the same time the code would respect the Single Responsibility Principle. We optimize our software for changeability. In the following we will see how we can extract pure functions to achieve that.
Legacy Coderetreat: Part 9 – Use Mocking Framework
Use Mocking Framework
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.
Purpose
By using mocking frameworks we are writing short and easy to read tests. The duplication of test doubles written by hand is minimized by the use mocking framework.
Legacy Coderetreat: Part 8 – Extract and Override
Extract and Override
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.
Purpose
Almost always when needing to test existing code we bump against dependencies that make the system untestable. This technique is useful to extract the static dependencies. After that we can use dependency inversion in order to be able to really test the systems.
With this technique we can transform untestable systems into testable systems, step by step. The steps are small because we want to enable safety while changing the code.
Legacy Coderetreat: Part 7 – Dependency inversion
Dependency Inversion
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.
Purpose
As you found out from the previous post, it would be a good idea to refactor in a safe way. This session is about another concept that will prepare for the tough refactorings ahead.
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.
