不评删帖是非，只说“简单便是美”，对代码彻底掌控的重要性！
最近这一段时间园子里面有关ORM的话题被某大佬连续发的有关他的ORM框架的文章带火了，不能不说不只做者的框架备受推崇，源码Star不少，做者的文章话题带动能力也强，其中一篇文章回帖操过100楼。愚做为早期ORM框架开源的一员（PDF.NET，后来更名SOD），去捧场观战天然责无旁贷，在与园友回帖讨论过程当中不免会提到本身的框架，无奈被原文做者以广告嫌疑删帖了，辛苦码字的回帖说删就删，尽管愚一开始就申明SOD框架不只仅是一个ORM框架，它是一个简单的但又全功能数据开发解决方案，可是别人家的地盘别人作主，愚也很差指责什么，各人有各人的是非标准，别处不能说，索性就本身发一篇随笔，来讲说愚认为的重要问题：“简单便是美”，对代码彻底掌控的重要性！html
实际上，这个观点不是我独有，也不是我原创，至因而谁最早这样说的无从考证，那么就只好看谁“志同道合”了，很幸运在上面说的某大佬文章回帖中，就有这样一位朋友，请看下图：程序员
幸亏愚认为这个观点很重要，就截图在个人QQ群里面分享了，要否则这个回帖被删了甚是惋惜。下面文字是上面图片的内容，贴出以下：算法
引用--------------------------------------
@架构师修行之路
作了这么多年，始终以为，对于数据库持久化而言，简单即时美，彻底掌控才是王道。用过ef，不太喜欢，一个简单的sql须要胚子和很多东西，可能我已经老了吧
回帖---------------------------------------
高度赞同，简单就是美，彻底掌控才是王道，这也是SOD框架的设计哲学。在Java开发领域，Hibernate不可谓不强大，然而不少开发员主要用的是mybatis就很能说明问题，Hibernate对于大多数Java开发人员而言太复杂了。sql
回到正文，为何说简单就是美，彻底掌控才是王道。简单的东西才容易驾驭，才容易彻底掌控；彻底掌控的事情才能最大程度保证成功而不依赖来运气和人品。这个道理其实不只仅是对数据库持久化而言，对软件项目，对任何事情都是成立的。数据库
以前园子里面有一篇文章《[漫谈] 软件设计的目标和途径》，做者说到：“软件设计的目标是避免软件的失控。那么是什么东西致使的失控? 你面临的业务太复杂？项目遗留的代码太烂？团队成员水平良莠不齐？工期太紧张致使你无暇作设计规划？也许吧，这些或多或少都确实是已经存在的事实。”通过一番分析，做者得出结论：“因此是什么致使的失控？现存的无力维护(bug、新功能都是维护)的代码致使的失控，同时这也是失控的表现结果。那么你为何会无力维护这些代码，由于它的真实行为和你理解的行为出现了误差，你以为它不可控了。这时候就是真的失控了，代码烂不烂其实并非重点，只要你还能维护，这些都不是问题。”编程
对这个观点，愚很认同，之前愚也经常维护别人写的遗留项目，那种填别人挖的坑的感受确实很无力，一个看似很小的Bug牵一发而动全身，寻找蛛丝马迹犹如大海捞针，有时候这种Bug看起来就像是“薛定谔的代码”--测试说有Bug而你怎么都不能复现，Bug修复了好像又没有修复。若是这种代码太多了或许这个项目真的就失控了，这种事情就曾经发生在笔者身上过，还好老板英明，又把原开发人员请回来兼职一段时间给咱们讲解系统到底有那些坑，找到了雷修复起来就很快了。这个案例说明，之因此很难维护别人的遗留系统，是由于你难以在有效的时间内彻底掌控系统，对系统的设计原理和代码运行流程不熟悉，也就不了解现有系统设计和代码的缺陷在哪里，总之就是这个系统对于你来讲太复杂了，没法彻底掌控；若是是你设计开发的系统，你熟悉全部的细节，那么你会说“这个很简单”，“那也很简单”是否是？你没有说过这样的话也必定听别人说过这样的话。因此在必定程度上，“简单”就等于“彻底掌控”，你能彻底掌控那就是简单，但你认为简单别人不必定以为简单，因此要让大多数人都以为简单的事情，就变得很是不简单了。著名科学家霍金有句名言：多写一个公式就会吓跑一半读者。霍金在他的科普书里面几乎没有使用多少公式，将复杂的宇宙科学讲得人人都能看懂，将宇宙写得美轮美奂，他写的《时间简史》火爆全球，销量经久不衰。愚认为“简单就是美”必定是霍金写科普书的“写做哲学”；一样，愚也将“简单便是美"始终做为SOD框架的设计哲学--一个不须要反射、不依赖.NET高级特性（好比LINQ）、核心组件不依赖第三方框架，极度精简的数据开发框架。缓存
世界上有两件最困难的事情：一个是你把你口袋里面的钱放到我口袋里面来，一个是我把我脑壳里面的想法放到你脑壳里面去。因此对本文的观点你确定不会那么容易相信，毕竟这是最困难的事情之一。若是你不信，请继续听我说。网络
话说一图胜千言，图样图森破，先看下图：mybatis
（图片来自网络，侵删）架构
上面是文章《“越复杂越不稳定”》的插图，不规则的石头一层堆砌一层，愈来愈高愈来愈小，总以为风雨飘摇，相反若是石头堆砌矮一点就一两层，或者石头结构标准四四方方，这堆石头就很稳定。堆砌的层数少咱们堆砌石头的工做简单，石头结构标准也就是石头形状简单，简单的方式让咱们对堆石头这件事情上能彻底掌控，这堆石头就能很是稳定而屹立不倒。文章说道：“咱们地球出现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轮子的意思。但愿你们仔细读读我文章内容，多多思考。若是是由于愚的表达能力没有把问题说清楚致使的误会，诚恳的给你们道歉，愚本不才，能力有限，因此自称愚即是此意，再次谢谢你们的支持！
PS：
本文的中心思想是讨论【“简单便是美”，对代码彻底掌控的重要性！】这个观点，而不是讨论删帖是非问题，然而评论区的话题被人带偏。前面开篇就说了要不要删帖是别人的权力，愚没有指责对方的意思，甚至要感谢对方给了愚写此文的契机。愚都没有讨论这个删帖是非问题，因此请你们也不要激动，读文章抓住重点，找到中心，谢谢！