Talk given 2019.11.23 at CAS 2019 Madrid https://cas2019.agile-spain.org/ https://cas2019.agile-spain.org/agenda/ 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
(Legacy code came to stay)Toño de la Torre
@adelatorrefoss
Software Crafters

3. ¿What is legacy
code?
1
@adelatorrefoss @codesaidev

4. 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”.
4@adelatorrefoss @codesaidev

5. “ To me, legacy code is
simply code without tests.
Michael C. Feathers
5@adelatorrefoss @codesaidev

6. 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.”
6@adelatorrefoss @codesaidev

7. confidence
Being able to confidently
make changes in any code
base.
7@adelatorrefoss @codesaidev

8. What are
legacy
projects?
2
@adelatorrefoss @codesaidev

9. Code that is hard to
change but still
makes money
@adelatorrefoss @codesaidev

10. source
+
team
10@adelatorrefoss @codesaidev

11. Team3
@adelatorrefoss @codesaidev

12. Why is it so
hard for teams?
@adelatorrefoss @codesaidev

13. frustration
13@adelatorrefoss @codesaidev

14. “
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
14@adelatorrefoss @codesaidev

15. retaining talent
is hard in
legacy projects
@adelatorrefoss @codesaidev

16. 4 Previously, on...
@adelatorrefoss @codesaidev

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 does code
becomes so hard?
17@adelatorrefoss @codesaidev

18. How to write good code?
(option A)
Managers or Technical Leads set a bunch of rules and/or
define an architecture.
It is mandatory that everyone follow these rules.
Someone, usually the Tech Lead, reviews all code (via
merge request) to check if everybody is following the
“agreement”.
18@adelatorrefoss @codesaidev

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

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

21. Smell the code5
@adelatorrefoss @codesaidev

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

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
@adelatorrefoss @codesaidev

24. How to
technically face
legacy code?
6
@adelatorrefoss @codesaidev

25. Reasons to change
software
1. Adding a feature
2. Fixing a bug
3. Improving the design of the system
4. Optimizing resource usage
Change behavior & Preserve behavior
25@adelatorrefoss @codesaidev

26. Edit and
Pray
vs
Cover and
Modify
26@adelatorrefoss @codesaidev

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

28. “
28@adelatorrefoss @codesaidev

29. 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.
29@adelatorrefoss @codesaidev

30. Software
Economics
30@adelatorrefoss @codesaidev

31. Dependency
problem
Much legacy code work involves breaking
dependencies so that change can be
easier.
7
@adelatorrefoss @codesaidev

32. 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.
32@adelatorrefoss @codesaidev

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

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

35. Show me the
code
8
@adelatorrefoss @codesaidev

36. A classic dependency
@adelatorrefoss @codesaidev

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

38. 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);
}
}
38@adelatorrefoss @codesaidev

39. A more complicated dependency
39@adelatorrefoss @codesaidev

40. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with vehicle
SpaceVehicle vehicle = VehicleFactory.createAComplicatedOne();
vehicle.sendCommand(command);
}
}
40@adelatorrefoss @codesaidev

41. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with vehicle
sendToVehicle(command);
}
protected void sendToVehicle(Command command) {
SpaceVehicle vehicle = VehicleFactory.createABigOne();
vehicle.sendCommand(command);
}
}
41@adelatorrefoss @codesaidev

42. class MarsRoverTest {
class MarsRoverSpy extends MarsRover {
Command commandSent;
@Override
protected void sendToVehicle(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);
}
}
42@adelatorrefoss @codesaidev

43. Heuristics &
Strategies
9
@adelatorrefoss @codesaidev

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

45. The 4 Rules of Simple
Design
45
Kent Beck
@adelatorrefoss @codesaidev

46. 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)
46@adelatorrefoss @codesaidev

47. Hexagonal
Architecture
(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.
47@adelatorrefoss @codesaidev

48. class MarsRover {
void move(int x, int y) {
Command command = new Command("move", x, y);
// Connect with a communications vehicle
sendToVehicle(command);
}
protected void sendToVehicle(Command command) {
SpaceVehicle vehicle = VehicleFactory.createABigOne();
vehicle.sendCommand(command);
}
}
48@adelatorrefoss @codesaidev

49. Team again10
@adelatorrefoss @codesaidev

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

51. How to learn along the way?
51

52. How to learn along the way?
Training in Technical skills
- Code smells, TDD, Refactoring, Design, Working with
Legacy, ...
52@adelatorrefoss @codesaidev

53. Knowledge Diffusion
- Pair programming
- Mob programming
- On boarding process
- Technical concerns process
How to learn along the way?
Crystallizing Knowledge
53

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

55. How to learn along the way?
55
Knowledge
Diffusion
&
Crystallizing
Training in
Technical
skills
Changing Habits All Team Product
Owning

56. Bibliography
Working Effectively with Legacy Code. Michael C. Feathers
Refactoring. Martin Fowler
Refactoring (second ed.). Martin Fowler
56@adelatorrefoss @codesaidev

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

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