make bad code good

Question

I got myself reading a article regarding changing the existing bad code into a good one. For reference, this is the link to the article http://www.javaworld.com/jw-03-2001/jw-0323-badcode.html?page=1

It broadly talked about the following

• Add comments

• Re-Factoring Code

  • Break large classes into smaller classes
  • Break large functions into smaller functions
  • Change code which is difficult to understand
• Use Layered architecture

Seems good. Any addons to this list which you all may have come across ?

Answer 1

Before doing any refactoring, ensure you have a suite of regression tests that you can run on the code. It's no good refactoring your code base if you then introduce thousands of regression bugs due to missing a slight nuance to what the original 'bad' code was actually doing (and missing it out in the refactoring).

Answer 2

Read it and tinker with it, commenting as you go, so that you understand fully it before you permanently change any code.

Answer 3

Regarding comments, it's good practise to use JavaDocs. It's like building documentation as you code.

Answer 4

Most code can be refactored from the high-level interface (and creating one of these could be a good start for any refactoring project).

It's not worth reimplementing from scratch, because the old code might have lots of special cases or workaround or non-documented but necessary behaviour. Therefore always use the existing code as a basis for refactoring.

Document as you learn the existing codebase by adding in JavaDocs and comments. This can form the basis of your redesign later on as you understand what the code does.

It can be that simply refactoring and changing variable names can aid readability a lot. Always look to do simpler refactorings if possible, especially if the code works and is just a little hard to maintain due to these simple issues.

Answer 5

Martin Fowler wrote an excellent book on refactoring.

Here is the catalog of refactorings from the book.

Answer 6

Make sure you have a full suite of regression tests!

Grab FindBugs, PMD etc. and start looking at what they have to say. I tend to find that the classes that report the most Findbugs errors have many issues and are a good place to start a refactoring effort.

Another tool worth looking at is STAN4J, it generates structural metrics showing you where the design of your code could really be improved. It will detect fragile inheritance heirarchies, bad abstractions etc. These should definately be a target of any refactoring effort.

It's worth always paying attention to these sorts of tools, they will help you out tremendously if you learn how to interpret what they are saying to you.

Also pay attention to the warnings your IDE, they're there for a reason.

• I am not affiliated with any of these tool providers (even though they're free), I do however use them a lot and am very impressed with them!

Answer 7

Ask yourself why you are refactoring the code. Does the code need to be touched? It is easy to break fragile code by improving it.

If you decide that the code needs to be changed, having a suite of tests, as others have mentioned, will help a lot.

Look at the revision history for the file(s) you are modifying and see if any changes have been made in order to fix bugs, so that you can avoid re-writing those bugs.

If you are refactoring the code for performance reasons, keep an eye out for algorithm improvements. If you can change an O(n^2) algorithm to O(n log(n)) in a hot section of code, that can do a lot more for your code than any number of other small changes.