最近這一段時間園子里面有關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輪子的意思，希望大家仔細讀讀我文章內容，多多思考，如果是因為愚的表達能力沒有把問題說清楚導致的誤會，誠懇的給大家道歉，愚本不才，能力有限，所以自稱愚便是此意，再次謝謝大家的支持！
PS：
本文的中心思想是討論【“簡單即是美”，對代碼完全掌控的重要性！】這個觀點，而不是討論刪帖是非問題，然而評論區的話題被人帶偏，前面開篇就說了要不要刪帖是別人的權力，愚沒有指責對方的意思，甚至要感謝對方給了愚寫此文的貧訓，愚都沒有討論這個刪帖是非問題，所以請大家也不要激動，讀文章抓住重點，找到中心，謝謝！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/65773.html
標籤：架構設計
下一篇：JavaScript（基礎、高級）學習筆記匯總表【尚硅谷最新版JavaScript基礎全套教程完整版(140集實戰教學,JS從入門到精通)】