极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。
这个原则带来一个问题，那就是我们还需要设计吗？
我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。
如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客户提出需求，而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情，与其如此，还不如在事先偷懒取巧。因为需求的变化总是不可控的，根据“利益趋避原则”，自然应选择对自己更有利的一个趋向。
但这种简单并不是“简陋”，即使我们不需要考虑明天的需求，一些好的重用原则与可扩展原则仍然需要遵循。例如，我们应尽量保证对象是高内聚、低耦合的；我们应遵循“面向接口编程”原则。一言以蔽之，我们需要做到：
1、减少依赖；
2、合理抽象；
3、功能最简。
简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”，正是因为重构的保障。即使设计过于粗陋，合理利用重构也能够亡羊补牢。在重构过程中，我们仍然需要遵循简单原则，仅为当前的需求对系统结构进行重构。例如，我们在最初的需求分析中，只有一个功能要求发送电子邮件。那么，我们可以编写一个方法来封装发送电子邮件的实现，这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进，新增的几个功能同样需要发送电子邮件，此时就有必要利用重构技术，将原来发送电子邮件的方法独立到单独的类中。但是，基于简单原则，我们没有必要完善所有功能，例如增加发送Meet Request的功能。因为目前的需求并不需要。
“简单”并不只限于设计。在敏捷开发过程中，我们还需要保证项目计划的简单，以及文档的简单，乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证，通过对项目阶段的分解，简化项目计划。至于文档的简单，我们完全可以抛弃复杂标准的文档模板，转而书写仅仅是自己需要关注的内容。至少，项目内部的文档完全可以言之有物，而不需要注重形式。我们还可以通过对项目过程进行裁剪，来保障过程的简单性。事实上，在极限编程中，很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计，包括持续集成和代码所有权，都是为了提高开发过程的效率，这实际上也是简单的一种体现。
敏捷开发思想中“简单最好”是一种心态，更是一条原则。
【编辑推荐】
