有时我们会告诉客户，对于该原则，要问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算法接纳的方式类似。这种方式并不过分庞大，以是不违反原则。然则若是我们知道要读的文件很小，不需要跨文件绑定令牌，那么开发一个简朴的整体式的应用，比把它分解为多个服务更合理。再看看前面的打卡系统的例子，若是目的只是盘算每个员工的事情时长，那么用多个克隆的整体式应用读打卡系统的行列并执行盘算则更合理。简而言之，简化设计这一步会要求我们用一种容易明白、低成本、可扩展的方式来完成事情。
(责任编辑：网络)
评论列表