Most of the devs are aspired to learn cutting-edge technologies and develop new, innovative products cause it's fun and adds a lot of value, keeping them excited and inspired.
In reality, tho, the vast majority of the open roles are often seeking devs to maintain their monster-size code-bases often written in outdated frameworks to fix bugs while avoiding damage to major dependencies.
How do you keep motivating yourself to deal with continuous legacy projects? Or do you try to avoid them at all costs?
Oldest comments (27)
either avoid or convince them to rewrite with something modern and maintainable. life's too short to wreck my brain with someone else's choices they made 10yrs ago π
I was in this situation not long ago, with a homemade framework with no documentation, a lot of variable abreviatated names (like $v, $d, $c) and method, no autoload (lot of require) and other old stuff.
What i did was just to dive into it. Even if i didn't like it and i was often irked at how the framework was made. It get better the longer you are in it, you also learn a lot about the language in general (php in my case), and you should and should NOT code.
My approach is usually divided into two: first I start to decipher the code like an archeologist, with a lot of WTFs and WHYs. Then, when I realize that the project is a total mess, I cry a lot until I end up with a fix that doesn't break all codebase.
My approach is to just make necessary changes and prays it does not break anything (literally). There's even a bunch of files with 6k line of code and everybody relies on that and since the old devs have resigned, we're just basically coding while hoping for the best. Right now we're in the midst of migrating all the important features so hopefully we can finally shutdown the legacy system.
The stallion coder doesn't deal with legacy code. I rewrite all of them every year.
Dependants? It's your problem. I gave you 30-day notice on deprecations, and then it's removed. You are supposed to rewrite dependant code every year, too.
When I started working with a huge legacy codebase, it was very normal to spend an entire day just reading the code and trying to understand the flow. A year later, Iβve gotten a lot better at it, but sometimes I still find myself dreading to make big changes to the pile of spaghetti code that might break something or everything.
"an entire day" β½
I've spent weeks inventorying code (while also working on new features, granted)
Top-down coding lost its cachet in the '80s, but it's the best way to avoid creating "legacy code": instead of a big mess of spaghetti, at worst one makes lots of little bowls of macaroni, which one can refactor individually
At first time, it looks awful for me.
After above times, I try to improve them about reliability, flexibility and scalability.
I picked up a project two years ago as a freelancer. An iOS and Android native app. Documentation was non existent, previous devs could not be contacted. Problem was: We needed to immediately start releasing updates. My best friend during this time was the debugger.
In the end I convinced my client to rebuild the entire app in react-native and maintain the old code until the new app was ready.
I do not generally avoid legacy applications, but I think it is important to be honest with your customer. If the code and documentation is really bad and beyond repair/maintenance, I try to convince him of the benefits of starting (at least in part) from scratch.
In my experience, trying to patch around broken projects will never make your customer happy, frustrate you as a developer and ultimately be more expensive in the long run.
This is well put ππ
Look at those lines and lines of code inside for loops and no try catch till I reach a point where I use a punching bag to relieve all the anger and then start to think about ways like caching, splitting into services, using linq and then when you present all the finding and improvement you manager replies saying we would not get the approvals or its to risky. This is happening in one of the big 4s and killing urself is the only way out
Some comments may only be visible to logged-in visitors. Sign in to view all comments.