技术相关：奥卡姆剃刀在软件设计中的运用

技术相关：奥卡姆剃刀在软件设计中的运用
--王珏原创

    在我的项目经验当中，有很多关于“架构”或者“技术内容”方面的讨论，常常是“公说公有理婆说婆有理”，根本无法达成一致。比如一个常见的场景是，甲说：我这是按照面向对象的思想设计的；乙说：你这个不符合关系数据库的设计准则。最后的结果可能是：
    1、谁的嗓门大，听谁的；
    2、谁的地位高，听谁的；
    3、谁的口才好，听谁的。
    对于正确的答案来说，这显然不是合理途径。

    那么在遇到上述问题的时候，我们又去到什么地方寻找正确的评价准则呢？
    奥卡姆剃刀准则，显然是解决此类问题的利刃。奥卡姆剃刀的解释大约有如下几种：

1. “切勿浪费较多东西，去做『用较少的东西，同样可以做好的事情』”（参见：wiki奥卡姆剃刀）；
2. 简称为“如无必要，勿增实体”（参见：奥卡姆剃刀）。
3. 当你有两个处于竞争地位的理论能得出同样的结论，那么简单的那个更好。（参见：生活中的定律——奥卡姆剃刀定律）

    举例来说， 日心说和 地心说想必大家都已经非常熟悉了，但是我们常常误解的以为“日心说”是正确的； “地心说”是错误的。其实地心说依然可以精确预测行星位置，只不过在行星运行模型中加入越来越多的均轮，和均轮的均轮，和均轮的均轮的均轮。。。。整个计算过程复杂无比，但是仍然可以保持精确。（参见： 奥卡姆剃刀和日心说）。换句话说： 在哥白尼时代，托勒密体系需要77个圆来描述太阳，月亮以及当时所知的5颗行星的运动。如果使用哥白尼的日心说，则只需要34个圆。（参见： 奥卡姆剃刀）

    我对于奥卡姆剃刀最直接的理解就是：“简单，简单，再简单一点”。Raymond的《UNIX编程艺术》一书中也明确指出：“设计要简洁，复杂度能低则低”。
    文章的开头我提到关于“面向对象思想在数据库设计中的问题”，其实操起奥卡姆剃刀，即使没有太多的面向对象或者数据库设计功底也能做出正确的选择： 去选择数据库模型相对简单的方案。如果一定需要找的这方面的根据则： “C++之父Bjarne Stroustrup被问道如何将面向对象的东西放到SQL中时回答：在贝尔实验室，曾经有很多天才对这个问题尝试了4种解决方法，最后得出的结论是不应该这样做。OO对于编程是一个很了不起的想法，但对于数据没有什么用”。
    同样，如果你实在搞不清楚什么“三范式”（如果需要做数据库设计，我建议还是去复习一下比较好）还偏偏要搞什么数据库设计，我的建议是运用 奥卡姆剃刀的简单原则：

1. 保持数据库中的“数据”（占用磁盘空间）尽可能的少。
2. 保持数据库中的“表”尽可能的少。
3. 保持数据库“表”中的“字段”尽可能的少。
4. 1、2、3条均衡使用。
   

    在架构设计时的“层次”概念大概已经深入人心，可问题的关键在于我们总是喜欢设计出太多的层次。就“数据库层”来说吧，常常有：

1. 原始数据层（比如存放网管采集来的数据）
2. 汇聚数据层（据说是提高效率，搞出来的半小时汇聚、2小时汇聚、日汇聚、周汇聚）
3. 展现数据层（据说是为了提高UI界面的客户体验效果）
4. 报表数据层（据说是为了把某些报表需要的数据预先计算好，填入其中）

    正如《网络风格的元素》（ The Elements of Networking Style）一书的作者在另一个略有不同的背景下所说的[Padlipshy]:“如果你知道自己在做什么，三层就足够了；但如果你不知道自己在做什么，十七层也没用。”
    操起奥卡姆剃刀，上述问题其实很好解决： 更少的层次，能够解决问题吗?如果可以，就不需要额外的层次。

    奥卡姆剃刀的“简单原则”在进行业务分析时候也同样锋利，在 需求相关：用时序图并协作图分析客户业务流程 一文中，我根据电信资源配置流程（资源不完全具备的情况）归纳整理出了三种资源配置方法：“逐步配置法”，以及“逻辑配置法”，以及“参考配置法”，显然，一眼就可以看出“参考配置法的协作图”最简单。

新浪地址： 技术相关：奥卡姆剃刀在软件设计中的运用

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/91771/viewspace-609549/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/91771/viewspace-609549/