# 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)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/code-katas/refactoring-journey-kata.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.