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.

Extract Class

Extract Class

Read More →

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.

minimize-duplication

Read More →

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.

Pure functions

Pure functions

Read More →

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.

mocking-framework

Read More →

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.

Extract and Override

Extract and Override

Read More →

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.

Sierpinski_Racket_example Read More →

Legacy Coderetreat: Part 6 – Basic rules of refactoring

Basic Rules of Refactoring

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

This technique is useful to minimize the mistakes one does while changing existing code. When refactoring existing code, one can introduce defects because of rushing through the changes.

During the next sections you will find some rules (guidelines) and some explanations about why these rules are useful.

 

Basic Rules of Refactoring

Basic Rules of Refactoring

Read More →

Coding Games – video at xALEc

Coding games

This is a video from xALEc where I am part of a conversation about how one could teach programmers to be better by using games and pair-programming.

Coderetreat: The toughest constraint

Coderetreat: The toughest constraint

Ask the attendees what they want

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.

The constraint

Now it was different. They wanted the scary constraints. And they insisted. So here is the constraint.

universe-with-wormholes
Read More →

Legacy Coderetreat: Part 5 – Add features on Legacy Code

Add features 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

When we need to add features in legacy code we need to make sure we understand it. But the feature needs to be added to an existing system. For that we need first of all to understand the current behaviour of the system. After that we need to make room for the change by refactoring the existing code. Of course we need a safety net before refactoring the existing system. Once we have room for the new feature we can alter the existing system. The main purposes of writing tests before adding the feature would be first of all to make sure we do not introduce defects and secondly to make sure we add the wanted feature. By having tests written for the new feature we can validate them with our product colleagues.

During the next section you will find the steps to take in order to minimize the risk of introducing defect or adding the wrong feature to legacy code, what you would do at a legacy coderetreat.

Add features on legacy code

Add features on legacy code

Read More →