Tag Archives: Refactoring

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

A community event: Bring your own code

Bring your own code

Last month I started a new community event idea. It is called “Bring your own code”, and I “stole” it from what Antoine Vernois is doing in the Toulouse Software Craftsmanship Community. You can find here the event page. Tomorrow we will have the second edition that you can find here. Let’s go a bit into the mechanics of this event type.

Why

  • You have a project and you want a second opinion.
  • Your code needs improvements and you do not know where to start from.
  • You just like to show some awesome code and give it as an example.
Bring Your Own Code

Bring Your Own Code

Read More →

The history of “Brutal Refactoring Game”

The history of Brutal Refactoring Game

Last year I was thinking about a session during which attendees would learn how to focus on refactoring. I had some thoughts about this: we would need a list of coding smells, and have some cards to give the attendees that had that coding smells in their code. Now the obvious question was: how can you have coding smells if you do not have a code base? I thought about it, and then I figured it out: during coderetreats I anyway see legacy code after 10-15 minutes. So if this session would take 90-120 minutes we would have no issue with finding coding smells.

The first thing was: of course I will ask people to do pair-programming. This is how you learn a lot!

I came with these basic thoughts to Alex, and we had a chat about this session. Initially I had wanted to print one index card for each of the coding smells. But Alex helped me simplify the concept by creating a numbered list of coding smells that would be projected on a screen. Then we thought: we could use index cards just to write the number of the coding smell.

Refactor your code commrades or it s the gulags for you

Now the question was: how do we do this? How can we enforce the coding smells? We thought about it and we said “we love clean code, so we could be something like a dictator”. Then we both had in mind the concept of “Benevolent Dictator“. The sessions was starting to shape-up. The benevolent dictator was a key factor in the environment we wanted to create: learn and play.

Read More →