REFACTORING MEETS BIG MONEY
There is that day in life of every developer when he goes to boss and asks for permission to rewrite / refactor our application. It can be that inherited thing, maybe something we wrote on our own, however it's often the moment when we feel it can't go any further. We're frustrated and angry.
I've been there, did it couple of times, and I won't hide, failed couple of times. There are still systems out there, that counted on me, that I'll get some love for them from business and I've failed them!
Right now it's a perfect time to share some of that experience, especially all the successful techniques I've been able to identified, to rescues all the systems out there among with sanity of developers that work on them.
I'll share everything I've learned on how to convince business to refactor, what are the possible strategies and finally, most likely most importantly, what to do and how to live with that legacy crap if we fail. The world does not end and we don't have to change our job if we fail.
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 refactor
14. 14CONFIDENTIAL
Everyday refactoring :: Definition
• Rename variable / method / class names
• Extract class / method / variable / parameter
• Move code around
• Removing duplicaTon (DRY)
• Removing dead code
• Cleaning up comments
• Improving encapsulaTon
• etc
hUp://www.infoq.com/arTcles/natural-course-refactoring
15. 15CONFIDENTIAL
• Increases readability of code
• Enables understanding of code
• Introduces paUerns
• Simplifies/allows tesTng
• Cleans up potenTal, 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 :: Pros
By MazeNL77
16. 16CONFIDENTIAL
• In big ball of mud is not always safe!
– Watch out for reflecTon!
• 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 restricTve tools, can be counterproducTve
– Pre-hooks anyone?
Everyday refactoring :: Cons
By Indi Samarajiva
29. 29CONFIDENTIAL
Decide what to measure
• How many commits / sprint
• How many commits / file (how ofen it changes)
– By different users/ In one sprint
• CyclomaTc complexity
• Code coverage
• LOC per sprint
• Findbugs issues
• Requests / second
• Resource (Memory/CPU) usage
• Lead Tme (how long its on board)
By MarTnvl
36. 36CONFIDENTIAL
Show & discuss
• Business like numbers
– Even if they don’t understand them
• Setup goals / milestones
• Try to use work Tme
• Setup day / sprint of excellence
• Organize hackathon / code retreat
• Share knowledge and train colleagues
• Set standards
– And enforce them with pre-commit hooks ;)
41. 41CONFIDENTIAL
• ~5 year old system
• Build on top of 5+ year old code base
• Sudden plan to change business model without consulTng 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 change