My second talk from 2015 Java2days conference. Looking at what refactoring is, why we do it and how to convince others to allow us doing that.

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
==
Meanwhile in perfect worldMeanwhile in perfect world

11. 11CONFIDENTIAL
• 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

12. 12CONFIDENTIAL
EVERYDAY REFACTORINGS
REFACTORING TYPES

13. 13CONFIDENTIAL
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

14. 14CONFIDENTIAL
• 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

15. 15CONFIDENTIAL
• 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

16. 16CONFIDENTIAL
BIG BANG
REFACTORING TYPES

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

18. 18CONFIDENTIAL
• 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

19. 19CONFIDENTIAL
ConsCons
By Indi Samarajiva

20. 20CONFIDENTIAL
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

21. 21CONFIDENTIAL
ConsCons
By Indi Samarajiva

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

23. 23CONFIDENTIAL
SPROUTING
REFACTORING TYPES

24. 24CONFIDENTIAL
• 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

25. 25CONFIDENTIAL
• 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

26. 26CONFIDENTIAL
• 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

27. 27CONFIDENTIAL
GET PERMISSION
REFACTORING

28. 28CONFIDENTIAL
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

29. 29CONFIDENTIAL
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

30. 30CONFIDENTIAL

31. 31CONFIDENTIAL
HOW TO MEASURE
REFACTORING

32. 32CONFIDENTIAL

33. 33CONFIDENTIAL

34. 34CONFIDENTIAL
QA and SupportQA and Support

35. 35CONFIDENTIAL

36. 36CONFIDENTIAL
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 ;)

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

38. 38CONFIDENTIAL
EXAMPLES

39. 39CONFIDENTIAL
• 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

40. 40CONFIDENTIAL
• ~5 year old system
• Build on top of 5+ year old code base
• Sudden plan to change business model without consulting with developers
– Business seen that as a simple change (we have everything)
– Development seen a lot of dependencies
– Unable to do as a simple change request
Big Bang :: Real world example -> Domain changeBig Bang :: Real world example -> Domain change

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

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

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

44. 44CONFIDENTIAL
QA SupportQA Support
Case:
Releases are done each week, a lot of DB changes are tangled in, QA has to support each release.
Developers get often issues with not building app, due to DB schema differences. They ask QA for support to get new
schema after each release. A lot of people time is being wasted.

45. 45CONFIDENTIAL
Case:
Product did not have versioning in first place. It was build
by ant only with some hacks to introduce new build tool:
Maven. Whole thing was in one version, always.
One of hacks involved adding qualifier to allow testing on
different environments.
versioningversioning

46. 46CONFIDENTIAL
• Don’t allow that to happen
• Refactoring is everyone business
• Small group of experts
• Not everyone care about code quality
• You may end up with huge rotation
• Ideas are not evenly distributed between teams
Antipattern – refactoring teamAntipattern – refactoring team

47. 47CONFIDENTIAL
• Happens on regular basis
• Everyone participate
• Enables the everyday refactorings
• Does not have to be only about TODOs (duh ;))
TODO huntingTODO hunting

48. 48CONFIDENTIAL

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