Talk given in DevFest Asturias 2019 (GDG Google Developer Group Asturias) 16.11.2019 Gijón (Spain) The Legacy Code came to stay (spanish) El legacy vino para quedarse RESUMEN Es una charla que pone en relieve que los servicios que damos los agilistas, no están orientados a sustituir el trabajo de otros, sino que entre todos conseguimos mejorar nuestros productos y nuestra vida diaria en el trabajo. ABSTRACT Casi todos sabemos lo que es el Legacy Code, ese proyecto al que todos nos hemos enfrentado alguna vez y que cuesta trabajar con él. Lo que era algo a evitar o a sustituir, en los últimos años por diversas razones, se ha convertido en algo que debe seguir existiendo durante mucho tiempo, por lo que se busca la manera de seguir manteniendolo con confianza. Esta necesidad parece técnica, y a lo sumo se entiende que involucra a los equipos que lo mantienen, pero realmente es una estrategia empresarial en la que se busca además de mantener la funcionalidad existente, avanzar el producto y cubrir la necesidad actual, con la ayuda de un equipo al que hay que mantener motivado, practicando además, eso tan difícil que hoy se conoce como La Retención del Talento. Explicaremos en esta charla los diferentes tipos de retos enmarcados en Código Legado, tantos técnicos como con los equipos a los que nos hemos enfrentado en Codesai y qué estrategias usamos para afrontarlos.

1. el Legacy vino
para quedarse
Toño de la Torre
DevFest Asturias 2019 -- 16.11.2019

2. Hi!
I’m Toñode la Torre
Software Developer at Codesai
@adelatorrefoss
2

3. GDG Asturias
https://twitter.com/GdgAsturias/status/794227008360300544
https://twitter.com/citipa/status/794227272970567680
https://twitter.com/GdgAsturias/status/768133121673928704
3

5. ¿What is legacy
code?
1

6. What is legacy
code?
▸ Code we’ve gotten from someone else.
▸ Tangled, unintelligible structure, code that you
have to change but don't really understand.
▸ Difficult-to-change code that we don’t
understand.
▸ “The sort of code you just wish would die”.
6

7. “ To me, legacy code is
simply code without tests.
Michael C. Feathers
7

8. Code without tests
“Code without tests is bad code. It doesn't matter
how well written it is; it doesn't matter how pretty or
object-oriented or well-encapsulated it is.
With tests, we can change the behavior of our
code quickly and verifiably. Without them, we
really don't know if our code is getting better or
worse.”
8

9. confidence
Being able to confidently
make changes in any code
base.
9

10. What are
legacy
projects?
2

11. Are there more
legacy than before?

12. source
team
time
budget
12

13. Team3

14. Why is this
work so hard for
teams?
Fear of make changes

15. “
Although our first joy of
programming been
intense, the misery of
dealing with legacy code is
often sufficient to
extinguish that flame.
Robert C. Martin
15

16. retain talent
is hard in
legacy

17. “If it ain't broke, don't fix it”
(aka “add a new elseif at the end”)
And the big ball of mud was born.
How code becomes
so poor?
17

18. How to write good code?
(option A)
Managers or Technical Leads set a bunch of rules or fix an
architecture.
Is mandatory to everybody to follow these rules.
Someone, usually the Tech Lead review all code (via merge
request) to check if everybody is following the “agreement”.
18

19. How to write good code?
(option A)
(SPOILER!)
It fails
19

20. How to write good code?
(option B)
Instead let’s learn.
What’s bad code?
20

21. Smell the code4

22. Code Smells
Code structures that reflects problems on the code
base. Usually indicating design flaws.
A code smell can be an easy target to start
improving the code.
22

23. Code Smells
Duplicate code
Comments (deodorant)
Long method
Large class
Long parameter list
Primitive obsession
Data clumps
23
Switch statements
Shotgun surgery
Divergent Change
Feature Envy
Message chains

24. Code Smells & Refactorings
There are refactorings techniques that might
be used to remove a given code smell.
24

25. Code Smells
& Design
It's not enough to detect that your
code has code smells (design
problems).
You also need to know what good
design is, to know how to improve
your code.
25

26. How to
technically face
legacy code?
5

27. Reasons to change
software
1. Add feature
2. Fix bug
3. Improve design
4. Optimizing resource usage
Change behavior vs Preserve behavior
27

28. Edit and
Pray
vs
Cover and
Modify
28

29. Edit and Pray
Usually, we have to preserve much more behavior
than create new one.
But, how much behavior is in risk for one change?
We have to mitigate that risk, options:
- be conservative: “add an if sentence, don’t
create a new method” (we have fear)
The Code starts to ROT
29

30. Cover and Modify
1. Cover with test first (aka regression testing)
creating a safety net.
Cover with tests act as a software vise.
2. Refactor to make place (preserving behavior).
3. Make the change.
30

31. “
31

32. Pretty Code &
Pretty Design
In legacy code is something that we arrive
at in discrete steps.
Some of the steps to make changes involve
making some code slightly uglier.
Best could be the enemy of better.
32

33. Remember TDD
basic cycle
33

34. Focus
Focus in the problem
Focus in the solution
Focus in the solution quality
34

35. Correlation between
Internal Quality and
Productivity
how easy is to find the code?
how easy is to understand the code?
how easy is to change this code?
how easy is to test my changes?
35

36. Software
Economics
36

37. Dependency
problem
Much legacy code work involves breaking
dependencies so that change can be
easier.
6

38. The Legacy
Code
Dilemma
When we change code, we should
have tests in place.
To put tests in place, we often have
to change code.
38

39. Break dependencies with conservative and
safe refactorings.
Be conservative means that, we might end
up making the code look a little poorer in
that area.
Be conservative
39

40. The Legacy Code
Change Algorithm
1. Identify change points.
2. Find test points.
3. Break dependencies.
4. Write tests.
5. Make changes and refactor.
40

41. Reasons to break
dependencies
1. Sensing : to sense effects
2. Separation : to run a piece of code into
a test harness
41

42. Show me the
code
7

43. A classic dependency

44. class MarsLander {
private DataBase dataBase;
MarsLander(DataBase dataBase) {
this.dataBase = dataBase;
}
void openParachute() {
Command command = new Command("open-parachute");
dataBase.save(command);
}
}
44

45. class MarsLanderTest {
@Test
void open_parachute_smoothly() {
MarsLander.DataBase dataBase = mock(MarsLander.DataBase.class);
MarsLander marsLander = new MarsLander(dataBase);
marsLander.openParachute();
Command expectedCommand = new Command("open-parachute");
Mockito.verify(dataBase).save(expectedCommand);
}
}
45

46. A complicated dependency
46

47. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with a communications satellite
SpaceSatellite satellite = SatelliteFactory.createABigOne();
satellite.sendCommand(command);
}
}
47

48. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with a communications satellite
sendToSatellite(command);
}
protected void sendToSatellite(Command command) {
SpaceSatellite satellite = SatelliteFactory.createABigOne();
satellite.sendCommand(command);
}
}
48

49. class MarsRoverTest {
class MarsRoverSpy extends MarsRover {
Command commandSent;
@Override
protected void sendToSatellite(Command command) {
commandSent = command;
}
}
@Test
void move_to_some_coordinates() {
MarsRoverSpy marsRover = new MarsRoverSpy();
marsRover.move(1, 1);
Command command = new Command("move", 1, 1);
assertEquals(command, marsRover.commandSent);
}
}
49

50. team again8

51. How to make the project
interesting for the teams?
The daily work with Legacy should be a challenge, an
opportunity to learn something new.
51

52. Code Smells
& Design
It's not enough to detect that your
code has code smells (design
problems).
You also need to know what good
design is, to know how to improve
your code.
52

53. How to learn along the way?
- Training in Technical skills
- Code smells, TDD, Refactoring, Design, Working with
Legacy, ...
- Knowledge Diffusion
- Pair programming
- On boarding process
- Technical concerns process
- Crystalizing Knowledge
53

54. How to learn along the way?
- Changing Habits
- Meaning of Done
- Quality First Mindset
- Coaching Through Pair Programming
- Deliberate Practice
- Have a shared team culture and a process to change it
- Creating Critical Mass
- All Team Product Owning
54

55. Principles9

56. Clean Code
A set of rules, principles and heuristics easy to
understand by all the team.
Understandability makes change, extension and
maintenance possible.
56

57. The 4 Rules of Simple
Design
57
Kent Beck

58. SOLID
1. Single Responsibility Principle (SRP)
2. Open Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)
58

59. Hexagonal
Architecture
(Ports &
Adapters)
10

60. How does good design looks
like?
A good design must support evolution
A good design must be testable
60

61. Ports & Adapters: Goal
“Allow an application to equally be driven by users,
programs, automated test or batch scripts, and to be
developed and tested in isolation from its eventual
run-time devices and databases.”
Alistair Cockburn
61

62. Ports & Adapters
Model is isolated, connected to
external world through interfaces
(ports) .
Those interfaces are
implemented in objects
(adapters) that translate the
application domain concepts
onto an appropriate technical
implementation.
62

63. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with a communications satellite
sendToSatellite(command);
}
protected void sendToSatellite(Command command) {
SpaceSatellite satellite = SatelliteFactory.createABigOne();
satellite.sendCommand(command);
}
}
63

64. But in the real
world?
11

65. Some experiences
- “Developers or POs, you should decide”
- New JS frameworks fans!
- Not everybody is enthusiastic with the
“learning” idea.
65

66. "Crossing the Chasm by Geoffrey Moore" by Chris Matts is licensed under CC BY 4.0

67. Comunidades de Necesidad &
Comunidades de Soluciones
Communities of Need & Community of Solutions
Antonio de la Torre
@adelatorrefoss
A different approach to Crossing the Chasm
CAS 2016 Vitoria, 1 de Noviembre de 2016

68. Bibliography
Working Effectively with Legacy Code. Michael C. Feathers
Refactoring. Martin Fowler
Refactoring (second ed.). Martin Fowler
68

69. 69
Preserve
your
business!
Thanks!
▸ Toño
▸ @adelatorrefoss

70. Credits
Special thanks to all the people who made and released these
awesome resources for free:
▸ Presentation template by SlidesCarnival
▸ Illustrations by Sergei Tikhonov
▸ Photographs by Unsplash
70