| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-g0jWGmg-E0rCQEmnibTDIA" |
| name="new_guideline,_OlyWoOX7Edu8VZPtlaU33g" guid="-g0jWGmg-E0rCQEmnibTDIA" changeDate="2007-07-25T12:51:48.198-0700" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| Refactoring involves improving the design of existing code without changing the system's behavior. It is explicitly not
 |
| about adding or changing behavior, but about improving the design of existing behavior.
 |
| </p>
 |
| <p>
 |
| A full set of developer tests is required before refactoring can be safely applied. It is critical that the system
 |
| behavior be in a known, verifiably correct state before modifying the design so that you can improve the design without
 |
| fear that the modified implementation will break something. Refactoring is a safe transformation to improve code, but
 |
| it is safe only if there are tests that can verify that the system still works as intended.
 |
| </p>
 |
| <p>
 |
| Refactoring is initiated when an area that needs improvement is identified in the system by examining either the code
 |
| or&nbsp;some other&nbsp;representation of the design. The issues identified are sometimes called "smells."
 |
| </p>
 |
| <p>
 |
| Here are several smells to look for that might lead to refactoring:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>Duplicated code:</b> Duplicated code makes the system harder to understand and harder to maintain.
 |
| </li>
 |
| <li>
 |
| <b>Large design element or method:</b> Large design elements or methods diminish the ability of people to
 |
| understand the design, reduce the potential for reuse, and make developer testing more difficult.
 |
| </li>
 |
| <li>
 |
| <b>Poorly named element:</b> Whether the element be a variable, function, class, or component, its name should
 |
| connote what it is so that the code can be maintained.
 |
| </li>
 |
| <li>
 |
| <b>Tight coupling:</b> Each design element should work with minimal concern for the internal aspects of other
 |
| design elements. Otherwise, changes to one element can have undesirable effects in other elements.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| As you can see from this list, refactoring can improve the "internals" of a design element, the interface of the
 |
| element, or the relationships and collaboration between elements. Also, many of the smells&nbsp;are characterized as
 |
| making the software more difficult to understand; whereas refactoring is about making the system simpler.
 |
| </p>
 |
| <p>
 |
| After an issue is identified, a refactoring method can be selected that will improve the situation. There are catalogs
 |
| of refactoring methods available that are change patterns that will fix common problems while retaining the behavior of
 |
| the system.
 |
| </p>
 |
| <p>
 |
| These are examples of refactoring methods:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>Extract Method:</b> Pull out the duplicated code into its own single method or extract part of a large method
 |
| into its own method.
 |
| </li>
 |
| <li>
 |
| <b>Extract Class:</b> Pull some cohesive part of a class into its own class to reduce the size of a design element
 |
| that is too big.
 |
| </li>
 |
| <li>
 |
| <b>Rename Method</b>, <b>Rename Class</b>, or <b>Rename Variable:</b> Give a more meaningful name to an element to
 |
| make it more understandable.
 |
| </li>
 |
| <li>
 |
| <b>Extract Interface:</b> Create a clean interface to an element to reduce coupling.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| When refactoring has been applied, developer tests are run again to ensure that the system still behaves correctly. It
 |
| is important that the system is working correctly after each small refactoring. Although many refactorings can be put
 |
| together to drive broad change across the code base, the tests should run correctly between each refactoring applied.
 |
| Refactoring must be applied as small behavior-preserving transformations.
 |
| </p>
 |
| <p>
 |
| As mentioned previously, refactoring requires full developer test coverage of the area under consideration. There are
 |
| additional techniques that enable refactoring. Coding standards define a common style and make it easier to refactor
 |
| consistently. An attitude of&nbsp;collective code ownership within the team is important. Each developer should feel
 |
| that refactoring can be applied across the code base to improve the implementation.
 |
| </p>
 |
| <p>
 |
| For deeper coverage on this topic, including a listing of "smells" and a catalog of refactorings to respond to them,
 |
| see [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references.html#FOW99"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>].
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
