What's the worst codebase you've ever worked on? You know the kind I'm talking about. A huge lumping monolith of spaghetti with barely any tests, class hierarchies a mile deep, and a list of dependencies that can make a grown man weep. Written by a self proclaimed "genius" 15 years ago with junior devs patching features on top of it since. What's your story? How did you deal with that mess? Are you still on that team? |
The problem was that making changes on all factories required making changes in code in 5 codebases, and it was impossible to merge them into one because of subtle differences how the production lines were working. Also it was impossible to run this software locally, so only tests you could do on live production environment. Imagine testing your software, there is a bug, and you just wasted 2 tones of concrete...
My solution for this problem was making a checklist of all the things that need to be changed and checked before changing, codebase by codebase. Also keeping the changes in SVN helped a lot for implementation reference. Good commit messages and comments in code were essential not to drown in this mess.
In the end, I hired an employee, taught him the ropes and "sold him" to this company. He works there till now and does exactly the same thing (8 years and counting) ;)
Nothing wrong with this thread as far as I can tell, but, if I could summin supernatural beings with a mere mention, I'd call @dang .
Codebases are kinda like cars. What's a "good" car? Is it a car with a large trunk and comfortable driving experience, or is it a car which does 0-60 in 2 seconds? The answer depends a lot on what you want to do and what your preferences are.
There are obviously objectively bad codebases, but I think a lot of codebases I considered bad in the past were just built in a way I wasn't comfortable with or was optimising for something that it didn't appreciate at the time. Ever noticed how it's common for JS devs to hate Java projects, and for Java devs to hate JS projects? I think that's probably because they're optimising for different things and are used to working on codebases which incorporate those priorities.
But to answer your actual question, my core languages are PHP, Node and Java. By far the worst codebases I've worked on have been the Java ones because they tend to both be larger, older (full of legacy code) and more likely to be over-engineered. Crappy code in a PHP project is probably more common, but generally you can just strip it out and refactor without much consequence. In Java projects everything tend to be much more interconnected which makes refactoring difficult.
Age of a project, the number of short-term contractors and junior devs on the project, and a lack of high-level architectural discussions within a team tend to be the largest collating factors to a bad codebases in my experience.
They wanted to modernize their source code though. The result was a mixed mess of old C++ (pre-98), and assembly language. Like C++ classes with assembly language inside.
Also I had to teach them how to use Mercurial, thank god I didn't went with git (which I love) or it would have been way worse. I also wrote a lot of Python packages to handle the dependencies, clean code, and do everything to ease their job.
They were fun guys though and we had good times working together, I miss them somehow.
Over 50,000 procedural PHP5 files under zero revision control, without a non-production environment to test on, power one of the largest "grey area" e-commerce platforms currently online. The type of place where you can resell medical pills which claim to cure every illness under the sun.
"index_old_test1.php" etc. was normal and the codebase went back to 2005.
It runs (unless things have changed... which is unlikely) on 3 physical servers - HAProxy, Apache2 and MySQL5.
No backup or failover/redundancy.
Oh, and more PII / GDPR data than you can shake a stick at - unencrypted at rest and in transit between app & database servers.
Everyone shared the same root password (no SSH keys!) with boxes listening on 22 via public IPs.
Thankfully the contract was a short albeit terrifying experience.
Never seen anything so bad in nearly 20yrs of tech.
I think part of me would actually kinda enjoy this experience just for the nostalgia factor. I got surprisingly good at making changes in prod without causing downtime...
I had to write a shared components library and yeah.. it went about as well as you can imagine. Thankfully the senior devs would tear my code apart and over the six or eight months I owned that project I learned a ton and made a v2 that was far better. From what I know it was used for another couple years since I left.
So yeah I’d say the worst code based I’ve worked on were my own code. The next project I was team lead on a login service. Again I had no idea what I was doing and someone gave me clean code and clean architecture books. Those changed my attitude a lot too.
It’s fun building code now, because any time I deal with old legacy code or so called spaghetti I understand why it’s that way and accept it. I write clean interface on top of it and within a couple months that old system is totally replaced by something that works well and is easy to test.
There were 8 layers of abstract classes with only one concrete class at the bottom.
There was a whole half-assed quasi-functional almost-but-not-quite-turing-complete language in XML for parsing legacy binary files.
There were unit tests, but they modified the dev DB so you needed to manually reseed it after every run (defintely no CI).
I spent months trying to refactor some of the more afwul bits. Not sure I actually made things any better.
I still shudder.
Not to detract from the obvious nightmare, but at least they dodged the "accidentally Turing complete" bullet... entirely inadvertently, I'm sure.
But honestly now I work on a typescript monolith thats moving to microservices and its probably worse than the ColdFusion code base. I'd rather work on the ColdFusion codebase.