不評刪帖是非，只說「簡單便是美」，對代碼徹底掌控的重要性！

    最近這一段時間園子裏面有關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：

本文的中心思想是討論【「簡單便是美」，對代碼徹底掌控的重要性！】這個觀點，而不是討論刪帖是非問題，然而評論區的話題被人帶偏。前面開篇就說了要不要刪帖是別人的權力，愚沒有指責對方的意思，甚至要感謝對方給了愚寫此文的契機。愚都沒有討論這個刪帖是非問題，因此請你們也不要激動，讀文章抓住重點，找到中心，謝謝！