A comprehensive view of refactoring

Since Fowler's definition, refactoring has become a daily practice for developers in teams around the world. It is an essential technique for maintaining adaptable software code, and a test suite is a requirement for this. Meanwhile, refactoring also requires discipline and maturity in those who apply it, such as how, when, and why it becomes a necessity not only for a developer but also for the business.

Transcript

1. A comprehensive view of refactoring 1 12/06/2025
2. 2 Ryanair + Codurance Software crafters Madrid
3. ¡Hola! And Welcome javier.raez@codurance.com https://www.linkedin.com/in/javier -raez-labrado-12b9b215a/ matheus.marabesi@codurance.com linkedin.com/in/marabesi Javier Raez Labrado 3 Matheus Marabesi
4. 4 Agenda 1. Part I ◦ Theory aspect 2. Part II ◦ Refactoring time 3. Part III ◦ Holistic view
5. Part I 5 Theory
6. What is refactoring? Any thoughts? 6
7. What is refactoring? Is the process of improving the code without changing its behaviour (Fowler) 7
8. Gilded rose (Typescript) Hi and welcome to team Gilded Rose. As you know, we are a small inn with a prime location in a prominent city ran by a friendly innkeeper named Allison. We also buy and sell only the finest goods. Unfortunately, our goods are constantly degrading in quality as they approach their sell by date. We have a system in place that updates our inventory for us. It was developed by a no-nonsense type named Leeroy, who has moved on to new adventures. Your task is to add the new feature to our system so that we can begin selling a new category of items: • All items have a SellIn value which denotes the number of days we have to sell the item • All items have a Quality value which denotes how valuable the item is • At the end of each day our system lowers both values for every item Pretty simple, right? Well this is where it gets interesting: • Once the sell by date has passed, Quality degrades twice as fast • The Quality of an item is never negative • “Aged Brie” actually increases in Quality the older it gets • The Quality of an item is never more than 50 • “Sulfuras”, being a legendary item, never has to be sold or decreases in Quality • “Backstage passes”, like aged brie, increases in Quality as its SellIn value approaches; ◦ Quality increases by 2 when there are 10 days or less and by 3 when there are 5 days or less but ◦ Quality drops to 0 after the concert Our task We have recently signed a supplier of conjured items. This requires an update to our system: “Conjured” items degrade in Quality twice as fast as normal items Rules Feel free to make any changes to the UpdateQuality method and add any new code as long as everything still works correctly. However, do not alter the Item class or Items property as those belong to the goblin in the corner who will insta-rage and one-shot you as he doesn’t believe in shared code ownership (you can make the UpdateQuality method and Items property static if you like, we’ll cover for you). Just for clarification, an item can never have its Quality increase above 50, however “Sulfuras” is a legendary item and as such its Quality is 80 and it never alters. https://kata-log.rocks/gilded-rose-kata 8
9. Change is the constant of software • Improve the structure of a program to improve maintenance (less complex code) • To make room for new features 9
10. 10 - Improve the structure of a program to improve maintenance - To make room for new features Why do we refactor? • We want to reduce the cost and keep it as close as possible to the coding part • Reaching production is costly A constant loop
11. Refactor vs rewrite? What are the differences between them? 11
12. Refactor vs rewrite? • Refactor ◦ We work on the existing code ◦ Iterative - step by step • Rewrite ◦ Big bang - new code ◦ Static ◦ Rewrite does not mean no refactor, it delays the decision
13. Misconceptions about refactoring 13 • Misconception ◦ We should stop everything and focus on refactoring ◦ It will take too long • Alternatives ◦ Campament scout rule ◦ Ways of working ◦ Refactor early, refactor often - Pragmatic Programmer
14. 3 min BREAK 14
15. • Refactoring is the practice of improving existing code without changing its behaviour • We do it because : ◦ we want to make code maintainable - at individual level ◦ reduce the cost of change - at organization level 15 Part I - Recap
16. Part II 16 Refactoring
17. Refactoring guidelines • Get familiar first ◦ get familiar with the setup • Stay in green ◦ tests should be testing behavior, so there is no reason why we should break any tests during refactoring. If you break any, undo, go back to green and start over • Commit as often as possible ◦ Make use of source control to safely and quickly revert to a known good point, provided we took small steps and committed frequently • Refactor readability before design ◦ Prefer small improvements in code readability in order to proceed with later design changes.
18. Most popular ones • Rename ◦ Change the name of classes, methods, variables, etc. • Extract ◦ Extract a class (or methods or variables …), creating a new abstraction. • Inline ◦ The inverse of extract. Inline a method (or variable), deconstructing an abstraction. • Move ◦ Move a class (or methods or variables…) to some other place in the codebase. • Safe delete ◦ Delete code and its usages in the code base.
19. Readability x Design 'To change something, first we need to understand something'. 19 Favor
20. Readability • Format ◦ Format consistently and don’t force the reader to waste time due to inconsistent formatting. Keep an eye on code conventions. • Rename ◦ Rename bad names, variables, arguments, methods, etc. Make abbreviations explicit. • Remove ◦ Delete unnecessary comments, delete dead code • Extract ◦ Constants from magic numbers and strings • Reorder ◦ Refine scope for improper variable scoping, and make sure variables are declared close to where they are used. • Flip if/else ◦ reduce cognitive load, instead of negate the condition uses it as positive
21. Design • Extract private methods from deep conditionals. • Extract smaller private methods from long methods, and encapsulate cryptic code in private methods. • Return from methods as soon as possible. • Encapsulate where we find missing encapsulation. • Remove duplication
22. Parallel change (expand, migrate, contract) This is a useful technique to implement breaking changes safely while staying in green. It consists of 3 steps: • Expand ◦ Introduce new functionality by adding new code instead of changing existing one. • Migrate ◦ Deprecate old code and allow clients to migrate to new expanded code, or change client code to point to new code • Contract ◦ Once all client code is migrated to new code, remove old functionality by removing deprecated code and its tests.
23. 3 min BREAK 23
24. • The refactoring process (each commit with a single change) - guidelines • Improved readability • Improved design • Improved the system - now we have a new functionality - Parallel change (expand) 24 Part II - Recap
25. Part III 25 Holistic view
26. Types of refactoring • Code ✅ • Persistence • Architecture
27. Persistence Rules: 1. Parallel change by default 2. Migration scripts (versioned in the repository) 27
28. Architecture/Re-architect? • DDD - Boundaries • Coupling 28
29. 29 Code Persistence Arch Short cycles, as much as possible Longer cycles, Less frequent Limit Priority
30. • Practice with the kata we used (or others) • Check the resources we have used: Refactoring and Refactoring catalog by Martin Fowler, Migrating databases by Edson Yanaga, cost of change by agilemodeling.com 30 Where to go from here?
31. ¡Gracias! Let's keep in touch javier.raez@codurance.com https://www.linkedin.com/in/javier-raez-l abrado-12b9b215a/ matheus.marabesi@codurance.com linkedin.com/in/marabesi Javier Raez 31 Matheus Marabesi