Helping the team onboard on a legacy codebase
Posted by goofy_goon@reddit | ExperiencedDevs | View on Reddit | 14 comments
EM here. We inherited a repo that has been built and maintained for at least a decade now. Most of the original code owners have left the company. This is a repo that's used as a platform by multiple teams.
There are barely any code changes required in the repo anymore. No new requirements are coming in. However, we have to maintain it - we do get a few queries coming on the usage of the repo / how to use an api etc. The team is expected to understand and answer the queries.
I'm being asked to create a plan for the team to ramp on the codebase.
Of course, I can ask the team to go through the code module-by-module (basically divide and conquer) but the knowledge won't stick as they are not gonna be working on it actively. There are no active tasks / bugs that need attention.
Any thoughts or suggestions on how to approach this?
PleasantCelery2149@reddit
In a similar situation I have had success in adding better test coverage. Writing the tests is often similar to using the codebase, which they need to be able to support with.
BertRenolds@reddit
Throw cursor at it. You just need a high level understanding
Ok-Yogurt2360@reddit
Proper documentation and adding historial context information might be a start. Something becomes legacy because the world moves on while the codebase stays relatively the same. So proper historical context often helps a lot to understand the codebase. At the same time you need proper documentation if you need to relearn how it works. Also make sure that there are enough tests for when you need to change something.
But this is just my first instinct, not out of personal experience.
No_Thought_4145@reddit
> Something becomes legacy because the world moves on while the codebase stays relatively the same.
I think that is a very important comment. For me, it comes into play regarding external libraries: whether they continue to be supported in their current version, and whether they can be upgraded in response to bugs and security vulnerabilities.
You may allow technical debt to accumulate as libraries lose support or lack vulnerability patches. Are stakeholders OK with that?
Knowing how to build and test the product is key here! God help you if you don't have a sufficient test process in place already.
No_Thought_4145@reddit
My two cents:
Get clarity and stakeholder agreement on the boundaries of your team's responsibilities for the codebase, THEN let that drive your ramp-up activities.
If the product is mature, stable, supports all known needs, and is assessed as unlikely to change in the future, then focus on understanding its use and behaviours. Treat it as a black box, review documentation and tests.
Part of this is acknowledging that the team is intentionally choosing to be ignorant of things -- cuz the truth is that without regular interactions with the code, the team will be required to re-learn a lot every time a change is required.
oneMoreTiredDev@reddit
This might be a good use case for AI.
Euphoric-Neon-2054@reddit
Also getting them to manually verify the autogenerated documentation with given examples will be a fast way to understand the mission critical stuff.
funbike@reddit
To understand a single feature, sometimes I'll use a code coverage report as a map of what all was called. YMMV depending on the tool.
I start the app with coverage disabled, and right before the event (such as clicking a button or running a unit test), I'll enable coverage. For more precision, I might set a breakpoint before the problematic method call before enabling coverage. Then I'll dump to the coverage file and kill the app. I configure the report to only report covered lines, not uncovered.
Then the code coverage report is your guide to what was called during that single action. No other code will be highlighted.
cracked_egg_irl@reddit
Find some kind of old bug or issue or ticket and go and fix that. Nothing will get you to understand it better than hands-on experience
SeriousDabbler@reddit
Yeah asking the developers to document the codebase is probably a pretty good first start. Classes, modules, deployment will get them familiar with it
pl487@reddit
So there's nothing at all to be improved or fixed? The software is optimal for all use cases? I doubt it. Find some things and pass them out.
toasterding@reddit
This is what AI is for. It's not going to get it completely right. It will miss things, it will hallucinate a little bit. But it can get you 80% of the way there and give you a huge leg up on *where* to start clicking around manually to really understand what's going on.
alanbdee@reddit
I've pointed AI at projects I know and had them document it. Make sure there's no secretes in it first though. But after that, First is to gather all information you know into one place. Then get it running on a devs machine (assuming it's that type of application). From there, it's bring it up to the standards of the company. All the while, remember that at any point, it might have a critical failure that will have your whole team scrambling to figure all this out. Do it sooner rather then later. Nothing sucks more then to have to divert the whole team to figure out something that nobody knows anything about.
Internal_Outcome_182@reddit
Tell them to improve/create new feature (think what can it be) and give them 2 weeks. There is no better way to understand codebase than develop something inside. (feature might not be real or needed, won't be merged in the end)