| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-i7KKltG_fEgqAjlVlIBGFA" |
| name="refactoring,_YNx2sJ05EdyQ3oTO93enUw" guid="-i7KKltG_fEgqAjlVlIBGFA" changeDate="2008-08-12T17:00:22.567-0700" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| Refactoring involves improving the quality of existing code without changing the system's behavior. It is explicitly
 |
| not about adding or changing behavior, but about improving the implementation quality 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 implementation so that you can improve the
 |
| quality 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 implementation or design 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 code, 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 implementation element, its
 |
| name should connote what it is so that the code can be maintained.
 |
| </li>
 |
| <li>
 |
| <strong>Tight coupling:</strong> 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 an element or&nbsp;the interface of the
 |
| element. 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.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| After 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="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99" guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>].
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
