Michał Gruca
Language: Polish
Wielu z nas miało ten moment w trakcie kariery (albo dopiero cała zabawa przed nimi), kiedy idzie się do szefa powiedzieć, że tak już się nie da dalej ciągnąć i trzeba cały ten soft przepisać albo zrifaktorować (i to bez szwagra).
Dla tej (podejrzewam, że większej) części z nas, która zna gorycz porażki w walce z biznesem o jakość, dedykuję ten talk. Przechodziłem w swoim życiu kilka razy ten cykl, próbowałem przepchnąć zmiany większe i mniejsze. Po kilku latach (i próbach), mam pewne sukcesy na tym polu i czas podzielić się z innymi jak do tematu można podejść.
Podczas wykładu spojrzymy na to czym jest ten cały refactoring, jak można do tematu podejść, zaplanować oraz przede wszystkim jak przekonać biznes by na niego kasę wyłożył.
Nie będę ściemniać, sukces nie jest murowany więc pochylimy się też nad tematem co zrobić jak kasy nie będzie a kod trzeba i tak ratować.
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
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
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
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
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
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
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
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 ;)