where refactoring meets big $$$
Post on 13-Jan-2017
296 Views
Preview:
TRANSCRIPT
4CONFIDENTIAL
Contact informationContact information
@michalgruca
michal.gruca@gmail.com
www.rits.pl
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
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
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
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
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
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
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
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
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
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
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
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 ;)
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
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
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.
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
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
47CONFIDENTIAL
• Happens on regular basis
• Everyone participate
• Enables the everyday refactorings
• Does not have to be only about TODOs (duh ;))
TODO huntingTODO hunting
top related