简单设计是Xp技术实践中开发实践的核心实践，“简单也是价值观中智力色彩最强烈的”，然而，提到简单设计，大家更觉得像原则或者价值观，感觉上还是比较泛，我们不妨从下面的几个角度看一下
 
1. 为什么要简单设计
<1>. 简单的代码更容易读懂。
<2>. 好的设计更能应对变化。
 
这两点是基于成本和收益考虑的，这里的价值是时间及金钱。更快的满足需求，减少复杂带来的故障排查、修复成本，代码大量修改或者重写成本。
 
2. 什么是简单设计
对一个团队来讲，简单设计就是团队中每个人都能轻松的读懂代码，并且代码层次清晰，文件、类、函数都比较独立，面对不断增加的需求，容易扩展。
简单意味着优雅。真正的做到简单，往往是比较困难的。因为本质往往隐藏在复杂表象的后面，需要深入的思考，才能找到。记得一位大牛解释时，借用了“念念不忘，必有回响”。一个漂亮模型的抽象，往往是深入思考后的产物。
设计更多的是在进行演进式设计。面对一个复杂的，需求不断变化的系统，首先，我们承认我们是不完美的（这点很重要，我们把重心转移到寻找更好的设计上，而不是比较某个人有多牛），我们不相信一步可以设计出一个完美无缺的模型。我们只要求设计在当前的需求下是简单的，我们遵循一些原则（后面会提到），当需求不断增加时，不断重构自己的设计，保持设计简单性，直到满足所有需求。
 
3. 简单设计的原则
Kent beck的简单设计四原则
<1>. Runs all the tests
<2>. No duplication
<3>. Expresses developer intent
<4>. Minimizes the number of classes and methods
 
Kent beck认为以上四点的可验证性及重要程度都是依次降低，我们逐个分析一下：
1>. 通过所有测试：至少有两个意思，系统必须有完备的自动化测试（不自动化你如何“Runs”）；所有的测试都验证通过，保证系统正确。
正确性永远是所有设计的基础。假如我们都是技艺超群的雕刻师，客户需要一匹狼，我们雕刻出一只狗，无论多么惟妙惟肖，对于客户可能都一文不值。
自动化测试在不同时期发挥不同作用。首先，自动化测试在产品研发的不同时期，价值是不相同的。在编码初期，测试用例可以帮我们发现大量低级故障，可以大大缩短真实环境调试的时间。其次，在代码维护阶段，完备的测试可以为你的大胆重构提供保护，持续的重构才能真正的保持设计的持续的简单。
 
2>. 没有重复: 重复是万恶之源，相信大家都有比较深刻的认识。客观来讲，这一点却是非常难以达到的。因为重复除了显而易见、赤裸裸的躺在哪儿的外，还有很多变体，比如：算法重复、功能重复、结构重复等。做到没有重复，至少需要两方面的功力：识别出；消除它。识别需要有比较好的嗅觉，能够嗅到代码中的坏味道；消除的方法较多，可以使用继承、多态、模板、宏等手段消除，需要根据具体的场景平衡使用，这点也考验开发人员背上的工具箱里，到底有多少工具。另外，《CleanCode》中推荐大家写小的函数，小类，其实我们完全没有必要刻意而为之，消除重复，函数与类自然变小。
 
3>. 表达作者的意图：是从代码的可理解性上着手的。有一些统计数据说代码写的时间与读的时间的比例大概为1：10。代码更多的是写给人看的，代码写的越容易理解，就越能节省读代码花费的时间，从而减少缺陷和沟通成本，缩减维护成本。好的意图可以通过好的命名、清晰的代码风格、良好的测试用例（用例即文档）等手段达到，然而关键的却是在乎：对自己手艺的在乎，对别人读代码时的关心。
 
4>. 尽量少的类和方法：这一点促使四原则构成一个完整的辩证体系，前三点主要讲设计要正确、易修改、易理解，这点却是防止大家做过。简单就是不多，也不少，目前为止刚刚好。它要求我们不能教条主义，死板硬套各种技巧，而是灵活使用，保持简单、精干。
 
原则处于Xp价值观和实践的中间位置，基于这些原则衍生出很多实践模式和设计模式，供大家选用。