把方案一简再简
在设计复杂系统时使用此原则简化方案的范围、设计和实施。在(编程或者计算)资源有限的情况下设计复杂系统或产品时使用。
有时咋们会告知客户,相对该原则,要问3个如何”,即如何简化范围,如何简化设计,如何简化实施。
1.如何简化范围
这样的问题的答复是:经常应用帕累托法则(也称为80-20法则)。80%的成果来自于20%的工作吗?相对咋们的情况,直接问80%6的收入来自于20%的基本功能吗”。少做(只做20%的工作)多得(获得80%的收益你的开发组就能有時间做其他的事情了。假如去除产品中不用要的基本功能,那么你的工作效率就能提高5倍,产品的复杂度也会大大减小。假如只有1/5的基本功能,那么毫无疑问,基本功能之间的依赖关系就会减少,从而扩展起来更简单,扩展成本也会更低。此外,节省下来的809%的時间既可以用于开发新产品,也可以用于事先考虑产品将来的扩展需求。
不止是咋们在思考如何在减少不用要基本功能的同时保留主要基本功能。37signals中的好多人对此方法都很拥护,他们在自个的书《重来》(Rework2)和博客YouCanAlwaysDoLess”(你可以做得少一点) 中都讨论过减少工作的必要性和所提供的好处。事实上,最小可行产品”这一概念是由EricReis提出,由MartyCagan传播开来的,它的依据是用最小的努力获得最有效的客户需求”这一理念。这种敏捷开发方法使咋们可以迅速地发布简单且简单扩展的产品。如此咋们的公司就可以获得更大的产品生产力(公司可扩展性),把時间用于构建少数有更高可扩展性的产品上。通过简化范围,咋们将具有更高的计算能力,同时工作得更少。
2.如何简化设计
范围缩小后,简化实施的工作就变得简单了。简化设计与过度设计的复杂度紧密相应。减少复杂度是删除工作中不用要的部分,而简化则是要找到一条捷径。在原则1中举过一个例子,把se1e1lct(大)fromschema_name.tabe_name改为为select(co1umn)fromschemaname.tabe_name,只查询你必须要的结果。简化设计的方法则建议咋们最先看一看要查询的信息是不是已经存在于本地资源(例如本地内存)中了。减少复杂度是为了减少工作量,而简化设计是为了工作得更快更简单。
假设咋们要读一部分源数据,对这些源数据中的中间令牌开展计算,然后把这些令牌绑定起来。在很多情况下,这样的假设中的每个动作都可以被分解成一系列服务。事实上,这种方法和流行的Map-Reduce算法采用的方法类似。这种方法并不过度复杂,故此不违背原则。不过假如咋们知道要读的文件很小,不必须要跨文件绑定令牌,那么开发一个简单的整体式的应用,比把它分解为多个服务更合理。再看一看前面的打卡系统的例子,假如目的只是计算每个员工的工作时长,那么用多个克隆的整体式应用读打卡系统的队列并执行计算则更合理。简而言之,简化设计这一步会需求咋们用一种简单理解、低成本、可扩展的方法来完成工作。
3.如何简化实施
最后,来讲看实施的问题。与原则2(实现可扩展性的D-I-D方法)致,这里的实施定义为解决方案的具体编码工作。此日时要面临的问题是用递归还是循环更合理?应该定义一个固定大小的数组,还是应该在必须要时动态分配内存?应该开发一个解决方案,还是应该采用开源的解决方案,还是应该购买一个解决方案?这些问题有一个相同的考量,即如何利用他人的经验和现有的解决方案来简化咋们的实施。
考虑到咋们不可能事事精通,故此最先应该查查找能符合咋们需求的、被广泛采用的开源解决方案或者第三方解决方案。假如没有这样子的方案,应该在公司内部询问能否有人已经开发了能解决该问题的可扩展方案。假如没有专用的解决方案,那么应该再从外部寻找,能否有人描述过解决该问题的可扩展方法,而且咋们可以合法地复制或模仿?只有当这三种条件都不成立时,才应该尝试自个解决该问题。最简单的网站开发实施方法全是已经被实施过且被证明是可扩展的方法。
本文章由新概念互动原创,如没特殊注明,转载请注明来自:http://www.jianzhan0.com/jingyand/72166.html