| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-g0jWGmg-E0rCQEmnibTDIA" |
| name="new_guideline,_OlyWoOX7Edu8VZPtlaU33g" guid="-g0jWGmg-E0rCQEmnibTDIA" changeDate="2007-04-19T05:51:37.878-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 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> Before refactoring, there must be full developer test coverage of the area 
 |
| of the system under consideration. Then 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 &quot;internals&quot; 
 |
| 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, Rename Class, or Rename Variable: </b>Give a more meaningful 
 |
| name to an element. </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 shared 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_6CCF393.html#FOW99" guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>]. 
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
