Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Crafting Code: Staying Green for Faster Refactoring
- 1. @jancowol Janco Wolmarans (@jancowol) Safety First! How to drop the compiler crutch for faster refactoring Crafting Code
- 2. @jancowol Usual Mechanics of Refactoring > Make a change, compile > Fix the compiler errors, compile > Fix more compiler errors, compile again > Fix last of the compiler errors, compile AGAIN > These are the last errors, I can feel it! > Test PDD (Prayer Driven Development)
- 3. @jancowol Going Red is SLOW Red Loss of Momentum Programming by Coincidence Foggy (end is unclear) Reduces Confidence Lost in the Weeds
- 4. @jancowol How do we move fast?
- 5. @jancowol How do we move fast?
- 6. @jancowol Flow Going fast is not about going fast.
- 7. @jancowol The Safety First Approach Staying Green Make a small change Scaffolding • Temp variables • Hardcoding • Duplication • Inlining Safety nets • Compiler • Tests Remove scaffolding Decompose refactoring
- 9. @jancowol What now? > Refactoring Book - Martin Fowler > Practice! (From first principles / Katas) > Reflect after a breaking change > Know your tools > Learn what good design looks like (and code smells) > Realise that there is no absolute safety
- 10. @jancowol /* THANK YOU*/ Janco Wolmarans Driven Alliance jancow@gmail.com @jancowol http://www.devconf.co.za/
Editor's Notes
- Relying on the compiler as a primary tool for refactoring can leave us in a broken, uncertain place.
- Relying on the compiler to break when we make changes, it causes: Fogginess. Where we don’t know when we’ll reach the end. Fixing one error may cause more to appear. Losing sight of the bigger picture. Diving down into fixing errors shifts the focus from the original change goal. Programming by coincidence. When the code eventually compiles, we may not be sure why. When code works by coincidence, it reduces confidence and introduces doubt. Loss of momentum, by frequently starting and stopping.
- A fast car can only go fast if…
- …it has wheels.
- Speed is neutralised by any stoppages. When code breaks we stop. In order to move forward at all, we need to make things work first. By striving to never have breaking code, we’re always in the position where we can make changes and keep moving forward.
- Decompose refactoring into a series of small steps. No step should result in code that is red for more than a few seconds. If this proves difficult, attempt to decompose further. Use scaffolding as temporary constructs to stay green and keep functional integrity. The compiler then becomes a sanity checking safety net, instead of a slow crutch.
- Demo a refactoring that replaces a simple int return value with a complex object.
- The Refactoring book is great for understanding a number of tool-based automated refactoring from first principles. When a refactoring results in a compiler error, step back and reflect. Consider smaller steps. Knowing your automated refactoring tool well helps when decomposing a refactoring. In order to refactor effectively, an understanding of good design is essential. Need to know the ideal end-state of the attempted refactoring. Even with small safe steps, when the compiler reports success, and the tests are passing, there’s always the possibility of inadvertently introducing errors. The odds of introducing errors are significantly reduced by this approach.