在设计复杂系统时使用此原则简化方案的范围、设计和实施。在(编程或者计算)资源有限的情况下设计复杂系统或产品时使用。

有时我们会告诉客户，对于该原则，要问3个“如何”，即如何简化范围，如何简化设计，如何简化实施。
 
1.如何简化范围

这个问题的答案是:经常应用帕累托法则(也称为80-20法则)。80%的成果来自于20%的工作吗?对于我们的情况，直接问“80%6的收入来自于20%的功能吗”。少做(只做20%的工作)多得(得到80%的收益你的开发组就能有时间做其他的事情了。如果去除产品中不必要的功能，那么你的工作效率就能提高5倍，产品的复杂度也会大大减小。如果只有1/5的功能，那么毫无疑问，功能之间的依赖关系就会减少，从而扩展起来更容易，扩展成本也会更低。此外，节省下来的809%的时间既可以用于开发新产品，也可以用于提前考虑产品将来的扩展需求。



不止是我们在思考如何在减少不必要功能的同时保留主要功能。37signals中的很多人对此方法都很拥护，他们在自己的书《重来》(Rework2)和博客“You Can Always Do Less”(你可以做得少一点) 中都讨论过减少工作的必要性和所带来的好处。事实上，“最小可行产品”这一概念是由 Eric Reis提出，由 Marty Cagan传播开来的，它的依据是“用最小的努力得到最有效的客户需求”这一理念。这种敏捷开发方法使我们可以快速地发布简单且容易扩展的产品。如此我们的公司就能够得到更大的产品生产力(公司可扩展性)，把时间用于构建少数有更高可扩展性的产品上。通过简化范围，我们将具有更高的计算能力，同时工作得更少。

2.如何简化设计

范围缩小后，简化实施的工作就变得容易了。简化设计与过度设计的复杂度紧密相关。减少复杂度是删除工作中不必要的部分，而简化则是要找到一条捷径。在原则1中举过一个例子，把se1e1lct(大)from schema_name.tabe_name改为为 select(co1umn) from schema name.tabe_name，只查询你需要的结果。简化设计的方法则建议我们首先看看要查询的信息是不是已经存在于本地资源(例如本地内存)中了。减少复杂度是为了减少工作量，而简化设计是为了工作得更快更容易。

假设我们要读一些源数据，对这些源数据中的中间令牌进行计算，然后把这些令牌绑定起来。在许多情况下，这个假设中的每个动作都可以被分解成一系列服务。事实上，这种方法和流行的Map-Reduce算法采用的方法类似。这种方法并不过度复杂，所以不违背原则。但是如果我们知道要读的文件很小，不需要跨文件绑定令牌，那么开发一个简单的整体式的应用，比把它分解为多个服务更合理。再看看前面的打卡系统的例子，如果目的只是计算每个员工的工作时长，那么用多个克隆的整体式应用读打卡系统的队列并执行计算则更合理。简而言之，简化设计这一步会要求我们用一种容易理解、低成本、可扩展的方式来完成工作。

3.如何简化实施

最后，来看看实施的问题。与原则2(实现可扩展性的D-I-D方法)致，这里的实施定义为解决方案的实际编码工作。此日时要面临的问题是用递归还是循环更合理?应该定义一个固定大小的数组，还是应该在需要时动态分配内存?应该开发一个解决方案，还是应该采用开源的解决方案，还是应该购买一个解决方案?这些问题有一个相同的考量，即如何利用他人的经验和现有的解决方案来简化我们的实施。

考虑到我们不可能事事精通，所以首先应该查查找能满足我们需求的、被广泛采用的开源解决方案或者第三方解决方案。如果没有这样的方案，应该在公司内部询问是否有人已经开发了能解决该问题的可扩展方案。如果没有专用的解决方案，那么应该再从外部寻找，是否有人描述过解决该问题的可扩展方法，而且我们可以合法地复制或模仿?只有当这三种条件都不成立时，才应该尝试自己解决该问题。最简单的网站建设实施方法都是已经被实施过且被证明是可扩展的方法。