Living the Best Life on a Legacy Project (phpday 2022).pdf
0 likes67 views
This document discusses strategies for working with legacy code. It defines legacy code as existing code that may be old, use outdated patterns, or obsolete frameworks but is still in use. It emphasizes that legacy code is not inherently bad if it is working and providing value. When refactoring legacy code, it recommends communicating with peers and business stakeholders, limiting scope, making a plan, using tools like coding standards and tests, and automating processes. The main message is that legacy code should not always be refactored and to focus on understanding the code and business value it provides.
Living the Best Life on a Legacy Project (phpday 2022).pdf
- 1. @asgrim Living the Best Life on a Legacy Project James Titcumb phpday 2022
- 3. @asgrim So, you joined a new team.
- 4. @asgrim WTF per minute: 0
- 5. @asgrim WTF per minute: 0
- 6. @asgrim WTF per minute: 1
- 7. @asgrim WTF per minute: 3
- 8. @asgrim WTF per minute: 15
- 9. @asgrim WTF per minute: 256
- 10. @asgrim
- 14. @asgrim "Legacy" Can mean... ● Old code ● Code that uses outdated patterns ● Obsolete (but still used) ● Difficult to maintain ● Uses old frameworks / libraries ● Fragile / untouchable ● Expensive to replace
- 15. @asgrim "Legacy" Can mean... ● Old code ● Code that uses outdated patterns ● Obsolete (but still used) ● Difficult to maintain ● Uses old frameworks / libraries ● Fragile / untouchable ● Expensive to replace ● Working code ● Code that (usually) still provides VALUE ● Code written an hour ago
- 16. @asgrim "Code can be in two states: in production ...or almost useless" - Srdjan Vranac (@vranac)
- 17. @asgrim Result of Fast Iteration
- 18. @asgrim Result of Years of Stability
- 19. @asgrim "Legacy" !== "bad"
- 21. @asgrim "If it ain't broke, don't fix it" - Someone in USA, probably
- 22. @asgrim Living with Legacy Existing Code
- 23. General skills
- 29. Technical skills & approaches
- 32. @asgrim Understanding code. Review code!
- 33. @asgrim Understanding code. Try using a step debugger!
- 34. @asgrim Understanding code. Write tests to characterise the code!
- 35. @asgrim Understanding the business.
- 36. @asgrim Success factor 😊 Developer Experience + Business Value = Happiness
- 37. @asgrim Should you refactor?
- 38. @asgrim Don't refactor for tech reasons alone
- 39. @asgrim When you DO decide to refactor
- 40. @asgrim Limit your scope
- 41. @asgrim Make a plan
- 44. @asgrim
- 45. @asgrim
- 46. @asgrim Static Analysis "Whack-a-Mole"
- 48. @asgrim Starting from nothing
- 49. @asgrim Starting from something bad
- 50. @asgrim Good tests > Bad tests > No tests
- 51. @asgrim Make good testing habits
- 52. @asgrim Make all team members reviewers
- 53. @asgrim Feedback, don't "gatekeep"
- 56. @asgrim
- 57. @asgrim One approach to tackle "no tests"
- 58. @asgrim Focus on critical functionality
- 59. @asgrim Then build up day-to-day
- 60. @asgrim Limit the scope of characterisation tests
- 61. @asgrim Delete the test…?
- 62. @asgrim Make sure tests are run in CI
- 63. @asgrim
- 64. @asgrim Automate all the checks!
- 65. @asgrim To summarise... "Legacy" !== "bad" ● It's just "existing code" ● If it's in production, it usually produces VALUE How to tackle existing codebase? ● You don't always need to refactor ● Communicate - peers & business ● Produce documentation ● Learn to really READ code! ● Determine what produces VALUE (both business value + developer experience) ● Use tools to help improve code quality ● Characterise critical functionality with tests ● Build up your "test pyramid" ● Automate all the things!
- 66. Any questions? James Titcumb 🥃 @asgrim