Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Brutal refactoring, lying code, the Churn, and other emotional stories from Legacy Land

250 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Brutal refactoring, lying code, the Churn, and other emotional stories from Legacy Land

  1. 1. Brutal Refactoring Lying Code The Churn (and other emotional stories from) Legacy Land!
  2. 2. The big questions What can I know?
  3. 3. The big questions What should I do?
  4. 4. The big questions What may I hope?
  5. 5. ( °□°╯ )╯︵ ┻━┻
  6. 6. (Maintaining) legacy code is depressing
  7. 7. “Technical debt”
  8. 8. “Continuous improvement”
  9. 9. What can I know?
  10. 10. When using PHP: not much
  11. 11. Dynamic types /** * @return mixed */
  12. 12. No compiler if (!'a') { // ... }
  13. 13. No compiler $a = 'a'; if ($a === 'a') { // ... }
  14. 14. No compiler if (!$a === false) { // ... }
  15. 15. No compiler if (false === !$a) { // ... }
  16. 16. Domain knowledge has left the building if ($product->isGrewBilly() && $customer->prefersPayTotum()) { $this->emailManager->sendTotumBillyAnnuitySummary(); }
  17. 17. "Legacy code is code without an owner"
  18. 18. So... what should I do?
  19. 19. Read books
  20. 20. Replace a constructor argument Override a method Tamper with the class loader Use AOP ...
  21. 21. The Churn.
  22. 22. Core domain concepts
  23. 23. Scaring away Churn monsters is a lot of work too!
  24. 24. Guess: who are the monsters in your project?
  25. 25. What else... should I do?
  26. 26. Little things?
  27. 27. Weed the ground
  28. 28. Pick up the stones, then put them back
  29. 29. Look your monster in the eyes
  30. 30. “Could this go somewhere else?”
  31. 31. What may I hope?
  32. 32. How did we get here?
  33. 33. Different developers Changing landscape Bad management Bad developers
  34. 34. 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...
  35. 35. You can hope that people will do this from now on (actually, force them...)
  36. 36. The secret: most code could remain untouched
  37. 37. Change will be needed, where?
  38. 38. The framework (yes, you will switch frameworks some day!)
  39. 39. What can you do to make it easier? Don't use everything from the framework
  40. 40. What can you do to make it easier? Rely on your own interfaces and implementations
  41. 41. Consolidate
  42. 42. Not everything needs “consolidation”
  43. 43. What can you do to make it easier? Don't let the framework leak into the core
  44. 44. Again … What may I hope?
  45. 45. Naive?
  46. 46. This is it
  47. 47. Do what you can do
  48. 48. “Burnout”
  49. 49. This is it
  50. 50. How to make huge improvements to a project?
  51. 51. The big rewrite?
  52. 52. Make the change easy, then make the easy change
  53. 53. Just Do It!
  54. 54. Always keep the project in a working state

×