把计齐整简再简

在设计庞大零碎时运用此准则简化计划的范畴、设计和施行。在(编程或者计较)有限的情况下设计庞大零碎或商品时运用。
有时咱们会通知客户，对付该准则，要问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要领)致，这里的施行界说为解决计划的理论编码事情。这地利要面对的问题是用递偿仍是轮回更合理?应该界说一个固定大小的数组，仍是应该在需求时动态分配内存?应该开发一个解决计划，仍是应该采用开源的解决计划，仍是应该购置一个解决计划?这些问题有一个沟通的考量，即怎样行使别人的教训和现有的解决计划来简化咱们的施行。
思索到咱们不行能事事粗通，以是起首应该查查找能知足咱们需求的、被普遍采用的开源解决计划或者第三方解决计划。若是没有如许的计划，应该在公司内部扣问是否有人曾经开发了能解决该问题的可扩展计划。若是没有专用的解决计划，那末应该再从外部寻觅，是否有人形容过解决该问题的可扩展要领，并且咱们可以正当地复制或仿照?只要当这三种前提都不成立时，才应该测验考试本身解决该问题。最简略的网站建举措措施行要领都是曾经被施行过且被证实是可扩展的要领。