En muchos proyectos en los que participamos, nos vemos habitualmente forzados a sacrificar nuestro compromiso con la calidad y la mantenibilidad del producto que estamos construyendo en favor del cumplimiento de plazos y/o resultados. Esto, de manera sostenida, tiene un gran impacto en la velocidad de entrega de los equipos. La falta de tests unitarios o una batería de tests unitarios mal planteada provoca que el refactor de código se vaya volviendo progresivamente más difícil y más costoso. ¿Disfrutas cuando haces un refactor de tu producto? Nunca es tarde para intentar convencer a tu negocio y poner en marcha algunas buenas prácticas que te ayudarán a reducir el código legacy transformándolo en código más mantenible. En esta charla compartiré algunos conceptos y técnicas que nos ayudarán en esta tarea, como branch by abstraction, sprout o wrap. Hablaremos también del mayor enemigo: las dependencias. Describiré con ejemplos los que deben ser nuestros mejores aliados: los tests de caracterización y las “costuras”. Y repasaré algunas técnicas básicas de refactorización que nos ayudarán en todo este proceso como extract interface o subclass & override.

1. How to deal with legacy code
And not die trying
MAD · NOV 23-24 · 2018
José San Román A. de Lara
VP of Engineering ING Bank Spain
@jsral

2. What is
legacy code?

3. Just old code?

4. Old code that
works

5. Profitable
old code

6. Profitable code
that we are
afraid to change

7. ~77% #bugs
found in production
can be detected using
unit tests
(*) Simple Testing Can Prevent Most Critical Failures: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

8. Legacy code is
profitable code
without the proper
unit tests

9. What can we do
with legacy code?

10. Do nothing

11. Rewrite

12. Incrementally
invest

13. On having a
better code

14. That should be easy to
change

15. Testable code

16. Testable and
well-tested code is
faster to change
than none

17. There’s no magic

18. There’s no magic
Just do good unit testing

19. Speed

20. Speed

Business value

21. Speed

Business value

ROI(*) ROI: Return On Investment

22. ROI
Legacy
code
(*) ROI: Return On Investment

23. Loosing speed
V 1.0 V 1.1 V 2.0 V 2.3 V 3.0
Time
Time

24. Cost of software
is the
Cost of evolving software

25. Why unit
testing?

27. Flaky tests
By
Google
(*) Source: Google’s testing blog https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

28. ~77% #bugs
found in production
can be detected using
unit tests
(*) Simple Testing Can Prevent Most Critical Failures: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf

29. Behavior
vs
Collaboration
(*) Integrated tests are a scam: https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam

30. Use stubs to simulate units
behaviors
(*) Mocks aren't stubs: https://martinfowler.com/articles/mocksArentStubs.html

31. Use mocks to simulate units
collaboration
(*) Mocks aren't stubs: https://martinfowler.com/articles/mocksArentStubs.html

32. Same confidence

33. Lower maintenance
costs

34. How to improve
old code?

35. If you choose
to rewrite

36. This is not your talk

38. Just kiddING ;-)

39. @ least, I’ll give you a recipe

40. Branch by abstraction
(*) Branch by abstraction: https://martinfowler.com/bliki/BranchByAbstraction.html

41. Technique for making
large-scale change
to software systems in
a gradual way

42. Client code
Client code
Client code
Supplier code

43. Client code
Client code
Client code
Supplier code
Abstraction
layer

44. Client code
Client code
Client code
Supplier code
Abstraction
layer
New Supplier
code

45. Client code
Client code
Client code
Supplier code
Abstraction
layer
New Supplier
code

46. Client code
Client code
Client code
Supplier code
Abstraction
layer
New Supplier
code

47. Client code
Client code
Client code
Supplier code
Abstraction
layer
New Supplier
code

48. Client code
Client code
Client code
Abstraction
layer
New Supplier
code

49. If you choose to
incrementally invest

50. Every time we make a
change,
code must get better

51. For new code 
Sprouts
Wraps

52. For new code 
Sprouts
Wraps
For old code 
Surgical &
incremental
refactor

53. For new code 
Sprouts
Wraps
For old code 
Surgical &
incremental
refactor

54. New code will be
formulated as new
methods or classes

55. Sprouts
(*) Working Effectively with Legacy Code by Michael C. Feathers

56. public class RiskEngine {
public static int ONE_MONTH = 30;
public static int ONE_WEEK = 7;
public TransactionRiskLevel validate(Transaction t) {
TransactionRiskLevel level = TransactionRiskLevel.LOW;
DBConnection connection = DBConnection.getConnection();
PhoneRepository phoneRepository = new PhoneRepository(connection);
PhoneNumber phone = phoneRepository.findPhoneNumberByCustomerId(t.getCustomerId());
if( phone == null ) {
return TransactionRiskLevel.NEEDACALL;
}
else if( phone.hasBeenModified(ONE_WEEK) ) {
level = TransactionRiskLevel.HIGH;
}
else if( phone.hasBeenModified(ONE_MONTH) ) {
level = TransactionRiskLevel.MEDIUM;
}
return level;
}
}

57. public class RiskEngine {
[...]
public TransactionRiskLevel validate(Transaction t) {
[...]
TransactionRiskLevel riskLevelByAmount = getRiskLevelByAmmount(t);
if( riskLevelByAmount.compareTo(level) > 0) { level = riskLevelByAmount; }
return level;
}
public TransactionRiskLevel getRiskLevelByAmmount(Transaction t) {
TransactionRiskLevel level = TransactionRiskLevel.LOW;
int amount = t.getAmount();
if(amount >= MAX_AMOUNT) {
level = TransactionRiskLevel.HIGH;
} else if (amount >= MIN_AMOUNT) {
level = TransactionRiskLevel.MEDIUM;
}
return level;
}
}

58. public class RiskEngineTests {
@Test
public void transactionRiskLevelIsMediumForTransactionsWithMinAmount()
{
RiskEngine riskEngine = new RiskEngine();
Transaction t = new TransactionBuilder().withAmount(RiskEngine.MIN_AMOUNT).build();
TransactionRiskLevel level = riskEngine. getRiskLevelByAmmount(Transaction (t);
assertEquals(level, TransactionRiskLevel.MEDIUM);
}
}

59. Wraps
(*) Working Effectively with Legacy Code by Michael C. Feathers

60. Decorator pattern
(*) Decorator pattern: https://en.wikipedia.org/wiki/Decorator_pattern

61. RiskEngine
+ validate()
BasicRiskEngine
+ validate()
RiskEngineDecorator
+ validate()
AmountRiskEngine
+ validate()
+ riskLevelByAmmount

62. public abstract class RiskEngineDecorator implements RiskEngine
{
private RiskEngine engine;
public RiskEngineDecorator(RiskEngine engine)
{
this.engine = engine;
}
public TransactionRiskLevel validate(Transaction t)
{
TransactionRiskLevel level = TransactionRiskLevel.LOW;
if( engine != null ) {
level = engine.validate(t);
}
return level;
}
}

63. public class AmountRiskEngine extends RiskEngineDecorator {
[...]
@Override
public TransactionRiskLevel validate(Transaction t) {
TransactionRiskLevel previousRiskLevel = super.validate(t);
TransactionRiskLevel riskLevelByAmount = getRiskLevelByAmmount(t);
if( previousRiskLevel.compareTo(riskLevelByAmount) > 0) {
return previousRiskLevel;
}
else {
return riskLevelByAmount;
}
}
private TransactionRiskLevel getRiskLevelByAmmount(Transaction t) {
TransactionRiskLevel level = TransactionRiskLevel.LOW;
int amount = t.getAmount();
if(amount >= MAX_AMOUNT) { level = TransactionRiskLevel.HIGH; }
else if (amount >= MIN_AMOUNT) { level = TransactionRiskLevel.MEDIUM; }
return level;
}
}

64. public class RiskEngineTests {
@Test
public void transactionRiskLevelIsMediumForTransactionsWithMinAmount()
{
AmountRiskEngine riskEngine = new AmountRiskEngine();
Transaction t = new TransactionBuilder().withAmount(AmountRiskEngine.MIN_AMOUNT).build();
TransactionRiskLevel level = riskEngine.validate(t);
assertEquals(level, TransactionRiskLevel.MEDIUM);
}
}

65. For new code 
Sprouts
Wraps
For old code 
Surgical &
incremental
refactor

66. Surgical & incremental
refactor

67. Preserving signatures

68. To minimize
any chances of
errors

69. Understanding
the code

70. The better way to
understand code is
running it

71. Characterization test
(*) Characterization tests: https://en.wikipedia.org/wiki/Characterization_test

72. Describe the actual
behaviour of an existing
piece of software

73. Dependencies

74. Hidden
dependencies

75. A piece of code is tightly
coupled to their
collaborators

76. Seams
(*) Working Effectively with Legacy Code by Michael C. Feathers

77. Place in your program
where you can
alter behaviour without
editing that place

78. Extract & Override

79. Identify
hidden dependency

80. Hard-coded
initialization

81. Extract dependency
creation in a
factory method

82. Create a testing subclass
and override
the factory method

83. public class RiskEngine {
[...]
public TransactionRiskLevel validate(Transaction t) {
TransactionRiskLevel level = TransactionRiskLevel.LOW;
DBConnection connection = DBConnection.getConnection();
PhoneRepository phoneRepository = new PhoneRepository(connection);
PhoneNumber phone = phoneRepository.findPhoneNumberByCustomerId(t.getCustomerId());
[...]
return level;
}
}

84. public class RiskEngine {
[...]
protected PhoneRepository getPhoneRepository()
{
DBConnection connection = DBConnection.getConnection();
PhoneRepository phoneRepository = new PhoneRepository(connection);
return phoneRepository;
}
public TransactionRiskLevel validate(Transaction t) {
TransactionRiskLevel level = TransactionRiskLevel.LOW;
PhoneRepository phoneRepository = getPhoneRepository();
PhoneNumber phone = phoneRepository.findPhoneNumberByCustomerId(t.getCustomerId());
[...]
return level;
}
}

85. public class RiskEngineForTesting extends RiskEngine {
protected PhoneRepository phoneRepository;
private RiskEngineForTesting()
{
phoneRepository = mock(PhoneRepository.class);
}
@Override
protected PhoneRepository getPhoneRepository() {
return phoneRepository;
}
public static RiskEngine forCustomerThatHasModifiedPhoneNumber(int days) {
PhoneNumber phoneNumber = new PhoneNumberBuilder().withLastModified(days).build();
RiskEngineForTesting engine = new RiskEngineForTesting();
when(engine.phoneRepository.findPhoneNumberByCustomerId(anyLong())).thenReturn(phoneNumber);
return engine;
}
}

86. public class RiskEngineTests {
@Test
public void transactionRiskLevelIsMediumForCustomerThatHasModifiedPhoneNumberLastMonth()
{
RiskEngine riskEngine =
RiskEngineForTesting.forCustomerThatHasModifiedPhoneNumber(RiskEngine.ONE_MONTH);
Transaction t = new TransactionBuilder().build();
TransactionRiskLevel level = riskEngine.validate(t);
assertEquals(level.ordinal(), TransactionRiskLevel.MEDIUM);
}
}

87. Combine this
approach
all over your
codebase

88. You must
enjoy refactoring
your code

89. Takeaways

90. Invest in your
legacy code

91. To speedup

92. To increase or
maintain ROI
(*) ROI: Return On Investment

93. Every time we make a
change,
code must get better

94. Surgical
refactor
Characterization
tests
Incremental
refactor
Unit
tests
Test first
Sprouts or
Wraps
Incremental
refactor
Unit
tests

95. There’s no magic

96. Good unit tests

97. Good code

99. Thx
;-)