where refactoring meets big money #4developers
Post on 06-Aug-2015
57 Views
Preview:
TRANSCRIPT
4CONFIDENTIAL
Contact informationContact information
@michalgruca
michal.gruca@gmail.com
www.rits.pl
10CONFIDENTIAL
That is very true, but to simplify discussion, I’m going to refer to changes as refactorings as well
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ;)
top related