Unit Testing on Legacy Code – Codecast 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…
Extract Class – Codecast 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…
Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing! During my work I am used to pair with my colleagues on basically anything.…
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Coding Games This is a video about Coding Games from xALEc where I am part of a conversation about how one could teach programmers to be better by using games and pair-programming.
During the Global Day of Coderetreat 2014 (GDCR) I facilitated the event in Turku, Finland. That is when I presented the toughest constraint ever in any coderetreats I facilitated until now.
Since I have a lot of constraints in the list, some time ago I started to ask the attendees how difficult would they want the constraints to be. I am asking them on scale from 1 to 5, 1 being boring, and 5 being extremely difficult, what would they want to do as difficulty.
Another thing I’m doing, stealing the idea from Alex, is to ask the attendees of the coderetreat about the expectations they have. They write one expectation on a sticky note and we look at them and they choose what they want to practice. I tell them about constraints that will generate the kind of learning they want.
Usually during coderetreats the attendees want constraints of the difficulty between 2 and 3. Probably because 1 seems boring and 5 seems scary.
Now it was different. They wanted the scary constraints. And they insisted. So here is the constraint.
