不评删帖是非，只说“简单即是美”，对代码完全掌控的重要性！

不评删帖是非，只说“简单即是美”，对代码完全掌控的重要性！

    最近这一段时间园子里面有关ORM的话题被某大佬连续发的有关他的ORM框架的文章带火了，不能不说不仅作者的框架备受推崇，源码Star很多，作者的文章话题带动能力也强，其中一篇文章回帖操过100楼。愚作为早期ORM框架开源的一员（PDF.NET，后来改名SOD），去捧场观战自然义不容辞，在与园友回帖讨论过程中难免会提到自己的框架，无奈被原文作者以广告嫌疑删帖了，辛苦码字的回帖说删就删，尽管愚一开始就申明SOD框架不仅仅是一个ORM框架，它是一个简单的但又全功能数据开发解决方案，但是别人家的地盘别人做主，愚也不好指责什么，各人有各人的是非标准，别处不能说，索性就自己发一篇随笔，来说说愚认为的重要问题：“简单即是美”，对代码完全掌控的重要性！

    实际上，这个观点不是我独有，也不是我原创，至于是谁最先这样说的无从考证，那么就只好看谁“志同道合”了，很幸运在上面说的某大佬文章回帖中，就有这样一位朋友，请看下图：

    幸好愚认为这个观点很重要，就截图在我的QQ群里面分享了，要不然这个回帖被删了甚是可惜。下面文字是上面图片的内容，贴出如下：

引用--------------------------------------
@架构师修行之路
  做了这么多年，始终觉得，对于数据库持久化而言，简单即时美，完全掌控才是王道。用过ef，不太喜欢，一个简单的sql需要胚子和不少东西，可能我已经老了吧
回帖---------------------------------------
高度赞同，简单就是美，完全掌控才是王道，这也是SOD框架的设计哲学。在Java开发领域，Hibernate不可谓不强大，然而很多开发员主要用的是mybatis就很能说明问题，Hibernate对于大多数Java开发人员而言太复杂了。

    回到正文，为什么说简单就是美，完全掌控才是王道。简单的东西才容易驾驭，才容易完全掌控；完全掌控的事情才能最大程度保证成功而不依赖来运气和人品。这个道理其实不仅仅是对数据库持久化而言，对软件项目，对任何事情都是成立的。

    之前园子里面有一篇文章《[漫谈] 软件设计的目标和途径》，作者说到：“软件设计的目标是避免软件的失控。那么是什么东西导致的失控? 你面临的业务太复杂？项目遗留的代码太烂？团队成员水平参差不齐？工期太紧张导致你无暇做设计规划？也许吧，这些或多或少都确实是已经存在的事实。”经过一番分析，作者得出结论：“所以是什么导致的失控？现存的无力维护(bug、新功能都是维护)的代码导致的失控，同时这也是失控的表现结果。那么你为什么会无力维护这些代码，因为它的真实行为和你理解的行为出现了偏差，你觉得它不可控了。这时候就是真的失控了，代码烂不烂其实并不是重点，只要你还能维护，这些都不是问题。”

    对这个观点，愚很认同，以前愚也常常维护别人写的遗留项目，那种填别人挖的坑的感觉确实很无力，一个看似很小的Bug牵一发而动全身，寻找蛛丝马迹犹如大海捞针，有时候这种Bug看起来就像是“薛定谔的代码”--测试说有Bug而你怎么都不能复现，Bug修复了好像又没有修复。如果这种代码太多了或许这个项目真的就失控了，这种事情就曾经发生在笔者身上过，还好老板英明，又把原开发人员请回来兼职一段时间给我们讲解系统到底有那些坑，找到了雷修复起来就很快了。这个案例说明，之所以很难维护别人的遗留系统，是因为你难以在有效的时间内完全掌控系统，对系统的设计原理和代码运行流程不熟悉，也就不了解现有系统设计和代码的缺陷在哪里，总之就是这个系统对于你来说太复杂了，无法完全掌控；如果是你设计开发的系统，你熟悉所有的细节，那么你会说“这个很简单”，“那也很简单”是不是？你没有说过这样的话也一定听别人说过这样的话。所以在一定程度上，“简单”就等于“完全掌控”，你能完全掌控那就是简单，但你认为简单别人不一定觉得简单，所以要让大多数人都觉得简单的事情，就变得非常不简单了。著名科学家霍金有句名言：多写一个公式就会吓跑一半读者。霍金在他的科普书里面几乎没有使用多少公式，将复杂的宇宙科学讲得人人都能看懂，将宇宙写得美轮美奂，他写的《时间简史》火爆全球，销量经久不衰。愚认为“简单就是美”一定是霍金写科普书的“写作哲学”；同样，愚也将“简单即是美"始终作为SOD框架的设计哲学--一个不需要反射、不依赖.NET高级特性（比如LINQ）、核心组件不依赖第三方框架，极度精简的数据开发框架。

    世界上有两件最困难的事情：一个是你把你口袋里面的钱放到我口袋里面来，一个是我把我脑袋里面的想法放到你脑袋里面去。所以对本文的观点你肯定不会那么容易相信，毕竟这是最困难的事情之一。如果你不信，请继续听我说。

    话说一图胜千言，图样图森破，先看下图：

    （图片来自网络，侵删）

    上面是文章《“越复杂越不稳定”》的插图，不规则的石头一层堆砌一层，越来越高越来越小，总觉得摇摇欲坠，相反如果石头堆砌矮一点就一两层，或者石头结构标准四四方方，这堆石头就很稳定。堆砌的层数少我们堆砌石头的工作简单，石头结构标准也就是石头形状简单，简单的方式让我们对堆石头这件事情上能完全掌控，这堆石头就能非常稳定而屹立不倒。文章说道：“我们地球出现45亿年，从单细胞动物发展到我们今天，成就了人类和成千上万种生物，但存在更持久的还是最早的单细胞生物，在今天还有存活。而后来演化的很多生物却在这过程逐步灭亡。即便是我们人类号称自己牛逼，也不过是才存在了几十万年，要知道恐龙可是存在了上亿年的历史，但最终也逃不过物种灭绝。这理解起来就是越复杂越不稳定的物种进化案例。”

    不论是小孩过家家堆石头这样的小问题，还是大到生物圈物种灭绝这样的是问题，都说明简单的重要性，越简单越稳定，越复杂越不稳定。这个道理符合大多数人的认知，道理就是这样，之所以让我们认同，就是因为我们看到的现象可以用这个道理来解释。当然这个道理在某些特殊场景下可能不成立，请参考另外一篇文章：《随笔：关于系统稳定性的思考》。这个道理仅仅这样说可能还不够，有很多时候我们“眼见未必为实”，错觉是常见的，所以现代科学更讲究数理逻辑。假设系统整体最佳的稳定性为1，系统由N多节点元素相互依赖而成，系统整体的稳定性由系统内每一个节点的稳定性系数相乘而来。假设每一个节点的稳定性都是0.9，那么2个节点组成的系统稳定性是 0.9 * 0.9 =0.81，10个节点系统稳定性约等于0.3486784401，这么低的系统稳定性肯定没法用了。将系统每一个节点的稳定性提高一个数量级达到0.99，那么2个节点组成的系统稳定性是 0.99 * 0.99 =0.0.9801，10个节点系统稳定性约等于0.904382，看起来系统稳定性还不错，但是如果100个节点系统稳定性将下降到约等于0.36603也变得不可用。

    如上图复杂的系统节点关系，如果一个系统设计成这样，在考虑上面的系统节点稳定性算法，这样的系统几乎就是不可靠性，稳定性非常差，如果一个项目代码是这样，那这样的项目很容易失控。但是一个系统是由简单的节点关系组成，并且节点可以递归定义，即一个节点又是一个简单的子系统，那么系统整体结构上不仅依然很简单，而且这样一种结构图还很优美，如下图：

    如上图，一个规则的六边形结构，通过节点组合的方式，最后组合成了一片优美的类似雪花样子的结构形状，这是不是“简单既是美”很好的例子？无独有偶，在软件领域也有一个“六边形架构”，或者类似的“整洁架构”，又叫“洋葱架构”。有关这些软件架构的介绍，可以参考愚写的新书《SOD框架“企业级”应用数据架构实战》里面的介绍。综上所述，“简单既是美”不管是从人的感性认知，还是从科学的数理逻辑层面，都证明了这是一个“金科玉律”，它跟墨菲定理、二八定律等一样重要，这是人们认识世界、改造世界的最佳实践，放在软件领域，甚至放到前面说的ORM框架设计上，“简单既是美”都应该成为一种设计哲学，SOD框架始终尊崇这一哲学，框架追求的目标是简单与效率的平衡，这种平衡犹如太极图，

体现在：代码的精简，开发、维护的简单与追求极致的运行效率。（详见框架官网）

再回到ORM的话题上，因为开发人员需要完全掌控自己的代码，所以大部分Java开发人员舍弃了功能强大的ORM框架Hibernate转而使用半ORM框架（甚至不能叫ORM）的MyBatis框架，宁愿手写SQL也不愿用全功能的ORM，用这种简单粗暴的方式来快速解决问题，这样别人接手项目也能快速上手而不至于造成项目失控，大家如果不相信这个现象，可以去各大招聘网站看看有关Java技术栈的招聘，不论从Java开发人员还是到JAVA背景的CTO，几乎没有几家要求熟练使用Hibernate的，几乎全部要求熟练掌握MyBatis框架。在Java界如此，那么在.NET界也就能很好的理解为什么.NET的ORM这么多了，因为造一个ORM轮子简单啊，这可能得益于.NET的强大而又好用的特性，微软对开发人员一向是保母型的：）。不过，这也造成一个尴尬的情况，正如下面的朋友说的，我回复了这位朋友，不巧这也被本文开头的那个ORM大佬给删除了，请看当时回帖截图：

回帖内容如下：

引用-------------------
@JulyLuo
  哎，难怪人都说DotNetCore的人都再搞ORM，天天搞这些。。
回复--------------------
这可能是造一个ORM轮子门槛比较低，当然造一个强大的ORM还是不容易，需要时间和作者的毅力，比如像楼主这样的毅力。不过，如果抛开ORM，去审视ORM背后的数据问题，就能发现一片宽阔的天地：数据、数据交互、数据控件、数据绑定、数据的分部、事务/分布式事务、数据同步、数据复制、数据清洗、数据缓存。。。。等等企业级应用开发需要处理的数据问题，SOD框架早就不是ORM框架了，它现在是一个简单的但又全功能的数据开发与架构的解决方案，为此还写了一本书：《SOD框架“企业级”应用数据架构实战》。
----------------------------

    回到正文，上面这位朋友说的的确有这样一个现象，除了前面说的微软是.NET开发人员的保姆使得使用.NET很容易造ORM轮子之外，愚想问大家，绝大多数用.NET的公司为什么用.NET呢？为什么很多国内的公司初创期间用.NET而成熟之后纷纷转投了Java呢？大家可能说这是生态问题，而愚认为，原因不仅如此，.NET容易使用，开发效率高是主要原因，初创公司节约成本是王道，同样的原因，小公司经不起折腾为了确保项目成功，开发简单代码能完全掌控也是项目负责人首要考虑的问题，后期公司成熟稳定了有钱了就可以选择生态庞大技术复杂的JAVA技术栈了，有N多高大上的框架可以来玩，谁还会再去造“很低级”的ORM轮子呢？如果更全面的看，造一个ORM框架技术含量的确比较低，但对于普通的.NET开发人员，他们没有接触大数据、云计算、机器学习、图像识别等等高大上技术的机会，不造ORM轮子还能造什么呢？80%的开发人员天天都在CRUD（请参考《软件开发中的“二.八定律”》之1.2 大部分时间都在做重复的增删改查），也只有ORM轮子是最容易造的了，技术想进步很难，这是.NET开发人员最难越过的坎。这个问题更详细的讨论可以参考我写的《数据背后的二八定律，揭示程序员担忧的主要问题》一文。愚不才，为了解决这个问题写了上面回答JulyLuo的一段话，想告诉大家虽然都是同样每天在解决数据CRUD问题，但是思考角度不一样就能发现另一片广阔的天地，这就是我这本书里面写的全部内容，欢迎了解。

    本来是对某大佬文章读者回帖的一个回复讨论，没想到大佬删除了我的回帖，也算是塞翁失马，于是才有了这篇随笔，告诉大家“简单即是美”，强调对代码完全掌控的重要性，在真正复杂的企业级项目开发中，选择什么框架一定要好好想想你能否完全掌控它，确保项目开发不走弯路，不要为了“面向简历编程”而匆忙上马使用流行的框架技术，如果你不能很好的掌控它，就选择一个简单的框架，或者向领导申请给予足够的技术预研/调研时间。感谢大家的阅读，希望在数据开发领域，SOD框架能成为你正确的选择！

-----------------分界线----------------------

本文发布后，有好几位朋友回帖批评愚说造ORM轮子不高大上的问题，愚认为大家表面上关注是否高大上的问题，本质上是在关注自己技术高低的问题，有没有贬损自己技术能力的意思。这里特别申明一下：

是否高大上 不等于 技术高低

推论：=>

造ORM轮子 不等于 技术低

愚的观点是，是否高大上跟技术高低没有关系，因为前者是一个心态问题，后者是一个技术问题，高大上更多的是跟收入、薪水、社会需求度、社会地位等相关。就像我回帖说的，在招聘市场，大数据、云计算、人工智能、机器学习、图像识别等这些热门技术不仅职位多，并且薪水基本要比普通的CRUD职位高出很多，形成鲜明对比，不信大家可以去招聘网站看看。由于这些热门技术需求量大、薪水又很高，用大家的话来说就是行业风口，高薪+光环，自然就是觉得高大上，不是吗？这不是我一人的观点，也是我跟朋友们交流说到的，见下图：

最后，愚的SOD有ORM功能，愚也算是造ORM轮子的人，怎么可能自己瞧不起自己，说造ORM轮子很低级呢？这逻辑上是说不过去的，愚绝对没有任何贬损大家造ORM轮子的意思。希望大家仔细读读我文章内容，多多思考。如果是因为愚的表达能力没有把问题说清楚导致的误会，诚恳的给大家道歉，愚本不才，能力有限，所以自称愚便是此意，再次谢谢大家的支持！

本文的中心思想是讨论【“简单即是美”，对代码完全掌控的重要性！】这个观点，而不是讨论删帖是非问题，然而评论区的话题被人带偏。前面开篇就说了要不要删帖是别人的权力，愚没有指责对方的意思，甚至要感谢对方给了愚写此文的契机。愚都没有讨论这个删帖是非问题，所以请大家也不要激动，读文章抓住重点，找到中心，谢谢！