Simple Design
Материал из AgileWiki
Содержание |
Определение
Simple design - подход в разработке ПО ориентированный на удешевления цены за счёт повышения качества и простоты кода.
Ценности:
- коммуницируемый код
- простота
- гибкость
Принципы:
- симметричность
- ...
Так же для полного понимания рекомендуется использовать SOLID принципы и принципы Лармана.
Статьи
c2.com
agileatlanta.org
"The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered." Not BigDesignUpFront? (BDUF).
If this is a "best practice", then why don't people do it?
- lack of experience
- they don't spend enough time on it, not done often enough
- they don't refactor so code grows complex
- lack of have design reviews
- overdesign, plan too far into future
- don't know DesignPatterns??
How is it any different if done "eXtreme"?
- ruthlessly refactor
- very small classes
- do one thing / have one responsibility
- very small methods
- instead of block comments
- just a couple lines of code
- ==> self documenting (really)
- long method and variable names instead of comments
- zero duplicate lines of code
- each class dones one thing and does it well
- design patterns used judiciously; used to communicate more than to code
What other practices support this practice?
- Small Releases discourages overdesign
- Common Vocabulary shows up in the design
- "future design changes tend to follow a convergent path"
- Sustainable Pace helps us think clearly
- Refactoring moves the code toward SimpleDesign
- (since we can't ever get it right the first time)
- Pair Programming gives us the conficence that it's simple, not stupid
- Coding Standards eliminates distractions
What other practices are supported by this one?
- enables frequent Small Releases via just enough JIT design
- makes Refactoring easier
- makes Unit Testing easier
- makes Pair Programming more fun
- simple, understandable code makes Collective Ownership more effective
How do I get started?
- Write the following on the wall and chant them in your daily standup meeting:
- Read Fowler's Refactoring book. http://www.refactoring.com/
- Learn TestFirstProgramming?. Take William Wake's test first challenge: http://www.xp123.com/
Next: Unit Testing (path A); Collective Ownership (path B).
-- AndrewFuqua - 31 Mar 2002
Ссылки
...
