Ask HN: Codebase at my work is a complete mess, what should I do?

medium level = 2 yrs experience? with degree?

i have news for you, it’s like this at all companies.

you can’t fix it. it grew that way from the people there. you need to outnumber them 2:1 to make headway.

grin and bear it. fix what you can along the way. trust me, the next guy will consider your code garbage. no matter how good it is!

Start writing tests, change no production code. You need to understand how it works (by reverse engineering its behavior with tests you’ll learn this) and you need to verify your changes don’t accidentally change existing behavior unless the existing behavior is verifiably wrong, and hey, you may find instances of this too, but don’t start making changes until you have a suite of tests that can spot behavior changes. There are times when things that appear to be bugs are actually weird features that the business needs to function. Sometimes cruft is actually a bug fix.

Start with high level integration tests of the most critical business processes. Then, work your way down to frequently used functions/classes/modules. After the whole thing is covered you can start cleaning/repairing, and I’d suggest doing so incrementally/as you’re adding new other features (make sure all new features come with tests).

Not a large one.

There's a lot of good advice here, but I'll add one thing. Learn the codebase really really well. Figure out where the seriously bad problems are. Figure out why the codebase is this bad, ideally from the original developers (not in an accusatory fashion, try to frame it as learning from them). Figure out the context of the bad code, otherwise you might end up repeating it. Write up notes and sketches and plans of the bad code.

Then, isolate a section that is practically reeking. Maybe it's even so bad that it's leaked into the user experience. It has to be a super small part of the codebase though. Plan out the refactor, making sure to make it backwards compatible (that means no regressions, no changes to internal interfaces, etc.). Start the refactor, then when you reach about the 70% mark (which will be more like the 30% mark considering regressions and stuff), try to pitch the refactor. But don't pitch it as a refactor. Figure out any problem that the user or manager is having, whether it's slowness, crashing, etc. and then slide in your refactor as the solution. Like hiding spinach in brownies. If there aren't any problems, well, then maybe the codebase isn't that bad.

And remember, 50% good code and 100% done is better than 100% good code and 50% finished when it comes to refactors.

Been through this in one of the largest car dealer companies in the world. Get them to buy third party components and slowly replace existing ones. Implement new features inside new, bugless, tested environments. Try moving sql to procedures and table functions. Add missing features like udp syslog logging, CI/CD, etc. That will increase developer happiness.