Tag Archives: Coderetreat

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.

Legacy Coderetreat: Episode 5 – Basic Rules of Refactoring – Code Cast

Basic Rules of Refactoring – 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.

We start by checking what can be extracted to another method. The Basic Rules of Refactoring describes the detailed steps I use.

To ensure that we have a safety net, let us start with covering the code with some system tests and then write tests on the newly created method. These are also characterization tests, but they are often simpler than the system tests we wrote before. When the new method have been covered by tests, call it from the initial place where the code was copied from. Run all the system tests. At the end do some manual testing to see that everything works fine.

This technique is very useful to have small and safe steps while refactoring. Remember to never cut and paste. Always duplicate the implementation, cover it with tests and then reroute the call to the new code.

 

 

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.

Legacy Coderetreat: Episode 4 – Add Feature on Legacy Code – Code Cast

Add feature 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. We have a new feature request and we need to add it to a legacy code base.

We start by understanding what we need to change. After that we run the existing system tests, that we wrote during the session From Nothing to System Tests. We use a test coverage tool to understand how much of the code is covered with tests. After this step we start writing new system tests until all the code
that will be changed is covered by tests.

When all of the system is covered with tests, we refactor the code to make room for a new feature. We extract a method, then a class and then an interface. The interface is implemented in a new way so that we add the new functionality. Adding the new functionality is done with tests written up-front.

At the end we write one system test to verify that the whole system can work well with the new feature. This is a kind of partial acceptance test that helps us understand if all the system works well together. And of course, manual testing and refactoring is essential before we can say we are done.

See more about the technique in the blog post Add Features on Legacy Code.

 

 

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.

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 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 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 →

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 →