XP/xp/guidances/concepts/refactoring_xp_programming.xmi

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