How do you decide which parts of the code shall be consolidated/refactored next?

Question

Do you use any metrics to make a decision which parts of the code (classes, modules, libraries) shall be consolidated or refactored next?

Answer 1

We use Cyclomatic_complexity to identify the code that needs to be refactored next.

Answer 2

I use Source Monitor and routinely refactor methods when the complexity metric goes aboove around 8.0.

Answer 3

I don't use any metrics which can be calculated automatically.

I use code smells and similar heuristics to detect bad code, and then I'll fix it as soon as I have noticed it. I don't have any checklist for looking problems - mostly it's a gut feeling that "this code looks messy" and then reasoning that why it is messy and figuring out a solution. Simple refactorings like giving a more descriptive name to a variable or extracting a method take only a few seconds. More intensive refactorings, such as extracting a class, might take up to a an hour or two (in which case I might leave a TODO comment and refactor it later).

One important heuristic that I use is Single Responsibility Principle. It makes the classes nicely cohesive. In some cases I use the size of the class in lines of code as a heuristic for looking more carefully, whether a class has multiple responsibilities. In my current project I've noticed that when writing Java, most of the classes will be less than 100 lines long, and often when the size approaches 200 lines, the class does many unrelated things and it is possible to split it up, so as to get more focused cohesive classes.

Answer 4

Each time I need to add new functionality I search for already existing code that does something similar. Once I find such code I think of refactoring it to solve both the original task and the new one. Surely I don't decide to refactor each time - most often I reuse the code as it is.

Answer 5

I generally only refactor "on-demand", i.e. if I see a concrete, immediate problem with the code.

Often when I need to implement a new feature or fix a bug, I find that the current structure of the code makes this difficult, such as:

• too many places to change because of copy&paste
• unsuitable data structures
• things hardcoded that need to change
• methods/classes too big to understand

Then I will refactor.

I sometimes see code that seems problematic and which I'd like to change, but I resist the urge if the area is not currently being worked on.

I see refactoring as a balance between future-proofing the code, and doing things which do not really generate any immediate value. Therefore I would not normally refactor unless I see a concrete need.

I'd like to hear about experiences from people who refactor as a matter of routine. How do you stop yourself from polishing so much you lose time for important features?