You've started a new job. As you dig deeper into the codebase, the WTFs per minute rate rapidly increases, and you're left wondering... "Where do I start?!". In this talk, I'll draw on my own experiences of joining several different teams to help upgrade their legacy codebase. I'll show you what approaches were tried, what worked, what didn't work, and how things could've been done differently. You'll come out of this talk with some ideas of how to tackle your own codebase and make it easier to refactor.

1. @asgrim
Tips for Tackling
a Legacy Codebase
James Titcumb
ScotlandPHP 2021

2. $ whoami
James Titcumb
www.jamestitcumb.com
www.roave.com
@asgrim

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

12. @asgrim
"Legacy"

13. @asgrim
"Legacy"

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"

20. @asgrim
Refactoring

21. @asgrim
"If it ain't broke, don't fix it"
- Someone in USA, probably

22. @asgrim
How to Tackle Legacy Existing Code

23. General skills

24. @asgrim
Business Communication

25. @asgrim
Peer Communication

26. @asgrim
Agree direction

27. @asgrim
Define processes

28. @asgrim
Produce documentation

29. Technical skills & approaches

30. @asgrim
Reading code.

31. @asgrim
Understanding code.

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

42. @asgrim
Tooling

43. @asgrim
Coding standards

44. @asgrim

45. @asgrim

46. @asgrim
Static Analysis "Whack-a-Mole"

47. @asgrim
Testing

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"

54. @asgrim
Policies
"Usual" policies

55. @asgrim
Policies
"Flexible" policies

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