Say you got an old codebase that you need to maintain and it's clearly not compliant with current standards. How would you distribute your efforts to keep the codebase backwards compatible while gaining standards compliance? What is important to you?
A:
I'd factor in time to fix up modules as I needed to work with them. An up-front rewrite/refactor isn't going to fly in any reasonable company, but it'll almost definitely be a nightmare to maintain a bodgy codebase without cleaning it up somewhat.
womble
2009-02-20 07:45:04
I agree that this is probably the best way to get time for any changes, but how will you prioritize them without doing it up-front? By doing it on a module by module basis you risk spending you resources equally over problems that are not equally important.
JohannesH
2009-02-20 07:55:23
If a change needs to be made to a module, you clean it up at the time you make the change. If a change is unimportant to the point that it doesn't get made, then the module won't get cleaned up yet.
womble
2009-02-20 08:01:46
+4
A:
At my workplace we don't get any time to refactor things just because it makes the code better. There has to be a bug or a feature request from the customer.
Given that rule I do the following:
When I refactor:
If I have to make changes to an old project, I cleanup, refactor or rewrite the part that I'm changing.
Because I always have to understand the code to make the change in the first place, that's the best time to make other changes.
Also this is a good time to add missing unit tests, for your change and the existing code.
I always do the refactoring first and then make my changes, so that way I'm much more confident my changes didn't break anything.
Priorities:
The code parts which need refactoring the most, often contain the most bugs. Also we don't get any bug reports or feature requests for parts which are of no interest to the customer. Hence with this method prioritization comes automatically.
Circumenventing bad designs:
I guess there are tons of books about this, but here's what helped me the most:
I build facades:
- Facades with a new good design which "quarantine" the existing bad code. I use this if I have to write new code and I have to reuse badly structured existing code, which I can't change due to time constraints.
- Facades with the original bad design, which hide the new good code. I use this if I have to write new code which is used by the existing code.
The main purpose of those facades is dividing good from bad code and thus limiting dependencies and cascading effects.
DR
2009-02-20 07:58:12
In a bad codebase (which is not unlike the one I'm maintaining) there might be a lot of interdependencies (often hidden dependencies) between modules which makes it either hard to change one module alone or to predict what effect it will have on the running systems.
JohannesH
2009-02-20 11:52:37