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

    最近这一段时间园子里面有关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框架始终尊崇这一哲学,框架追求的目标是简单与效率的平衡,这种平衡犹如太极图

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:

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

 

posted on 2020-09-15 18:04  深蓝医生  阅读(1812)  评论(42编辑  收藏

导航