Reminder: This learning hour is screen recording friendly. If one of the team members can't join, you can record it, and they'll be able to watch later.
The first step to a successful refactoring is understanding of what the refactoring is and isn't. The second part is the knowledge of the vocabulary of different code smells and refactorings that can solve them. Both are useful for communication between team members (fewer misunderstandings and more alignment), and smoother execution.
Reading: (10 min) (& asking clarification questions)
Martin Fowler's definition of 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.
-- source
below statements are generally false
- Refactoring work should be planned and prioritized alongside user stories for the sprint.
- When someone is refactoring the code may be broken for a few days while they do it.
- Code reviews generate refactoring tasks in the backlog.
- If you encounter ugly code it is your moral duty to refactor it.
- The team lead does most of the refactoring, others should only refactor when they are told to.
- If you don’t understand the code you shouldn’t refactor it.
- You should refactor in a code branch and have QA test it to confirm you haven’t broken anything before merging to master.
- You should get permission from your manager before refactoring.
(5 min)
What code smell names do you already know?
(5 min)
What refactoring names do you already know?
If you haven't read, then it's a good idea to start reading this at your own pace:
“Refactoring 2nd Edition” by M. Fowler
(10 min)
In the following code,
- Identify code smells
- Suggest which refactoring could be used
Tennis rules for this kata can be found here
(5 min)
Coach demonstrates one or two extract function refactorings for this code.
(20 min)
Use the code sharing tool of your choice (e.g., JB Code-With-Me or VS Code LiveShare).
Ensemble rules:
- Driver rotates every 5 min
- Ensemble serves as a collective navigator
- Coach serves as a facilitator, keeping the ensemble productive
(5 min)
Reflection:
- What did you learn today?
- What would you do differently starting tomorrow?
- What else do you want to learn deeper now (that you weren't aware before)?