建议154：不要过度设计，在敏捷中体会重构的乐趣
有时候，我们不得不随时更改软件的设计：
- 如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。
- 如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。
- 刚开始的架构太糟糕了，这可能源于设计经验的不足或者架构师的不负责任。
以上分别从外部和内部描述了必须修改需求和设计的几种场景。也就是说，在软件开发过程中，变化几乎总会发生。
为了捕捉需求上的不断变化，软件开发必须变得足够“敏捷”。设计也应该停留在“高层次”上，具有指导作用，而功能模块（或者说代码）则需要逐步改进。我们把改进的过程称为“重构”.
传统的瀑布开发由于不能满足需求的变化，在软件领域被各类敏捷开发框架所取代。
敏捷开发模式把整个开发过程分成了一个一个的迭代，每个迭代的周期大概是两周到一个月。每个迭代大致分为如下几个步骤。
敏捷开发使用“用户故事”（User Story，在TFS敏捷规范中，它被归类到BackLog）来核定需求和工作量指标。在一个迭代开始的时候，开发团队应该挑选用户故事作为本次迭代的目标；而在每一次迭代结束的时候，用户故事应该开发完毕。整个开发部门必须发布一个可以运行的版本交付给客户（对象可以是真实的用户，也可以是团队运营部门）。这有助于客户及时调整他们对产品的预期，并修正可能存在的需求变动。而作为开发团队，也可以根据客户的反馈修正需求，甚至是设计。
正是因为敏捷开发拥抱变化，所以站在整个开发流程来看，设计应该是可以修改的，而落实到代码上来，也就是重构的地位提升了。在敏捷开发体系中，我们可以将其作为一个任务（Task）引入整个开发流程中。
作为一个团队，需要定期审视模块是否可以被重构。而作为开发人员，建议一旦嗅到代码的坏味道，就需要重构我们的代码。
我们不追求让代码第一个版本就保持非常整洁的程度，那不现实，而且会让开发者觉得无从下手。当然，我们更不应该让繁杂的代码永远保持在第一个版本的状态，那样的代码，让我自己都不满意。
转自：《编写高质量代码改善C#程序的157个建议》陆敏技