Evolutionary Design - Refactoring Heuristics

Evolutionary Design
- Refactoring Heuristics -
By Adrian Bolboacă

blog.adrianbolboaca.ro
Programmer, Trainer, Coach
Focused on organizational and
technical coaching
Co-Author of the Coderetreat Book
leanpub.com/coderetreat
Interested in raising the bar of
software development
Experimenting with Evolutionary
Design for ~6 year

How do we evolve the code?
Focused on solution
● Plan, Write, Deploy (waterfall)
● Planned & Iterative (misunderstood Agile)
● Planned & Iterative & Incorporate feedback (Scrum)
Focused on problem
● Unplanned & Iterative (misunderstood extreme programming)
● Unplanned & Iterative & Incorporate feedback
(evolutionary)

Code
Evolution
Focused
On
solution

Code Evolution: Focused on solution
1. Analyze
2. Find at least three solutions
3. Choose the best solution
4. Implement the chosen solution
a. Implement a feature
b. Improve feature
c. Implement next feature
d. Refactor
e. ….
5. Measure solution efficiency
6. Improve the implementation
7. Done

Code
Evolution
Focused
On
problem

Code Evolution: focused on problem
1. Analyze
2. Understand the problem
3. Find the simplest solution possible
4. Implement the simplest solution possible (start with a
test)
5. Complicate solution to be closer to reality (add more
tests)
6. When duplication occurs, extract design elements
7. When solution is good enough, stop
8. Check, Test and Deploy

Refactoring
● Essential in evolutionary design
“Refactoring means changing the structure of the code
without changing its external observable behavior”
● Purpose: generate design specific for the problem
● How: Navigate through possible solutions
● Prerequisites:
○ Know design concepts and “laws”
○ Observe violations of design concepts
○ A lot of practice

Refactorings
● Are specific
● Have clear steps
● Some of them are automated by tools
● When used in correct order they generate flow
● Often not used in correct order
Problem: When do I know how to use a specific refactoring
technique?
Solution: Refactoring Heuristics

Refactoring heuristics
● Signs telling you when to use a refactoring
● Are educated by practice
● Useful not to get stuck in refactoring
● Useful understanding when you used the wrong refactoring
● Help you avoid mistakes
● Can get you in a refactoring flow

1. Refactoring mantra
1. Write / Execute simplest test
2. (Write the simplest production code to make the test
pass)
3. Refactor
a. Are names good enough? (variables, methods, classes, etc)
b. Is the structure right (coupling, cohesion, responsibilities, etc)
c. Am I going on a good path?
4. Commit to local source control
5. Go to 1
After ~25 minutes take a break
Maybe push to central source control repository

2. The rule of three
“Whenever I see a design element repeat itself at least
three times, it might be a sign of duplication”
Solution:
1. Make duplication identical
2. Use extract refactoring (constant, variable, method,
class)
3. Restructure code to look nice
Hint: Always create duplication in order to remove it

3. Unnatural third party
“When code throughout the system is not respecting its
natural level of abstraction and will cross one or more
architectural boundaries (e.g. layers) of the system”
Solution:
1. Extract the code blocks to methods
2. Move the extracted methods to a new module raising the
abstraction of the system and encapsulating the 3rd party
3. Check if the code structure is correct
4. If I have a vampire structure, remove it

4. Keep Small visual distance
“Whenever refactoring, keep the similar pieces of code close
one to another in order to spot duplication”
Solution:
● Use your IDE to move the similar methods
OR
● Copy / paste the method, then delete the initial method

5. Small code width
“When the code line is too wide it is difficult to
understand”
● Change the font size in your IDE to 18. If you cannot see
all the code in the screen, the code is too wide.
Solutions:
● Extract method
● Consolidate conditional
● Consolidate logical expression

6. Adult parameter
“Many methods have the same parameter in the same class”
● Typically happens when we extract pure functions from a
bigger code base
Solution:
1. Create a class field for that parameter
2. Change signature of each method to remove that parameter
3. Check, Test & Commit

More Refactoring Heuristics
● Vampire Class
● Extract only Domain Concepts
● Close the Closure
● Zombie Class
● Redundant Comment
● Always rename one entity at a time
● … and many more
Soon read more about them on blog.adrianbolboaca.ro

Refactoring, TDD & Structural Brain Changes

Maguire et al. 2000
“The role of the hippocampus is to facilitate spatial
memory, in the form of navigation”
“A correlation was found between the amount of time spent as
a taxi driver and volume in the right posterior hippocampus”
“The results provide evidence [..] that extensive practice
with spatial navigation affects the hippocampus”
https://www.tutor2u.net/psychology/reference/maguire-2000

So i leave you with one idea
Wire your brain by practicing
refactoring if you want to be able
to navigate to the best solutions.
Start with Refactoring Heuristics.

Let’s Pair
I am available for face 2 face or remote pairing
Just drop a line http://blog.adrianbolboaca.ro/contact

Evolutionary Design - Refactoring Heuristics

More Related Content

What's hot (20)

Similar to Evolutionary Design - Refactoring Heuristics (20)

More from Adi Bolboaca (19)

Recently uploaded (20)

Evolutionary Design - Refactoring Heuristics