<?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="-U8NScY6mORb4XPcNZ_mrEA"
    name="refactoring_xp_programming,1.4410217108363206E-306" guid="-U8NScY6mORb4XPcNZ_mrEA"
    changeDate="2006-11-09T19:20:46.023-0500" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__refactoring&quot; name=&quot;XE_xp__refactoring&quot;>&lt;/a>&lt;a id=&quot;XE_refactoring__practice_of&quot; name=&quot;XE_refactoring__practice_of&quot;>&lt;/a>&lt;a id=&quot;XE_engineering_practices__refactoring&quot; name=&quot;XE_engineering_practices__refactoring&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    Description&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Refactoring is the practice of improving the design of a system without changing its behavior. Refactoring is a&#xD;
    critical practice and skill in iterative development. The programmer is either adding a new feature or refactoring. XP&#xD;
    programmers consciously choose between refactoring and adding new functionality on a minute-by-minute basis. Some&#xD;
    refactorings are trivial, such as renaming or moving things. Other refactorings allow you to exchange procedural logic&#xD;
    with polymorphism, and still larger refactorings exist to introduce design patterns.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    While processes like Extreme Programming rely on refactoring to let the design emerge, the usefulness of refactoring&#xD;
    extends beyond the Agile Methodologies. As feature requests and bug fixes require changes to a system, refactoring&#xD;
    techniques allow the programmers to maintain a good design. Refactoring can also be used to improve the design of an&#xD;
    existing system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Refactoring is not new. Developers have been refactoring for years, though only recently have people started to catalog&#xD;
    refactorings. Refactoring has become such an important part of development that professional-level Integrated&#xD;
    Development Environments (IDEs) either include built-in tools or have plug-ins to provide refactoring support.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If your system isn't being refactored as it is modified, your design deteriorates; methods become longer, classes take&#xD;
    on more responsibility, more code gets cut and pasted around your system, previously cut-and-pasted code has to be&#xD;
    modified in several places.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If your system becomes brittle and inflexible, your developers will have to spend more time and money to add features&#xD;
    or fix bugs. As the design continues to deteriorate, fixing one bug creates two more, or the cost of adding a new&#xD;
    feature out weighs the benefit of having it because so much of the system has to be modified. There are many analogies&#xD;
    to describe this battle against entropy; from cleaning as you go to design debt.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Knowing the refactorings isn't enough. Developers must be able to identify problem areas of the program design (often&#xD;
    referred to as &quot;smells&quot;). These are the places where refactoring can be used to improve the design of the code. Design&#xD;
    skill and experience are needed to recognize bad code smells.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Automated tests provide a safety net when making changes. The automated tests report when the functionality of the&#xD;
    system changes. Make a structural change to the software; see that the tests still pass. You can confidently refactor.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Where do all these tests come from? In XP, they are developed using &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../xp/guidances/concepts/test_driven_development.html&quot; guid=&quot;1.620567348185129E-306&quot;>Test-Driven Development&lt;/a>. It is possible to refactor without tests, but you run the&#xD;
    risk of unknowingly introducing bugs or breaking existing functionality.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Benefits&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Allows the design to emerge over time.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Keeps the design from rotting.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reduces cost of change.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Related Information&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    &amp;nbsp;See the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../xp/guidances/guidelines/refactoring.html&quot; guid=&quot;8.137126904637637E-306&quot;>Refactoring Guidelines&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>