Motivation

In software development day-by-day activities, you go through deadlines, workarounds and misunderstanding and under estimate of work, this leads to bad code and design quality regarding to bad or temporary decisions you took to pass the situation, and this affect whole project quality and upcoming development activities and this generates what called by Technical Debt.

Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.

So, in order to eliminate technical debt you must revisit your code/decisions and try to refine them frequently and plan time in your weekly work to do that and this what called Refactoring.

What is Refactoring?

Refactoring is the process of restructuring code, while NOT changing its original functionality. The goal of refactoring is to improve internal code by making many small changes without altering the codes' external behavior and it's not necessary to improve performance.

So, the main goal of refactoring is enhancing code readability and maintainability.

When to Refactor?

There are multiple times that a refactor is good at.

Rule of three

Three strikes and you refactor, decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure.

Before adding new feature

Before adding new feature you have to take a look and see how this feature can affect your existing code, is it need a change in it? or what is the best way to add this feature? and so on.

When you found some ugly code

There is a rule that says, leave the place cleaner than you found, when you find some code that can be better regarding to readability and maintainability don’t be hesitated and refactor it.

Refactor principles

- Small changes at a time

Always consider a small change at time, build and compile and test what you did, then complete the refactoring.

- Don't break your code

All your refactor changes have not to break the code, and always code must be compilable and runnable, cause of any urgent matter happens and you need to leave the refactoring right now, otherwise you don’t refactor.

- Do unit test

Writing unit test before refactoring can save your back and give you more confidence when refactoring cause you now have an alert when there is something goes wrong you will be notified once it happens.

Refactor Catalog

refactor catalog describes solution for each code smell you may face in your daily work and code smells are categorized by

Bloaters

Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. Usually, these smells do not crop up right away, rather they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).

Symptoms

• Large method

A method contains too many lines of code. Generally, any method longer than 10 lines.

some example here

• Primitive obsession

Use of primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.)

Use of constants for coding information (such as a constant USER_ADMIN_ROLE = 1 for referring to users with administrator rights.)

some examples here

• Large class

A class contains many fields/methods/lines of code.

some examples here

• Long parameter list

When you have more than three or four parameters for a method.

some examples here

• Data clumps

Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database). These clumps should be turned into their own classes.

some examples here

Object oriented abusers

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

Symptoms

• Alternative classes with different interfaces

Two classes perform identical functions but have different method names.

some examples here

• 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.

some examples here

• Temporary field

Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they are empty.

some examples here

Dispensable

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

• Comments

Comments are usually created with the best of intentions, when the author realizes that his or her code isn't intuitive or obvious. In such cases, comments are like a deodorant masking the smell of fishy code that could be improved.

some examples here

• Duplicate code

some examples here

• Data class

A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters). These are simply containers for data used by other classes. These classes don't contain any additional functionality and can t independently operate on the data that they own.

some examples here

IF YOU LIKED THE POST, THEN YOU CAN SUPPPORT SUCH CONTENT WITH A CUP OF COFFEE, THANKS IN ADVANCE.