Refactoring cookbook

Definition of Refactoring:
A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Why should you Refactor?
To improve the design of software
To make software easier to understand
Helps in finding bugs
To program faster
To improve security

When should you Refactor?
When you add a function or a new feature
When you need to fix a bug
When you do a code review
When new updates are introduced in the programming language
When there are vulnerabilities inside the program

Problems with Refactoring
Databases:
Most business applications are tightly coupled to the database schema that supports them. That’s one reason that the database is difficult to change. Another reason is data migration. Even if you have carefully layered your system to minimize the dependencies between the database schema and the object model, changing the database schema forces you to migrate the data, which can be a long and fraught task.
Changing Interfaces:
What if refactoring change published interfaces?
One solution is to retain both the old interface and the new one, at least until your users have had a chance to react to the change.

Refactoring and Performance
A common concern with refactoring is the effect it has on the performance of a program. To make the software easier to understand, you often make changes that will cause the program to run more slowly. Refactoring certainly will make software go more slowly, but it also makes the software more amenable to performance tuning. The secret to fast software, in all but hard real-time contexts, is to write tunable software first and then to tune it for sufficient speed.

Prerequisite before Refactoring

Build a solid set of tests for that section of code.

Identifying the code smells

Mysterious name
Duplicated code
Long method
Long parameter list
Global data
Long class
Mutable data
Divergent Change: When one module is often changed in for different reasons,breaking the single responsibility pattern.
Switch Statements: Most times you see a switch statement you should consider polymorphism.
Loops:Replace loops by pipelines.Ex:Array.filter and Array.reduce

How to start Refactoring?

1. The most common way to start refactoring is to extract code into a function.
   Extraction is all about giving meaningful names so that we don’t need any comment to understand what the function does.
   Contenders for good names are:
   1) Function name
   2) Function Parameter name
   3) Class name
   4) Local variable name
2. Forming and naming functions are essential low-level refactoring — but, once created, it’s necessary to group functions into higher-level modules.
3. Another important part of refactoring is moving elements between contexts. For ex:To move functions between classes and other modules or to move Fields between classes.
4. Any variable with more than one responsibility should be replaced with multiple variables, one for each responsibility. Using a variable for two different things is very confusing for the reader.
5. Dealing with conditional statements: