建议154：不要过度设计，在敏捷中体会重构的乐趣
有时候，我们不得不随时变动软件的设计：
如果项目是针对某个大型机构的，，差别级另外软件使用者，会提出差此外需求，或者跟着关键岗位人员的更替，需求也会随小我私家意志有所变换。
如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调解设计方案。
刚开始的架构太糟糕了，这可能源于设计经验的不敷或者架构师的不卖力任。
以上分袂从外部和内部描述了必需改削需求和设计的几种场景。也就是说，在软件开发过程中，变革几乎总会产生。
为了捕捉需求上的不停变革，软件开发必需变得足够“敏捷”。设计也应该勾留在“高条理”上，具有指导感化，而成果模块（或者说代码）则需要逐步改造。我们把改造的过程称为“重构”.
传统的瀑布开发由于不能满足需求的变革，在软件范围被种种敏捷开发框架所代替。
敏捷开发模式把整个开发过程分成了一个一个的迭代，每个迭代的周期概略是两周到一个月。每个迭代大抵分为如下几个法式。
敏捷开发使用“用户故事”（User Story，在TFS敏捷规范中，它被归类到BackLog）来核定需求和事情量指标。在一个迭代开始的时候，开发团队应该挑选用户故事作为本次迭代的方针；而在每一次迭代结束的时候，用户故事应该开发完毕。整个开发部门必需颁布一个可以运行的版本交付给客户（东西可以是真实的用户，也可以是团队运营部门）。这有助于客户及时调解他们对产品的预期，并修正可能存在的需求改观。而作为开发团队，也可以按照客户的反馈修正需求，甚至是设计。
正是因为敏捷开发拥抱变革，所以站在整个开发流程来看，设计应该是可以改削的，而落实到代码上来，也就是重构的职位地方提升了。在敏捷开发体系中，我们可以将其作为一个任务（Task）引入整个开发流程中。
作为一个团队，需要按期审视模块是否可以被重构。而作为开发人员，建议一旦嗅到代码的坏味道，就需要重构我们的代码。
我们不追求让代码第一个版本就连结非常整洁的水平，那不现实，而且会让开发者感受无从下手。固然，我们更不应该让繁杂的代码永远连结在第一个版本的状态，那样的代码，让我本身都不对劲。