> For the complete documentation index, see [llms.txt](https://yoan-thirion.gitbook.io/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/code-katas/refactoring-journey-kata.md).

# Refactoring journey

## Objectives

* Practice refactoring tips to improve your day-to-day efficiency
* Use your IDE features

![](/files/-MRThN9ncVWGcSYbV2va)

### Before we start

* Clone the repository [here](https://github.com/ythirion/refactoring-journey)
* Make sure you can run the tests

## Connection

### Refactoring, you said refactoring ?

![](/files/-MRTkJlw8bDTtWCbTWWW)

***Names of Refactorings :***

* Write down names of refactorings you already know
* Write up names on a whiteboard or flipchart

Remind them some they use probably : Rename Variable and Extract Interface.

## Concepts

### Several ways to write code

![](/files/-MRTkiNm7iP29axl6M4O)

### What is refactoring ?

> *Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.*
>
> *Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behavior*. - [Martin Fowler](https://martinfowler.com/bliki/DefinitionOfRefactoring.html)

{% hint style="success" %}
Refactoring is a systematic process of **improving code** without creating new functionality that **can transform a mess into clean code and simple design**.
{% endhint %}

![](/files/-MRTl2C4HzbPK82ctWvP)

> ***The main purpose of refactoring is to fight technical debt***

### When to refactor ?

![](/files/-MRTn4ShUnxB4Ys9eTO9)

#### When adding a feature

* If you must deal with someone else’s dirty code, try to refactor it first
  * Clean code is much easier to grasp
* Refactoring makes it easier to add new features
  * Easier to make changes in clean code

#### Rule of Three (duplication)

* You can copy and paste the code once
* BUT when the same code is replicated **3 times**, it should be extracted into a new procedure

#### When fixing a bug

* Clean your code and the errors will practically discover themselves.

#### During a code review

* Code review may be the last chance to tidy up the code before it becomes available to the public
* Best to perform reviews in a pair with an author : *you could fix simple problems quickly*

#### When paying your debt

* Dev teams can create technical debt consciously at one time and book some time later to tackle it
* See [technical debt quadrants](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)

### How to ?

![](/files/-MRToMGe-vvYotkkUcQ0)

There are two cases when tests can break down after refactoring : 

* You made an ***error during refactoring***
  * Go ahead and fix the error
* Your ***tests were too low-level*** (for example, you were testing private methods of classes)
  * In this case : the tests are to blame
  * Either refactor the tests themselves or write an entirely new set of higher-level tests

## Concrete Practice

![](/files/-MRTpUnhI5s-BK6POjhv)

Follow the journey step by step as explained in [my website](https://ythirion.github.io/refactoring-journey/) :

![](/files/-MTBmWEHCaKHDr3QYmS7)

#### Enjoy the Journey

![Refactoring Journey map](/files/-MTo4_ZPTzIWbjX19lam)

## Conclusion

**Learning feedback**

* Each participant add his/her name on the quadrant
* Please explain ***why you are there***

![](/files/-MRTqNEHu_kHtSNlf1AL)