How to navigate legacy code?
Posted by The-Ball-23@reddit | ExperiencedDevs | View on Reddit | 28 comments
I have quiet some experience programming but I have mostly built application from scratch and that too only in a microservice architecture. I recently joined a new org and they have a monolith legacy code (\~15 years) on which they develop and refactor and another microservice (\~6 years). I can find my way through the microservice part as it is written in the language I am familiar with (GoLang) and I have worked in such a system earlier. But how do I find my way through on the monolith part (written in PHP) ? Are there any steps to it or any tried and tested approach that I can follow?
Hot-Profession4091@reddit
Pick up “Working Effectively with Legacy Code” by Michael Feathers.
The topic takes an entire book to cover and, luckily, Michael wrote a great one.
wwww4all@reddit
Learn basics of whatever version PHP, then learn to read the code.
There's no magic lamp that will tell you some secret key word that will make legacy code not legacy code.
The-Ball-23@reddit (OP)
Thanks, this is the approach I was thinking of along with adding unit tests. Since there is no test coverage for the monolith
Gunningagap77@reddit
If it wasn't built with unit tests, do not add them. No good will come from it, and you will only burn yourself out. Learn about the PHP version it was written in, and the most common issues that arise from upgrading to the latest PHP version. Far better use of your time, as you'll learn a hell of a lot about how the legacy code works when you're fixing all the errors upgrading will cause. Good luck, and god speed. Barring that, here's hoping your next job pans out a little better.
Historical-Arm-32@reddit
I second this. Code has to be written with tests in mind and be designed to be testable from Day 1. And you don't want to pave the way for some scrum master accidentally baking write unit tests for uncovered code into a Definition of Done for a piece of legacy code.
troxy@reddit
Unit testing is the secret key word, in my opinion.
iama_regularguy@reddit
Unit testing, feature flags and strangler pattern all day
jaskij@reddit
One thing I found immensely helpful when navigating unknown C codebases was using Doxygen to generate call and callee graphs. AFAIK it does also support PHP. Play with the options a little, you want to enable most of the graphing stuff.
AdmiralAdama99@reddit
Can confirm. Doxygen does support PHP.
BanaTibor@reddit
If there is nobody to give you that walk through that is a tough cookie. In that case you have to sit down, get a notebook (a paper one) ans have to read a shit ton of code and map the app.
In my experience I have found that I can learn anything much faster if I know the underlying concepts, frameworks, build tools, code bases, etc.
wildmonkeymind@reddit
Give “Working Effectively With Legacy Code” a read. Oldie but goodie.
BanaTibor@reddit
It is about refactoring and bringing untested code under a test suite.
onar@reddit
One of my absolute favorites!
I tend to like programming books that give advice beyond code-specifics. They good ones age very well!
The-Ball-23@reddit (OP)
Definitely gonna give this a try
loumf@reddit
TL;DR: add tests. But the book will explain how to do that to code that is fundamentally untestable.
ivoryavoidance@reddit
First have an understanding of the api does. Start from the routes obviously. How to get the routes, are in use? API gateway logs.
Since we have quite good editor integrations, add a debug break point at the start and follow it. If the logging is done well, then you can follow the steps as well.
Since you have some programming experience, before going into the syntactical details, see if you can overall get a gist of what it is, from the function names comments etc.
If it’s only the codebase then it’s a bit easier than if you were trying to understand a connected system overall with async stuff. If it’s not documented. But that’s overall how I approach it when I have time. Docs, Logs debugs English intuition/general understanding, syntax and framework/language convention. And then finally ask for help.
The-Ball-23@reddit (OP)
So that is the thing. I am already proceeding with the first 3 steps you mentioned but since there is little to no documentation and people who worked on it are long gone I am facing issues. Some people in the comments did suggest some ways to approach this problem, I think I am gonna try them. Especially, reading through the book.
ivoryavoidance@reddit
Cool cool cool . Were there tickets or something like that? Or atleast commit histories. Maybe you could leverage LLM to make sense of the changes and build a story :P .
Little_Yesterday_820@reddit
I’ve done a lot of legacy stuff. This is my guiding principle:
“Do not remove a fence until you know why it was put up in the first place.” (Chesterton’s Fence)
It may be old, crusty, ugly, ridiculous code, but obviously it still works. Never break working code for the sake of something new and shiny.
Obviously there are situations where it’s something that absolutely must change (security, compliance, etc). Evaluate all your options and consider all the things that can go wrong. Don’t be afraid to ask for help, you may find some old grognard that knows exactly what information you need.
The-Ball-23@reddit (OP)
Thanks, note taken!
ObjectiveConsistent2@reddit
git grep
GhostMan240@reddit
You just have to kind of do it. It may seem impossible at first but the more you look at the code the more the pieces will start to fit together. Add break points or debug if you want to know more about the timing things run at, how dissonant pieces of code affect each other, etc. It’s a skill just like any other, the more you do it the better you’ll get.
WhiskyStandard@reddit
Profile common workflows. You’ll be able to see what’s high level, what’s low level, and what’s important. And if no one’s ever done it before you’re likely to find a 5-10% performance improvement that’ll make you look like a genius.
Also run a hotspot analysis on the repo. Code that has changed a lot probably has some stories. Adam Tornhill’s Code Maat has that and many other analyses you can run on a codebase. He also has some great books about what you can learn from the codebase and its repo.
mcfg@reddit
Here's two guys discussing Michael Feathers Book, the book saved me, this youtube video would be a good place to get a quick overview:
ps://www.youtube.com/watch?v=PjBlBq1aRmE
i_exaggerated@reddit
Great podcast. They had the author on in a later episode.
PhyPsyLife@reddit
If you and your team plan to touch some of the legacy code to improve things, I recommend these 2 techniques: "Live Legacy Code Refactoring with the Golden Master" by Philippe Bourgau
https://www.youtube.com/watch?v=9HmVrfkzm9I
lucid00000@reddit
Depends on the language/tooling/design of the system but I've found setting up breakpoints liberally and stepping through code line by line as you exercise whatever part of the system you're working on to be by far the best way to get up to speed.
Also, if you find yourself sifting thru the same bit of code for a long ages trying to figure out what the hell it's doing or why it exists, be a good Boy Scout and leave some comments/docs for the next person who has to deal with it (could be you in 6 months).
x2network@reddit
X debug.. get a pot of coffee and start stepping 🤣😜👍