How to cope with bad code [closed]

Question

General tip:

if (it is working)
   Do (not touch it);
else
{
   Make (as few modifications as possible)
   Or (it will stop working at all);
}

This is experience of generations.

Michael Feathers wrote a good book about this subject exactly.

Working Effectively with Legacy Code.

Another great book is by Martin Fowler, Kent Beck and others:

Refactoring: Improving the Design of Existing Code.

Refactoring needs the safety harness of a unit test suite to remove that "Have I broken it?" feeling. Covering the bad code in a blanket of tests will help you whilst you strive for good clean code.

Pex is a tool that I find useful (if you are in the .NET world) for creating tests for legacy code.

Legacy code == code without tests!

Kindness,

Dan

When I have to deal with adding functionality to bad code, my usual approach is:

• Write automated tests for every important feature that must work (as most bad code doesn't have any tests).
• Do code changes.
• Make sure the tests are still working.

That give you at least some confidence that you didn't break everything. As for how to learn coping with bad code, I guess it's just about experience.

Well, if you're going to refactor large amounts of code in a project I'd recommend using some decent version control, so you can branch and fall back easily. Given, this is probably is an open door, but crucial imo.

Furthermore, before you start getting in to complex OO, try breaking methods and functions into smaller ones. Ensuring some level of atomicity in each of the functions, which makes the code alot easier to maintain, read and manage. It's all about the small stuff, break it down into logical units of operation, I'm doing a refactor action on a 1k lines method. It does al sorts of fancy stuff. My first goal is to get as much stuff out of it in smaller pieces, when that's done I'll start thinking about a better OO design, which is much easier because I've a much better grasp on things.

Aspirin works good too.

I am currently in this situation. My approach is to answer some questions before touching the code:

1. Is the code really that bad? If yes, what are the common errors? ==> maybe concentrate on those first
2. What is the main runtime flow in the code? Maybe you can discard quite a few constructs from it.
3. Try to layer/modularize the code without changing it. This leads to some reduction of interdependencies
4. Try to poke the code with tests. If the code base is entangled beyond hope: use something like PowerMock to simulate objects that are not (yet) in need of change
5. Have an integration environment available, in which you can test changes in a production near environment.
6. Don't shy away to rewrite parts of the code base. But try to not implement too much new stuff in it
7. Try to team up, discuss designs, principles, solutions

This is tough work, and nobody will thank you for it. Be proud of small improvements and enjoy a good work done :)

I think that it is always good to have a general idea of how everything works in the software you are developing/improving. That's where the design documents and other documents made after or during the development process come in. I believe that if someone before you has not done proper documentation, then at least you should write a couple of lines somewhere about what you experience throughout your development process. I usually use OneNote or other stuff to write notes about what I encounter, and usually keep listing things which I feel would require refactoring. And if there is some downtime during the project, I usually go back to that list and try to improve things bit by bit.

So basically, if someone before you hasn't done it right, it would be good if at least you could help reduce the problems for any other developer who would come across the same code.