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.

Refactoring: the good, the bad and the ugly.

8 views

Published on

At some point every developer has to deal with legacy code. In this talk we will go through the technical terms related to legacy applicaton, how to move the project from the stone age to the future and getting your client into the refactoring mindset. We'll also go through some actual refactorings and useful resources.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Refactoring: the good, the bad and the ugly.

  1. 1. REFACTORING THE GOOD, THE BAD AND THE UGLY Jeroen Thora | @jeroenthora acrobat
  2. 2. JEROEN THORA ▸ Backend developer @ Kunstmaan | Accenture interactive ▸ Opensource contributor and maintainer ▸ Knplabs/php-github-api, Bernard, Bootstrap- datepicker, ...
  3. 3. WHAT WE WILL TALK ABOUT ▸ Introduction to legacy code ▸ Steps to refactor ▸ Code smells (and solutions) ▸ Tools & resources ▸ Summary
  4. 4. LEGACY CODE
  5. 5. HOW YOU FEEL
  6. 6. TECHNICAL DEBT ▸ bit by bit the code is corrupted ▸ Accumulation of technical debts ▸ Any healthy project will collect some technical debt ▸ Forced to pay the debt ▸ Paying this debt is called refactoring
  7. 7. REFACTORING "It's a process of restructuring existing code, altering it's internal structure without changing it's external behaviour"
  8. 8. BENEFITS - CODE ▸ Will look clean ▸ Easy to understand ▸ Easy to change / maintain
  9. 9. BENEFITS - YOU ▸ Will code faster ▸ Spot bugs easier ▸ More confident to develop the code
  10. 10. CONVINCING YOUR CLIENT/BOSS ▸ Explain what technical debt means ▸ Use actual examples like cost to on-board team members, development of features, ... ▸ Integrate cost in the offer ▸ Refactor with clear short-term goals in mind ▸ Point out that you want the best for your customer ONCE OWNER CONVINCED
 FREEDOM TO MOVE THE PROJECT IN THE RIGHT DIRECTION.
  11. 11. WARNINGS (DON'TS) ▸ The big red button switch (Green field approach) ▸ Migration of data ▸ Mistakes old and new ▸ Keeping up with the business GENERAL ADVICE
 DON'T START OVER. IMPROVE WHAT YOU HAVE! 
  12. 12. HOW TO START ▸ Make problems visible ▸ Monitor your environment ▸ Visualise errors ▸ Sentry / grafana dashboard / ...
  13. 13. *insert screenshot sentry + grafana dashboard*
  14. 14. TEAM ▸ The boyscout rule - Robert C. Martin (Uncle Bob) ▸ "Leaving the camping ground cleaner than you found it" ▸ You have to care ▸ The whole team has to care ▸ Discipline ▸ Keep taking small steps ▸ Small victories generate momentum
  15. 15. BALL OF MUD ▸ Isolate the messy part ▸ Push dependencies out from the outside to the core ▸ Controllers -> services -> libraries -> ... ▸ Making code  self-contained ▸ Thus making it testable
  16. 16. BALL OF MUD ▸ Small iterations ▸ Easy to detect regressions ▸ Almost risk free refactoring ▸ Together with tests
  17. 17. BUILD CONFIDENCE ▸ High level tests of business critical logic ▸ Checkout flow, member registration, .... ▸ Unit tests of small components ▸ Clear input and a clear output. ▸ Make sure that bit of code keeps behaving as expected. GENERAL ADVICE
 DON'T (TRY TO) TEST EVERYTHING.
  18. 18. YOU (OR MY REFLECTIONS) ▸ Becoming a better developer ▸ Learning to recognise bad code ▸ Back to basics ▸ People are generating shiny new legacy constantly ▸ Fun and rewarding
  19. 19. CODE SMELLS ▸ Bloaters ▸ Unneeded stuff ▸ Change preventers ▸ Complex if statements ▸ Bad naming IF IT STINKS, CHANGE IT! An indication of a deeper problem in the system
  20. 20. BLOATERS Long method Long parameter list Large class Image source: refactoring.guru
  21. 21. BLOATERS Long method Long parameter list Large class ▸ Move logic to private methods ▸ Group common logic ▸ Keep class hierarchy small ▸ Avoid classes with same behaviour ▸ Enforce single responsibility principle ▸ Group in object ▸ Remove method call result params
  22. 22. UNNEEDED STUFF Dead code Useless comments Future code 
 not in use Image source: refactoring.guru
  23. 23. CHANGE PREVENTERS Shotgun Surgery Image source: refactoring.guru
  24. 24. CHANGE PREVENTERS ▸ Avoid classes with same behaviour ▸ Move duplicated code ▸ Don't over engineer Shotgun Surgery
  25. 25. COMPLEX IF-STATEMENTS
  26. 26. BAD NAMING
  27. 27. RESOURCES / TOOLS ▸ Phpmd ▸ Phpcpd ▸ Scrutinizer ▸ Php-cs-fixer ▸ Php Inspections EA (ultimate)
  28. 28. RESOURCES / TOOLS https://refactoring.guru
  29. 29. SUMMARY ▸ Live by the boyscout rule ▸ Get your boss/client in the refactoring mindset ▸ Small steps at a time ▸ Monitor your application ▸ To improve yourself, improve your code
  30. 30. THANKS! QUESTIONS? @jeroenthora acrobat

×