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