XP/xp/guidances/concepts/simple_design.xmi - epf/org.eclipse.epf.libraries - Git at Google

 <?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="-0rSxLFlmQfyKrgnqi1NKrg" name="simple_design,1.6109092258980447E-306" guid="-0rSxLFlmQfyKrgnqi1NKrg" changeDate="2006-11-08T16:39:05.846-0800" version="1.0.0">
   <mainDescription>&lt;a id=&quot;XE_xp__simple_design&quot; name=&quot;XE_xp__simple_design&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_simple_design__practice_of&quot;
 name=&quot;XE_simple_design__practice_of&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_engineering_practices__simple_design&quot;
 name=&quot;XE_engineering_practices__simple_design&quot;&gt;&lt;/a&gt;
 &lt;h3&gt;
     Description
 &lt;/h3&gt;
 &lt;p&gt;
     The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the
     current test cases. In many domains, &quot;simplest design&quot; is ambiguous, but it is a well-defined term in XP. A simple
     design has these four characteristics, listed in priority order:
 &lt;/p&gt;
 &lt;ul&gt;
     &lt;li&gt;
         The system runs all the tests.
     &lt;/li&gt;
     &lt;li&gt;
         It contains no duplicate code.
     &lt;/li&gt;
     &lt;li&gt;
         The code states the programmers's intent very clearly.
     &lt;/li&gt;
     &lt;li&gt;
         It contains the fewest possible number of classes and methods.
     &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;
     Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven
     Development describes how the system is created in many small steps, driven by tests that programmers write. Each of
     these tests is a probe into the design of the system, allowing the developers to explore the system as it is being
     created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the
     iteration. In XP, design quite literally happens all the time.
 &lt;/p&gt;
 &lt;p&gt;
     It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they
     should understand everything about the system before committing that knowledge to code. The reason, they've always been
     told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the
     hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,
     etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,
     understand the system incrementally, and implement in pieces.
 &lt;/p&gt;
 &lt;p&gt;
     The strategy of building software in this manner is based on the following reasoning:
 &lt;/p&gt;
 &lt;ul&gt;
     &lt;li&gt;
         Given that all requirements aren't known on the first day of the project, the development style must be adjusted to
         accommodate new understanding from customers and changes in the business climate.
     &lt;/li&gt;
     &lt;li&gt;
         If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By
         that time, there is a better chance that enough understanding will exist to support a better decision.
     &lt;/li&gt;
     &lt;li&gt;
         Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed
         and implemented in such a way that changes can be accommodated easily.
     &lt;/li&gt;
     &lt;li&gt;
         Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about
         the system. This learning must be reflected in the design. If the design is already cast before coding begins, this
         feedback is more difficult and costly to put back into the design.
     &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt;
     Here are some guidelines to help in arriving at a simple design:
 &lt;/p&gt;
 &lt;ul&gt;
     &lt;li&gt;
         Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.
         For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when
         forming a system incrementally.
     &lt;/li&gt;
     &lt;li&gt;
         Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be
         (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.
     &lt;/li&gt;
     &lt;li&gt;
         Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep
         implementation simple. Let the second user pay for the generality.
     &lt;/li&gt;
     &lt;li&gt;
         Seek out and destroy duplication. The practice of &lt;a class=&quot;elementLink&quot;
         href=&quot;./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html&quot;
         guid=&quot;1.4410217108363206E-306&quot;&gt;Refactoring&lt;/a&gt; is the most powerful tool in the arsenal. It is through removing
         duplication that new classes, methods, and larger scale systems are born.
     &lt;/li&gt;
     &lt;li&gt;
         Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated
         again in less time and better than the first time by leveraging what was learned the first time.
     &lt;/li&gt;
 &lt;/ul&gt;
 &lt;h3&gt;
     Benefits
 &lt;/h3&gt;
 &lt;ul&gt;
     &lt;li&gt;
         &lt;b&gt;Small initial investment&lt;/b&gt;: There is no need to invest in frameworks or generality that might be or might not
         be required in the future.
     &lt;/li&gt;
     &lt;li&gt;
         &lt;b&gt;Maintainability&lt;/b&gt;: Simple design will keep the design from rotting and dying prematurely. The more complex the
         design is, the harder it is to understand and preserve and the more rapidly it will decay.
     &lt;/li&gt;
     &lt;li&gt;
         &lt;b&gt;Flexibility&lt;/b&gt;: Simple systems are always easier to change than more complex systems.
     &lt;/li&gt;
     &lt;li&gt;
         &lt;b&gt;Agility&lt;/b&gt;: Simple systems are faster to change than more complex systems.
     &lt;/li&gt;
 &lt;/ul&gt;</mainDescription>
 </org.eclipse.epf.uma:ContentDescription>
	<?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="-0rSxLFlmQfyKrgnqi1NKrg" name="simple_design,1.6109092258980447E-306" guid="-0rSxLFlmQfyKrgnqi1NKrg" changeDate="2006-11-08T16:39:05.846-0800" version="1.0.0">
	<mainDescription><a id="XE_xp__simple_design" name="XE_xp__simple_design"></a><a id="XE_simple_design__practice_of"
	name="XE_simple_design__practice_of"></a><a id="XE_engineering_practices__simple_design"
	name="XE_engineering_practices__simple_design"></a>
	<h3>
	Description
	</h3>
	<p>
	The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the
	current test cases. In many domains, "simplest design" is ambiguous, but it is a well-defined term in XP. A simple
	design has these four characteristics, listed in priority order:
	</p>
	<ul>
	<li>
	The system runs all the tests.
	</li>
	<li>
	It contains no duplicate code.
	</li>
	<li>
	The code states the programmers's intent very clearly.
	</li>
	<li>
	It contains the fewest possible number of classes and methods.
	</li>
	</ul>
	<p>
	Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven
	Development describes how the system is created in many small steps, driven by tests that programmers write. Each of
	these tests is a probe into the design of the system, allowing the developers to explore the system as it is being
	created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the
	iteration. In XP, design quite literally happens all the time.
	</p>
	<p>
	It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they
	should understand everything about the system before committing that knowledge to code. The reason, they've always been
	told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the
	hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,
	etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,
	understand the system incrementally, and implement in pieces.
	</p>
	<p>
	The strategy of building software in this manner is based on the following reasoning:
	</p>
	<ul>
	<li>
	Given that all requirements aren't known on the first day of the project, the development style must be adjusted to
	accommodate new understanding from customers and changes in the business climate.
	</li>
	<li>
	If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By
	that time, there is a better chance that enough understanding will exist to support a better decision.
	</li>
	<li>
	Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed
	and implemented in such a way that changes can be accommodated easily.
	</li>
	<li>
	Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about
	the system. This learning must be reflected in the design. If the design is already cast before coding begins, this
	feedback is more difficult and costly to put back into the design.
	</li>
	</ul>
	<p>
	Here are some guidelines to help in arriving at a simple design:
	</p>
	<ul>
	<li>
	Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.
	For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when
	forming a system incrementally.
	</li>
	<li>
	Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be
	(YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.
	</li>
	<li>
	Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep
	implementation simple. Let the second user pay for the generality.
	</li>
	<li>
	Seek out and destroy duplication. The practice of <a class="elementLink"
	href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
	guid="1.4410217108363206E-306">Refactoring</a> is the most powerful tool in the arsenal. It is through removing
	duplication that new classes, methods, and larger scale systems are born.
	</li>
	<li>
	Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated
	again in less time and better than the first time by leveraging what was learned the first time.
	</li>
	</ul>
	<h3>
	Benefits
	</h3>
	<ul>
	<li>
	<b>Small initial investment</b>: There is no need to invest in frameworks or generality that might be or might not
	be required in the future.
	</li>
	<li>
	<b>Maintainability</b>: Simple design will keep the design from rotting and dying prematurely. The more complex the
	design is, the harder it is to understand and preserve and the more rapidly it will decay.
	</li>
	<li>
	<b>Flexibility</b>: Simple systems are always easier to change than more complex systems.
	</li>
	<li>
	<b>Agility</b>: Simple systems are faster to change than more complex systems.
	</li>
	</ul></mainDescription>
	</org.eclipse.epf.uma:ContentDescription>