Presentation about how to refactor, what are the types of refactorings and how to sell refactoring to the business

1. 1CONFIDENTIAL
Where refactoring
meets
Big $$$
First steps

2. 2CONFIDENTIAL
RULES ;)
REFACTORING

3. 3CONFIDENTIAL
By The U.S. Army

4. 4CONFIDENTIAL
Contact informationContact information
@michalgruca
michal.gruca@gmail.com
www.rits.pl

5. 5CONFIDENTIAL
WHO REFACTORS CODE
QUESTION

6. 6CONFIDENTIAL
ON A DAILY BASIS 

7. 7CONFIDENTIAL
WHO PLANS REFACTORINGS?
QUESTION

8. 8CONFIDENTIAL
ACADEMIA TIME
REFACTORING

9. 9CONFIDENTIAL
What is refactoringWhat is refactoring

10. 10CONFIDENTIAL
That is very true, but to simplify discussion,
I’m going to refer to changes as refactorings as well

11. 11CONFIDENTIAL
Meanwhile in perfect worldMeanwhile in perfect world

12. 12CONFIDENTIAL
• It’s hard to maintain
• Changes in domain are coming
– New requirements are impossible to implement
• There are no tests (sic!)
• Development of new features is so slow
• System is slow
• You just don’t want to go to work anymore
– (nor your colleagues)
Why to refactorWhy to refactor

13. 13CONFIDENTIAL
EVERYDAY REFACTORINGS
REFACTORING TYPES

14. 14CONFIDENTIAL
Everyday refactoring :: DefinitionEveryday refactoring :: Definition
• Rename variable / method / class names
• Extract class / method / variable / parameter
• Move code around
• Removing duplication (DRY)
• Removing dead code
• Cleaning up comments
• Improving encapsulation
• etc
http://www.infoq.com/articles/natural-course-refactoring

15. 15CONFIDENTIAL
• Increases readability of code
• Enables understanding of code
• Introduces patterns
• Simplifies/allows testing
• Cleans up potential, simple, programming mistakes
• Fully supported by IDE in any language
• Is fast, does not need to be planned
• Does not require process, can be done on a go
• Is safe and non-intrusive
– But not always!
Everyday refactoring :: ProsEveryday refactoring :: Pros
By MazeNL77

16. 16CONFIDENTIAL
• In big ball of mud is not always safe!
– Watch out for reflection!
• Without tests and tools (IDE) can be very dangerous
• May be source of funky bugs
• No process, not all developers will adapt
• If backed with restrictive tools, can be
counterproductive
– Pre-hooks anyone?
Everyday refactoring :: ConsEveryday refactoring :: Cons
By Indi Samarajiva

17. 17CONFIDENTIAL
• Quarter of development followed by phase 2 with up to 6 months of work for team
– And short break between them
• Funky structure of domain model
– TreeMap<Integer, Map<TabelType, Map<RecordType, List<TableId>>>>
• Only creator understood the design
Everyday refactoring :: Example -> Planned refactoringsEveryday refactoring :: Example -> Planned refactorings

18. 18CONFIDENTIAL
BIG BANG
REFACTORING TYPES

19. 19CONFIDENTIAL
Big Bang :: DefinitionBig Bang :: Definition
By Xtraterestrial

20. 20CONFIDENTIAL
• Allows for a fresh start
– New technology stack
– Clean architecture
– Better domain model
• Can be a serious contributor for finding a new job ;)
ProsPros
By MazeNL77

21. 21CONFIDENTIAL
ConsCons
By Indi Samarajiva

22. 22CONFIDENTIAL
ConsCons
• We don’t deliver anything for many, many sprints
• World moves forward, our application does not
• Business is unhappy
• Success of the new project is not guaranteed
By Indi Samarajiva

23. 23CONFIDENTIAL
ConsCons
By Indi Samarajiva

24. 24CONFIDENTIAL
Big Bang :: When to do itBig Bang :: When to do it
By Wayne Ray

25. 25CONFIDENTIAL
• ~5 year old system
• Build on top of 5+ year old code base
• Sudden plan to change business model
Big Bang :: Real world example -> Domain changeBig Bang :: Real world example -> Domain change

26. 26CONFIDENTIAL
SPROUTING
REFACTORING TYPES

27. 27CONFIDENTIAL
• Proposed by Michael Feathers in
“Working Effectively with Legacy Code”
– To refactor methods
– And classes
• Can be used with whole packages, modules,
components, applications
Sprouting :: DefinitionSprouting :: Definition

28. 28CONFIDENTIAL
• Introducing new code in testable manner
• Separate abstractions
• Prevents rooting of new functionalities
• Enables change of architecture
• Allows to update technology stack
• Allows to build independent modules and applications
ProsPros
By MazeNL77

29. 29CONFIDENTIAL
• Requires much more work, people and resources than
standard feature release
• May add serious latency to functions and slow down the
whole system
• Adds more abstraction layers to the project
ConsCons
By Indi Samarajiva

30. 30CONFIDENTIAL
Sprouting :: Real world exampleSprouting :: Real world example

31. 31CONFIDENTIAL
Sprouting :: Real world exampleSprouting :: Real world example
By Crochetbug

32. 32CONFIDENTIAL
Sprouting :: Real world exampleSprouting :: Real world example

33. 33CONFIDENTIAL
GET PERMISSION
REFACTORING

34. 34CONFIDENTIAL
Decide what to measureDecide what to measure
• How many commits / sprint
• How many commits / file (how often it changes)
– By different users/ In one sprint
• Cyclomatic complexity
• Code coverage
• LOC per sprint
• Findbugs issues
• Requests / second
• Resource (Memory/CPU) usage
• Lead time (how long its on board)
By Martinvl

35. 35CONFIDENTIAL
Measure!Measure!
• Velocity
• Build time
• Number of failing builds
• Number of merges
– +time of each merge
• ROI / sprint
• Code quality
• Freeze time
• Response time
• Maximum load

36. 36CONFIDENTIAL
HOW TO MEASURE
REFACTORING

37. 37CONFIDENTIAL

38. 38CONFIDENTIAL

39. 39CONFIDENTIAL
Show & discussShow & discuss
• Business like numbers
– Even if they don’t understand them
• Setup goals / milestones
• Try to use work time
• Setup day / sprint of excellence
• Organize hackathon / code retreat
• Share knowledge and train colleagues
• Set standards
– And enforce them with pre-commit hooks ;)

40. 40CONFIDENTIAL

41. 41CONFIDENTIAL
Read list :: Build a book clubRead list :: Build a book club

42. 42CONFIDENTIAL

43. 43CONFIDENTIAL
I love your feedback! I love your feedback! 
@michalgruca
michal.gruca@gmail.com
www.rits.pl