When developing on an old code base, should I use Best Practices or go for Consistency [duplicate]

Question

Possible Duplicate:
Code maintenance: keeping a bad pattern when extending new code for being consistent, or not ?

As my experience in programming increases with each project, I look back at earlier projects and cringe at some of the ways the code is structured or how well i have implemented a design pattern. These projects are still utilized in production environments (without issue) and have new features implemented on a yearly cycle.

Updating the entire structure is not feasible. When implementing new features should I structure the updates with best practices in mind, or should I keep to existing (inferior) structure to maintain consistency with the rest of the project?

Answer 1

You may have answered your own question without realizing it:

These projects are still utilized in production environments (without issue) and have new features implemented on a yearly cycle.

If that is indeed the case, the implementation is probably not as bad as you think it is. If the software works and is relatively easy to maintain, you've nailed it. On top of that, if you can easily add new features without drastic structural changes, then you've really nailed it.

You will always look back on yesterday with what you know today and decide that yesterday is somehow inferior to today. That's what we call growth and improvement, however it doesn't imply that yesterday in some way needs to be fixed.

Why, oh why would you spend any considerable length of time making a maintainable, extendable and functional program be exactly the same thing as it was when you started? Will there be any obvious gains to users that aren't measured in millionths of a second or lines of code that they rarely (if ever) see?

If, during the life cycle of the program you realize that deprecated methods or functions make the existing design not make as much sense as it originally did, you might have to make some adjustments. You might also need to introduce a feature that eventually justifies going back and doing a lot of re-factoring.

Don't go re-factoring something in production just for the sake of re-factoring. The whole goal is to write code that doesn't have to be drastically changed in the future, and it looks like you hit that goal. Why short circuit a success?

Answer 2

Leave the code better than you found it

There is always an adrenaline rush to quickly implement some new feature or pattern when you find a bad piece of code but before you jump and clean it up there are few points to bear. Since this is production code and is working its not always suited to clear it off and write yours which will have to be tested rigorously.

You should identify the existing usages and how your new changes are gonna impact it, is it worth the time investing since some might need quick turn around for an issue.

Am i addressing all that was earlier because some functionality do tends to be missed out(at times not always and you find yourself staring at the code again in a weeks time)

In some cases it would be impossible to alter or could have devastating efforts in the sense of timeline, money and maintaining it could be a better option.

So try to work out on some of these lines and i presume you would find more suggestions pouring in, At all times give Readability a higher precedence than optimizations.(unless its really hampering something)

Answer 3

You need to maintain compatibility, not consistency.

Answer 4

Follow the boy scout rule, that is, always leave it cleaner than you found it (including your new code)

That doesn't mean you have to dive in and refactor until it's perfect, it just means incremental refactoring when it makes sense to do so.

Answer 5

Tread lightly, for you tread on my dreams.

I think the key to this is buy-in. I'm always an advocate for refactoring and improving the design of existing code but if you end up going on a tangent that no-one else follows your code is going to look so foreign to them that it isn't going to be very helpful. Worse than that, they might get angry at you for revamping all their hard work without at-least some input in the process and offer resistance to it. This area is helped greatly by code reviews. With code reviews everyone in the team gets to see the direction each-other is taking and offer suggestions so that the code base evolves with continued consistency (assuming it started with consistency).

So, try to get code reviews in place if they aren't already. Also, when making a major refactoring (or as an alternative to code reviews) send an email to the team members letting them know your ideas and asking for suggestions or criticisms. If you find that none of this is working and you are getting frustrated with resistance to improvements it might be time to find a job where change is welcomed instead of feared.