Refactoring

The purpose of refactoring is to make the program code easier to understand; Without this, refactoring cannot be considered successful.

Refactoring should be distinguished from performance optimization . Like refactoring, optimization usually does not change the behavior of the program, but only accelerates its work. But optimization often makes code difficult to understand, which is the opposite of refactoring ^[3] .

On the other hand, it is necessary to distinguish between refactoring and reengineering , which is carried out to expand the functionality of the software. As a rule, large refactorings precede reengineering.

Refactoring must be applied continuously when developing code. The main incentives for its implementation are the following tasks:

1. it is necessary to add a new function that does not fit into the adopted architectural solution ;
2. it is necessary to correct the error, the causes of which are not immediately clear;
3. overcoming difficulties in team development, which are caused by the complex logic of the program.

In many ways, when refactoring, it is better to rely on intuition based on experience. Nevertheless, there are some visible problems in the code ( English code smells ) that require refactoring:

1. code duplication ;
2. long method;
3. large class;
4. long list of parameters;
5. “Greedy” functions - this is a method that excessively refers to the data of another object;
6. redundant temporary variables;
7. data classes
8. ungrouped data.

In programming, the term refactoring means changing the source code of a program without changing its external behavior. In extreme programming and other flexible methodologies, refactoring is an integral part of the software development cycle: developers alternately create new tests and functionality, then refactor the code to improve its consistency and transparency. Automatic unit testing ensures that refactoring has not destroyed existing functionality.

Refactoring is not originally intended to correct errors and add new functionality, it does not change the behavior of software at all ^[3] and this helps to avoid errors and facilitate the addition of functionality. It is performed to improve the comprehensibility of the code or change its structure, to remove the "dead code" - all this in order to make the code easier to maintain and develop in the future. In particular, adding new behavior to the program can be difficult with the existing structure - in this case, the developer can perform the necessary refactoring, and only then add new functionality.

This can be moving a field from one class to another, taking a piece of code from a method and turning it into an independent method, or even moving the code through a class hierarchy. Each individual step may seem elementary, but the combined effect of such small changes is able to radically improve the project or even prevent the breakdown of a poorly designed program.

The most used ^[4] refactoring methods:

• Change method signature
• Encapsulate field
• Class selection (extract class)
• Extract interface
• Extract local variable
• Extraction method
• Generalize type
• Embedding (inline)
• Introduce factory
• Introduce parameter
• Pull up method
• Push down method
• Rename method
• Move method
• Replace conditional with polymorphism
• Replace inheritance with delegation
• Replace type code with subclasses
• Replacing code stack with recursion and vice versa

Change method signature

The essence of changing a method signature is to add, change, or delete a method parameter. After changing the signature of the method, you need to adjust the access to it in the code of all clients. This change may affect the external interface of the program, in addition, all clients of this interface are not always accessible to the developer changing the interface, therefore, this or that form of registration of interface changes may be required for their subsequent transfer along with the new version of the program.

Encapsulate field

In case the class has an open field, it is necessary to make it private and provide access methods. After Field Encapsulation , the Move Method is often used.

Extract method

Isolation of a method consists in isolating individual fragments from a long and / or code requiring comments, and converting them into separate methods, with the substitution of suitable calls in the places of use. In this case, the rule applies: if a piece of code requires a comment about what it does, then it should be allocated in a separate method. Also the rule: one method should not occupy more than one screen (25-50 lines, depending on the editing conditions), otherwise some of its fragments have independent value and must be selected. From the analysis of the relationships of the selected fragment with the surrounding context, a conclusion is drawn about the list of parameters of the new method and its local variables.

Move method

A method move is applied to a method that often refers to a different class than the one in which it is located.

Replace conditional with polymorphism

A conditional statement with several branches is replaced by a polymorphic method call of some base class that has subclasses for each branch of the original operator. The branch is selected implicitly, depending on which instance of the subclass the call was addressed to.

Basic principles:

• First, create a base class and the required number of subclasses;
• in some cases, it is necessary to optimize the conditional operator by “ Method extraction ” ;
• it is possible to use the " Move Method " to place the conditional operator at the top of the inheritance hierarchy;
• having chosen one of the subclasses, it is necessary to specify in it the polymorphic method of the base class and move the body of the corresponding branch of the conditional operator into it;
• repeat the previous action for each branch of the conditional statement;
• replace the entire conditional operator with a call to the base class polymorphic method.

• Database related issues
• interface change problems;
• difficulties in changing the design.

Technical criteria for refactoring tools:

• program databases;
• parsing trees
• accuracy.

Practical criteria for refactoring tools:

• speed;
• cancellation of modifications;
• integration with other tools.

• Design Patterns
• Extreme programming
• Code view
• Database Refactoring

• Fowler M. , Beck K., Brant D., Roberts D., Updike W. Refactoring: Improving the Existing Code = Refactoring: Improving the Design of Existing Code (2000). - St. Petersburg: Symbol Plus, 2009 .-- 432 p. - 3000 copies. - ISBN 5-93286-045-6 .
• Scott W. Ambler, Pramodkumar J. Sadaladge. Database Refactoring: Evolutionary Design = Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series). - M .: "Williams" , 2007. - 368 p. - ISBN 0-321-29353-3 .
• Joshua Kerievsky. Refactoring with Patterns = Refactoring to Patterns. - Williams, 2008 .-- 400 p. - ISBN 5-93286-045-6 .

• What is refactoring? (eng.)
• Martin Fowler's refactoring homepage
• Ksenzov Michael. Software architecture refactoring: layer allocation (neopr.) . - One of the main methods for refactoring software architecture is considered - the allocation of layers, as well as its place in the context of refactoring architecture as a multi-step iterative process. Date of treatment November 30, 2007. Archived on August 25, 2011.
• Overview of programs for automatic refactoring
• Revisiting Fowler's Video Store: Refactoring Code, Refining Abstractions