Refactoring is a disciplined way to restructure code when small changes are made to the code to improve its design. An
important aspect of a refactoring is that it improves the design while not changing the behavior of the design; a
refactoring neither adds nor removes functionality.
Refactoring enables you to evolve the code slowly over time, to take an iterative and incremental approach to
implementation.
These are the types of refactoring:
-
Code refactoring. Often referred to simply as refactoring, this is the refactoring of programming source code.
Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce Assertion, and
Pushdown Method.
-
Database refactoring. A database refactoring is a simple change to a database schema that improves its design while
retaining both its behavioral and informational semantics. Examples of database refactorings include Rename Column,
Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use Official Data
Source.
-
User interface (UI) refactoring. A UI refactoring is a simple change to the UI which retains its semantics.
Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common Font, Indicate
Format, Reword in Active Voice, and Increase Color Contrast.
Martin Fowler [FOW99] identifies four key reasons to refactor:
-
Refactoring improves the design of software
-
Refactoring makes software easier to understand
-
Refactoring helps you find bugs
-
Refactoring helps you program faster
Refactoring can improve the design of existing code, but it does not take the place of considering the design before
writing code. Refactoring instead changes the role of up-front design, allowing the strictly design work to be more
abstract. Small-scale, very tactical decisions can be made during the implementation of the solution with confidence
that refactoring will ensure a quality implementation at that level. The designing of the solution before
implementation will be more lightweight and focused on broad factors that will drive the implementation.
There is an additional benefit of refactoring: it changes the way a developer thinks about the implementation when not
refactoring. The basic task of implementing a solution becomes solely about getting the solution to pass its developer
tests in the simplest way possible. Then the design of that solution can be examined and refactored separately. Even if
these two things -- implementation of the solution and then improvement -- are just a minute apart, it can be freeing
for a developer to single-mindedly create code that causes a test to pass, and then separately single-mindedly improve
that code.
These are some additional resources:
|