Misconceptions about Refactoring

In this session we talk about what refactoring is and why we do it. We work on improving some names to improve readability.

There is a video on Emily Bache’s YouTube channel which shows a variant on this learning hour: “Refactoring, what you need to know”

Learning Goals

• Explain that poor names and difficult to read code are reasons to refactor
• Use the ‘rename’ refactoring to improve some code with poor names

Session Outline

• 15 min connect: refactoring warm-up questions
• 5 min concept: When should you refactor
• 30 min do: pairs refactor Tennis3
• 5 min reflect: review warm-up questions

Discuss Misconceptions

Create a handout with a number of statements about refactoring, which are controversial, wrong, or only partially true. Ask people to discuss them in small groups and decide whether each statement is true or false. Here is a sample page of questions you could use.

This is a True or False Mythbusting connect.

Purpose of refactoring

Remind people that the purpose of refactoring is to make code easier to understand and cheaper to modify.

It’s a necessary part of iterative and incremental development. You don’t plan the entire design up front, you take working code and change the design to support new functionality.

Another use of refactoring is for code that has technical debt, that is, it is harder than necessary to understand and modify. You do a series of safe refactorings on it to improve readability and reduce complexity.

Work on Tennis3

Examine the code in Tennis3 in The Tennis Refactoring Kata. Is there anything wrong with this code? Do you see any technical debt? How could refactoring improve it? Discuss what’s needed and address problems one by one.

Reflect

Ask When should you use this? I.e. when should you refactor? Have people note down their answer.