# Refactoring Code

Refactoring is a controlled technique for improving the design of an existing code base over time.

We all want to write perfect code, but given the challenges in software development, we often end-up with less-than-perfect solutions.

• Rushed features: Sometimes we don’t have enough time, so we cut corners, complete things "on-time".
• Lack of tests: We might think that the code is ready, but we haven’t tested it adequately.
• Lack of communication: Perhaps we misunderstood requirements, or how a feature would integrate into the larger product.
• Poor design: Possibly our design is rigid and makes adding or modifying features difficult.

These are all actions that may cost us time later. We may need to stop and redesign a rushed feature, or we may need to fix bugs later.

We refer to this as technical debt — the deferred cost of doing something poorly.

# What is refactoring?

Martin Fowler (2000) also introduced the notion of refactoring: systematically transforming your working code base into a cleaner, improved version of itself that is easier to read, maintain and extend.

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant.

-- Martin Fowler, 2018.

Refactoring suggests that code must be continually improved as we work with it. We need to be in a process of perpetual, small improvements.

The goal of refactoring is to reduce technical debt by making small continual improvements to our code. It doesn’t reduce the likelihood of technical debt, but it amortizes that debt over many small improvements.

Refactoring your code means doing things like:

• Cleaning up class interfaces and relationships.
• Fixing issues with class cohesion.
• Reducing or removing unnecessary dependencies.
• Simplifying code to reduce unnecessary complexity.
• Making code more understandable and readable.
• Adding more exhaustive tests.

In other words, refactoring involves code improvement not related to adding functionality.

TDD and Refactoring work together. You continually refactor as you expand your code, and you rely on the tests to guarantee that you aren’t making any breaking changes to your code.

# How to refactor code?

# The Rule of Three

1. When you’re doing something for the first time, just get it done.
2. When you’re doing something similar for the second time, do the same thing again.
3. When you’re doing something for the third time, start refactoring.

# When adding a feature

Refactor existing code before you add a new feature, since it’s much easier to make changes to clean code. Also, you will improve it not only for yourself but also for those who use it after you.

# When fixing a bug

If you find or suspect a bug, refactoring to simplify the existing code can often reveal logic errors.

# During a code review

The code review may be the last chance to tidy up the code before it becomes available to the public.

# Refactoring actions

Fowler lists a series of refactoring actions in his original book. He has also made them available at: https://refactoring.com/catalog/

IntelliJ IDEA also makes refactoring easy by providing automated ways of safely transforming your code. These refactorings often involve operations that would be tricky to do by-hand but easy for a tool to perform for you (e.g. renaming a method that is called from multiple locations).

To invoke refactorings, select an item in your source code (e.g. variable or function name) and press Ctrl-T to invoke the refactoring menu. You can also access this from the application menu.

There is a complete list of refactorings in the IntelliJ IDEA documentation. Refactorings include:

# Code Smells

A “code smell” is a sign that a chunk of code is badly designed or implemented. It’s a great indication that you may need to refactor the code. Adjectives commonly used to describe code include:

• “neat”, “clean”, “clear”, “beautiful”, “elegant” <— the reactions that we want
• “messy”, “disorganized”, “ugly”, “awkward” <— the reactions we want to avoid

A negative emotional reaction is a flag that your brain doesn’t like something about the organization of the code - even you can’t immediately identify what that is. Conversely, a positive reaction indicates that your brain can easily perceive and following the underlying structure.

The following categories and examples are taken from refactoring.guru.

# Bloaters

Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. These smells accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).

• Long method: A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions.
• Large class: A class contains many fields/methods/lines of code. This suggests that it may be doing too much. Consider breaking out a new class, or interface.
• Primitive obsession: Use of related primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.). Consider creating a data class, or small class instead.
• Long parameters list: More than three or four parameters for a method. Consider passing an object that owns all of these. If many of them are optional, consider a builder pattern instead.

# Object-Oriented Abusers

All these smells are incomplete or incorrect application of object-oriented programming principles.

• Alternative Classes with Different Interfaces: Two classes perform identical functions but have different method names. Consolidate methods into a single class instead, with support for both interfaces.
• Refused bequest: If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions. This violates the Liskov-substitution principle! Add missing behaviour, or replace inheritance with delegation.
• Switch Statement: You have a complex switch operator or sequence of if statements. This sometimes indicates that you are switching on type, something that should be handled by polymorphism instead. Consider whether a class structure and polymorphism makes more sense in this case.
• Temporary Field: Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they’re empty. This may be a place to introduce nullable types, to make it very clear what is actually happening (vs. constantly checking fields for the presence of data).

# Dispensibles

A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand.

• Comments: A method is filled with explanatory comments. These are usually well-intentioned, but they’re not a substitute for well-structured code. Comments are a maintenance burden. Replace or remove excessive comments.
• Duplicate Code: Two code fragments look almost identical. Typically, done accidentally by different programmers. Extract the methods into a single common method that is used instead. Alternately, if the methods solve the same problem in different ways, pick and keep the most efficient algorithm.
• Dead Code: A variable, parameter, field, method or class is no longer used (usually because it’s obsolete). Delete unused code and unneeded files. You can always find it in Git history.
• Lazy Class: Understanding and maintaining classes always costs time and money. So if a class doesn’t do enough to earn your attention, it should be deleted. This is tricky: sometimes a small data class is clearer than using primitives (e.g. a Point class, vs using x and y stored as doubles).

# Couplers

All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation.

• Feature envy: A method accesses the data of another object more than its own data. This smell may occur after fields are moved to a data class. If this is the case, you may want to move the operations on data to this class as well.
• Inappropriate intimacy: One class uses the internal fields and methods of another class. Either move those fields and methods to the second class, or extract a separate class that can handle that functionality.
• Middle man: If a class performs only one action, delegating work to another class, why does it exist at all? It can be the result of the useful work of a class being gradually moved to other classes. The class remains as an empty shell that doesn’t do anything other than delegate. Remove it.

# Last Word