4

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

To keep things simple let's say I am responsible for maintaining two applications, AwesomeApp and BadApp (I am responsible for more and no that is not their actual names).

AwesomeApp is a greenfield project I have been working on with other members on my team. It was coded using all the fancy buzzwords, Multilayer, SOA, SOLID, TDD, and so on. It represents the direction we want to go as a team.

BadApp is a application that has been around for a long time. The architecture suffers from many sins, namely everything is tightly coupled together and it is not uncommon to get a circular dependency error from the compiler, it is almost impossible to unit test, large classes, duplicate code, and so on. We have a plan to rewrite the application following the standards established by AwesomeApp, but that won't happen for a while.

I have to go into BadApp and fix a bug, but after spending months coding what I consider correctly, I really don't want do continue perpetuate bad coding practices. However, the way AwesomeApp is coded is vastly different from the way BadApp is coded. I fear implementing the "correct" way would cause confusion for other developers who have to maintain the application.

Question: Is it better to keep coding the wrong way to remain consistent with the rest of the code in the application (knowing it will be replaced) or is it better to code the right way with an understanding it could cause confusion because it is so much different?

To give you an example. There is a large class (1000+ lines) with several functions. One of the functions is to calculate a date based on an enumerated value. Currently the function handles all the various calculations. The function relies on no other functionality within the class. It is self contained. I want to break the function into smaller functions (at the very least) and put them into their own classes and hide those classes behind an interface (at the most) and use the factory pattern to instantiate the date classes. If I just broke it out into smaller functions within the class it would follow the existing coding standard. The extra steps are to start following some of the SOLID principles.

Community
  • 1
bwalk2895
  • 1,988
  • 1
  • 13
  • 15
  • I think your reasoning is correct, taking into account a usual fact that budget for legacy code maintenance is tight/short. – Yusubov Jul 03 '12 at 18:06

5 Answers5

4

Consistency is worth less than quality every time. If your other developers on BadApp don't know how to code well, train them or fire them.

Or, if your boss won't consider those two alternatives, call your headhunter.

Edit: Twas my impression that you were suggesting that the other developers working on BadApp would have a problem with good code. If not, then, well, there's really no reason not to start coding well. Consistency is only valuable if you're consistent with something worth being.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
4

I would think your danger in "fixing" BadApp as you maintain is that it will suck up time and effort better spend on GoodApp until it's time for BadApp V2.0.

I would:

  1. Have a team meeting and enumerate the differences between the two. That helps everyone (including any "old schoolers" to buy into what's good.
  2. Acknowledge that you will leave some of the old stuff (if it's working) as is and leave breadcrumbs for yourself on what needs to be fixed. You can use your ticket system or even extended "TODO" type comments in the code. After time these accumulate and the migration is less buggy.
  3. When the rewirte of BadApp does come, management will commit the proper resources based on what you identified above...LOL I just want to type that, could not have said it with a straight face :-)
Phil Cooper
  • 250
  • 1
  • 5
1

If I was in your place I'd either suggest to the team to concentrate on refactoring the code, or at least have someone only assigned to refactor the code. It should be pretty obvious that it will pay off in the long run.

Don't ever feel ashamed to fix broken code!

marktani
  • 629
  • 6
  • 18
1

Refactoring code all the time isn't always good and productive. I had a colleague who is a brilliant programmer but he never managed to finish the app he was working on. With every new bug he saw many faults in the program and tried to change some structure to fix the bug. He was fired eventually.

If there are any changes that will take smth like 30-40 percent more time than you need just to fix the bug, than I'd say you change the code. By the time you and your team find time/person to completely refactor the code, it will be much easier because a lot is already done. If you are adding new piece of code to that app, than add it properly. Don't be afraid that someone won't understand it.

But if with every bug you'll try to rewrite a big piece of code, you'll get nowhere. It's better either to do small changes and wait for the BIG refactoring, or not to touch the old nasty but working code.

superM
  • 7,363
  • 4
  • 29
  • 38
0

What it may come down to is a cost analysis on BadApp, to see if it is worth going in and updating the code to better standards, or whether just flat out rewriting the application is better. Or, there may be off the shelf solutions out there to do part of the functions of BadApp, and rewrite/update the rest.

One approach might be to have a developer or two go through the code in BadApp, and outline what needs to be changed/updated (This could be part of or a result of the cost analysis). You keep that list, and then anytime you need to go into BadApp, you also take one of the rewrite functions and complete that. It extends the timeframe for updating BadApp to standard, but it will eventually be at least MediocreApp.

JohnP
  • 524
  • 6
  • 14