從回帖被刪，再說「簡單即是美」，對程式碼完全掌控的重要性！
最近這一段時間園子裡面有關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框架能成為你正確的選擇！
