Continuous Integration and Refactoring

A common question is how do you find the code that should be refactored?

Often refactoring takes place when making small changes to existing code while introducing new code or changing a method, but code which could benefit from refactoring can also be found by using static analysis tools. The following are examples of typical problems:

Conditional Cyclomatic Complexity

• Cyclomatic Complexity Numbers (CCN) measure the number of unique paths in a method via conditional constructs such as if and switch statements, while and for loops and exceptions
• Overly complex methods typically have a CCN of 10 or more
• Conditional statements can be refactored out using polymorphism

Duplicate Code

• Duplicate code often appears because it is sometimes easier to copy and paste code than generalise behaviour in another class, however this results in duplicate maintenance and inconsistent behaviour where there are slight variations
• Duplicate code can be found where a number of lines are repeated either exactly the same or similarly
• It can be refactored from a large method into an abstract class method

Long Methods and Large Classes

• There is often a correlation between long methods and conditional complexity and it is likely that the more lines in a method the more difficult it is to maintain the code
• Long methods should be extracted out into smaller reusable methods

Too Many Imports

• A class with many imports relies upon many other classes
• Fan out complexity can be used to find out how many classes a class depends upon

There are many static analysis tools available including CheckStyle and PMD. These tools can be included along with Unit tests as part of Continuous Integration (CI) builds triggered with every change to a project's version-control repository and by schedule.

See: Automation for the people: Continual refactoring