Evolutionary Design seems to be one of the black arts of software development. Test Driven Development brought the need of understanding how to evolve the code in order to solve a problem. Evolving the code is not done by magic, we evolve the code, the programmers. And we need specific techniques for that. This talk will be an interactive one, presenting some of the most useful refactoring techniques for Evolutionary Design.

1. Evolutionary Design
- Refactoring Heuristics -
By Adrian Bolboacă

2. 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

3. 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)

4. Code
Evolution
Focused
On
solution

5. 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

6. Code
Evolution
Focused
On
problem

7. 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

8. 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

9. 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

10. Refactoring
Heuristics

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. Refactoring, TDD & Structural Brain Changes

20. 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

21. 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.

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

23. Questions?