| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\xp\guidances\concepts\simple_design.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: simple_design.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,1.6109092258980447E-306 CRC: 4110814805 -->Simple Design<!-- END:presentationName,1.6109092258980447E-306 --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-0rSxLFlmQfyKrgnqi1NKrg CRC: 63014376 --><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><!-- END:mainDescription,-0rSxLFlmQfyKrgnqi1NKrg --> |
| </body> |
| </html> |