Refactoring zealots will tell you you cannot refactor without proper unit test in place - Five Lines of Code assumes no tests available (although highly encouraged) while providing practical coding patterns (XP / Clean Code / Refactoring) that leverage the IDE and compiler such that they are considered "safe".
Christian Clausen does a fantastic job at weaving together the fundamentals of technical agile (craftsmanship) practices that are accessible to beginners yet thought provoking enough to teach the oldest of us dogs a few tricks.
Refactoring - the discipline of transforming bad code to good code without breaking it. It works best - and cost least - if you do it regularly.
Good Code
- Human Readable
- Maintainable
- Performs task as expected
Time is expensive, make easy to read
Make change easy, then make easy change
Readability - code's aptitude for communicating intent
Maintainability - risk inherent to change
Readability over Performance
(except when performance matters)
Rules
Rule - Five Lines
- No more than five lines
- Specific limit less important than having limit
- Extract method
Comments are used like deodorant on bad code
Rule - Either Call or Pass
- Call or pass, not both
- Keep at same level of abstraction
Carefully consider names
Rule - If Only At The Start
-
if
should be first thing in function
Rule - Never Use If With Else
- Unless, checking against data type not in control
-
if-else
as hardcoded decision
Push Code Into Classes
refactoring pattern as an extension of Replace Type Code With Classes
Rule - Never Use Switch
- Unless, no default and return in every case
Rule - Only Inherit from Interfaces
- Shared code causes coupling
Favor object composition over inheritance
IDEs indicate unused code, delete it!
Rule - Use Pure Conditions
- Command and query separation
Don't have to understand all code to refactor.
Strategy Pattern is a powerful refactoring tool.
Rule - No Interface With Only One Implementation
- Interface signals variation; if none, adds overhead to mental model
Rule - Do Not Use Getters or Setters
- Force Pushed-Based Architecture, class behavior
Law of Demeter - Don't talk to strangers
Getters mask violations
Rule - Never Have Common Affixes
- Code should not have common prefixes or suffixes
The Real World
Enforce Sequence
- Remove sequence invariant / temporal coupling
- Utilize constructors / lifecycle events
Listen to compiler's output, including its warnings
Avoid having multiple threads with shared mutable data
Zero Compiler Warnings - Broken Window Theory
Comments are sus, smell, and are not to be used as deodorant on unclean code
Comment only what code cannot say - why comments, not what comments
Code is a liability
Incidental Complexity - "Tech Debt"
- ignorance
- waste
- debt
- drag
Sharpen the Saw - 80/20
Anything that is unused, no matter it's potential, is only an expense
Generality and Optimization sacrifice Simplicity - take precautions to minimize adverse effects
Only solve problem at hand, not problem can imagine
Maximize amount of work not done
Code is efficient until proven otherwise - avoid premature performance optimizations at the cost of readability - setup performance tests when optimization is necessary
Isolate tuned code #magic
If cannot make it good, make it stand out
Cyclomatic Complexity as lower bound for number of tests - one for each path through the code
Improving through small steps is what refactoring is about
Rules Overview
- Five Lines
- Either Call or Pass
-
if
Only At The Start - Never Use
if
withelse
- Never Use
switcth
- Only Inherit From Interfaces
- Use Pure Conditions
- No Interface With Only One Implementation
- Do Not Use Getters Or Setters
- Never Have Common Affixes
Top comments (0)