What can I do to maintain respect for a poorly written codebase? [duplicate]

In my job I have to maintain a poorly written codebase which is both hard to understand, has tons of comments that are just plain wrong, has a bunch of weird decisionmaking going on in it and a whole lot more.

I primarily do bugfixing which ranges from finding that little comment somewhere in the code that makes some random part not work, to understanding complex circular dependencies with some kind of singleton’a’palooza going on, and occasionally I actually get to write some real code, which is when I’m the happiest. But I’m concerned about the bugfixing witch I must confess many times ends up in being sloppy patchwork because I don’t have the time or the mental fortitude to look at the horrendous code anymore.

Now the biggest problem this project has is not that I’m just a whiny guy, I’m most certainly not alone in having above mentioned sentiments about the codebase. The biggest problem is probably the cost of maintaining it… But I digress.

What I’m wondering is if there is some practices that I and my colleagues can try use to regain some respect for the codebase we’ve inherited and are working so that we don’t walk down the path of creating more code rot?

Having worked with some truly horrid C# at my first job, I’ve ran headlong into this problem. While I wound up leaving, in the time I spent with it I took the mindset of treating the code as a patient.

All code, no matter how awful, WTF-ridden, poorly-conceived, inadequately-implemented, or just plain bad was intended by its developers to solve a problem, with the tools they had at their disposal. Does that make the code good? Nope. Does that makes maintaining it less painful? Assuredly not. Of course, your question isn’t about the developer pain; its about whether you can look at this code day-in and day-out for however long you remain employed at your current shop.

To that end, when working with code, I view it as a doctor might: an entity that is exhibiting symptoms of a particular trait.

We call symptoms of intended behaviors ‘correct behavior’ most of the time…except for when the reasoning behind the behavior being ‘intended’ is bad. When this circumstance occurs, it might be helpful to pull together something that you can present to your management to explain the behavior you’re seeing, and an optimal process that would improve how the app works, and finally the minimal changeset to modify those symptoms. If all goes well, they’ll approve and let you do what a developer does best: leave code in better condition than you find it. If not? It might not be so bad, they might just have a business reason (too little time, too little money).

When I encounter symptoms of an unintended behavior, I prefer to follow whatever bug-reporting workflow is in place in my shop; it’s the quickest, most efficient way to inform your leaders of the problems besetting your app. In my first job, there were some issues we didn’t get to address for about two months due to the nature of the industry we were operating in, but not reporting it (or worse, making rogue changes) would have had far worse side-effects, which leads to still-lower respect for your code base.

Better still, try to find constructive ways to get your managers to speed up the process by which bugs are responded to (this was a problem at that first shop of mine), because the longer you know a bug is in the wild, the less your respect for the code will be at the end of the day. Morale matters!

When I see malformed code that dosen’t match standards for the language, I don’t blame the code for being malformed, but I do consider the developer who wrote it; maybe they’re not familiar with the language? (I encountered this case with a coworker who had zero programming experience, but a rich history as a manual tester; this person wrote some truly horrid copy/paste code that it took me weeks to stabilize.)

When you encounter this case, you have two options. If the developer is there and in easy access, make yourself available as a teaching resource; you can influence this person to write code to the standards of your language and your shop. Help them be a better developer, chances are they’re having a difficult time, but are putting on a tough face and grimacing through it just like you. Better still, you can sleep easier at night knowing that the volumes of poor code will be decreasing over time, which is always welcome.

If the person isn’t in easy access, or has already left, when an excuse to revise the code appears in a positive, low-risk fashion, take it. You’re doing your organization a favor by being the change you want to create.

If in a few weeks you’ve tried all of this and still seen no improvements to your own consideration of your codebase, and to others’ treatment of it, there’s nothing for it: you shouldn’t support something you hate, as you’ll do it sub-par as to make all the symptoms I’ve just talked about worse. But, before you start chatting up that recruiter, make absolutely sure you’ve exhausted every option to improve that codebase, and to get your coworkers to do the same. I would imagine if you’re cringing in this much pain, this can’t be pleasurable to them, either!

Sometimes you have to understand these things in the context they were concieved in, then built in, then maintained in.

Some of the worse offenders that I have seen probably started out as very nicely written programs. You can see a bit of well-thought out architecture trying to poke out through the mess. But as it happens, the requirements change during the end of the initial build, so some things get a little sloppy, to ensure deadlines are met, etc… Then the initial team of contractors hands it off to the internal dev team that have a different way of doing things. That team might have a dozen people, and with one or two members turning over per year, and with different people changing their focus on the system, it’s easy to understand how quickly and easily a nice code base can become an abomination. By the time I came on to it, it was full of all kinds of “WTF”‘s and eccentricities. Some of them made no sense, some were clear anti-patterns, some were to fix platform-specific issues with a specific vendor component that may or may not still have issues in their current versions (but no one’s had the time to test and the current code just works so no one wants to mess with it).

At least that’s how the horrible legacy codebases I’ve worked on evolved. Of course there were probably many things that could have been done at many of these cycles to mitigate the WTF-factor, but if that had happened then I’d have nothing to write about. 😉

As for working with it: I used to think of my job on one of those systems as a precision-strike fighter plane: fly in quick and fast through hostile terrain and deliver that one small line of code that blows the bug to pieces. Sometimes it was more fun to think of the longer, more involved big-fixes process as a Sherlock Holmes mystery: The Case of the Garbled Queue Message (or something like that).

Well, you’re directing a lot of energy toward an inanimate object. I actually deal with it by relishing in the challenge, in the contest itself. It’s the same way you face an opponent on the sports field. You want to win. They are an obstacle to you winning, but you don’t hate them for it.

The next thing I do is a refactoring step first, while I’m still trying to understand the code. If my change needs to go in a 1000 line function, I break up that function. If there’s boilerplate code repeated all over the place, I pull it out into its own function. I replace magic numbers with named constants. I’m not talking major rework that requires a deep understanding of the code, just simple transforms that can be almost mechanically applied.

At that point, I’m ready to make my change, and it’s a lot easier to do so, usually more than making up for the time I spent refactoring. Some of my best work ends up with a net loss in number of lines of code, even when I’ve added new features. When I’m facing an uphill battle, I try to remember how good that will feel when I finish.

Maybe there is no pride in the code, but you did not write it. What you can acknowledge yourself for is making the user experience better by removing the bugs. Not glorious, but the users will love you for it.

Also, you leave the code a little better for the next guy.

Filed under: softwareengineering - @ 17:55

Thẻ: bad-code, code-quality, legacy-code, maintenance

Thiết kế website giá rẻ

Danh mục

What can I do to maintain respect for a poorly written codebase? [duplicate]