<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-i7KKltG_fEgqAjlVlIBGFA" name="refactoring,_YNx2sJ05EdyQ3oTO93enUw" guid="-i7KKltG_fEgqAjlVlIBGFA" changeDate="2008-08-12T05:00:22.000-0700" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    Refactoring involves improving the quality of existing code without changing the system's behavior. It is explicitly&#xD;
    not about adding or changing behavior, but about improving the implementation quality 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 implementation so that you can improve the&#xD;
    quality without fear that the modified implementation will break something. Refactoring is a safe transformation to&#xD;
    improve code, but 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 implementation or design 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 code, 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 implementation element, its&#xD;
        name should connote what it is so that the code can be maintained.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Tight coupling:&lt;/strong> Each design element should work with minimal concern for the internal aspects of&#xD;
        other 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 an element or&amp;nbsp;the interface of the&#xD;
    element. Also, many of the smells&amp;nbsp;are characterized as making the software more difficult to understand; whereas&#xD;
    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.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    After 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;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>FOW99&lt;/a>].&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
