PHP Benelux 2019 edition Working effectively with legacy code isn’t all about creating test harnesses before refactoring algorithms. The “safety first” strategy doesn’t always apply. Not if the code you’re looking at is LYING IN YOUR FACE anyway. In this talk I’ll show you what brutal refactoring is. I’ll show you the red glowy eyes of the Churn. And I’ll hold up some big warning signs that should prevent you from producing legacy code today. Table flips allowed.

1. Brutal Refactoring
Lying Code
The Churn
(and other emotional stories from)
Legacy Land!

3. The big questions
What can I know?

4. The big questions
What should I do?

5. The big questions
What may I hope?

7. ( °□°╯ ）╯︵ ┻━┻

8. (Maintaining) legacy code is depressing

9. “Technical debt”

10. “Continuous
improvement”

11. What can I know?

12. When using PHP: not much

13. Dynamic types
/**
* @return mixed
*/

14. No compiler
if (!'a') {
// ...
}

15. No compiler
$a = 'a';
if ($a === 'a') {
// ...
}

16. No compiler
if (!$a === false) {
// ...
}

17. No compiler
if (false === !$a) {
// ...
}

18. Domain knowledge has left the building
if ($product->isGrewBilly() && $customer->prefersPayTotum()) {
$this->emailManager->sendTotumBillyAnnuitySummary();
}

19. "Legacy code is code without an owner"

20. So... what should I do?

21. Read books

26. Replace a constructor argument
Override a method
Tamper with the class loader
Use AOP
...

28. The
Churn.

31. Core domain concepts

33. Scaring away Churn monsters is a lot of
work too!

36. Guess: who are the monsters in your
project?

38. What else... should I do?

41. Little things?

42. Weed the ground

43. Pick up the stones, then put them back

44. Look your monster in the eyes

45. “Could this go somewhere else?”

46. What may I hope?

47. How did we get here?

48. Different developers
Changing landscape
Bad management
Bad developers

50. You know what to do...
●
Write tests from the start
●
Document code and architecture decisions
●
Agree on a coding style
●
Enforce a coding standard
●
Run static analysis tools
And so on...

51. You can hope that people will do this from
now on (actually, force them...)

52. The secret: most code could remain
untouched

53. Change will be needed, where?

54. The framework
(yes, you will switch frameworks some day!)

55. What can you do to make it
easier?
Don't use everything from the framework

56. What can you do to make it
easier?
Rely on your own interfaces and
implementations

57. Consolidate

58. Not everything needs “consolidation”

59. What can you do to make it
easier?
Don't let the framework leak into the core

61. Again … What may I hope?

64. Naive?

65. This is it

66. Do what you can do

68. “Burnout”

69. This is it

71. How to make huge improvements to a
project?

72. The big rewrite?

73. Make the change easy,
then make the easy change

74. Just Do It!

75. Always keep the project in a working state