#legoo內核# -- 準則一 ：小便是美

      從目前社會的發展可知，隨着社會的不斷進度，分工也越來越精細，這種來自社會發展的規則也一樣適用於軟件架構設計。SOA其實就是在模擬社會的一種分工精細框架的投影，業務成熟度越高，SOA體現的價值就愈大，反之則價值體現愈小。我寫這段開場白的目的其實就是想說明，基於軟件架構而言，軟件架構的進化過程與社會的工業化進程有着驚人的類似之處，而 #legoo內核# 的定位是模擬 工業化下的流水線做業模型。正如 文章的標題，「小」表明着每一段有效的代碼都是獨立的流水線上的一個節點，功能單一但絕對高效，而且能夠隨處複用。
      若是你準備開始編寫一個程序，首先要作的就是勾勒一個完整的程序流程圖，下一步則是對流程圖進行修飾，保證流程圖上的每個節點儘量的功能單一而且可複用，讓節點成爲業務數據的加工場與過濾器。做爲一個傳統的架構師，心中確定懷着一個編寫偉大程序的渴望，可是在真正的投入項目研發時，卻要花費數週甚至幾個月的時間去從零開始構思一個完整的項目解決技術方案，然這種方案是不可取的，其實在我現實的世界中，只要把一些小巧的解決方案組合起來，幾乎能夠解決90%以上的問題，好像到如今讀者依舊沒法體會 基於 小 的思惟模式如何進行流水線設計？下面用一個很傳統的程序例子來講明。
      任何一個懂電腦的人，都知道文件複製吧，也就是用戶把一個文件從一個文件夾複製到另一個文件夾抑或在同一文件夾複製，貌似如何簡單的一步操做，若是我做爲操做系統的複製流程設計，那麼我要用以下的一種思路來對拷貝的過程進行分解，從而完成最終的拷貝，整個流程按照序號依次進行：
       一、要求用戶選中所要複製的文件
       二、檢查源文件是否被鎖定，若是鎖定則提示用戶沒法完成複製
       三、檢查目標文件是否存在（複製的目的文件夾）
       四、若是存在同樣的文件，諮詢用戶是否要進行覆蓋抑或取消複製操做
       五、對文件加鎖，而且讀入文件信息。
       六、若是文件內容爲0字節，則提示用，是否繼續 或者退出複製
       七、申請內存，隨機讀取指定大小的文件塊
       八、建立目標文件，而且寫入文件內容，知道源文件讀取完畢
       九、關閉IO流
       十、提示用戶複製成功
       若是做爲linux的話，可能還會加入當前用戶對文件的 讀寫權限的過程，window下則能夠忽略這一過程，一個文件的複製，只有在第七、8步纔是真正的執行復制操做，而其餘的流程節點則是在爲複製進行合法性過濾以及對複製結束的後臺動做進行收尾處理，若是你是一名程序員的話，你可能會發現，其餘的幾個步驟也能夠適用於除了文件複製以外的其餘任務，例如文件 剪切 操做。
       上面的每個節點均可以做爲一個獨立的程序片斷去設計，每個片斷的存在並不關心本身到底在作神馬動做（複製 or 剪切），他只聚焦於本身自己的功能，例如 第3步：檢查一個文件是否存在，他僅僅須要一個文件路徑參數便可，也不關心他的下一步要幹嗎，這就是  小 的優雅之處。
      整個流程是基於必定的規則組裝而來的，相似於SOA下的bpel流程設計，但這是基於程序片斷的一種流程組裝，「等一下」也許讀者會這樣子想， 這些複雜的程序如何能按照必定的規則去運做，入參如何控制。。。諸如此類的問題，這一章節不討論這些，文章主要是向你們闡述明白  小 的這種思惟模式與方法論。
      本人也認可，就程序片斷而言，完成的功能很簡單也很單一，可是把這些簡單的功能組裝在一塊兒，你就會體現到他的強大之處，總體功能大於局部功能的簡單疊加。任何大型任務均可以按照這種思惟模式 進行 「小」的設計與分解。這讓我想起 本山大叔的一個小品，大意是這樣子的：動物園開會，大象沒來 。。。。請問，把大象關冰箱須要分幾步。。。 看到了吧  程序源自生活，打開冰箱 與關上冰箱 是可複用，把任何東西放進去都須要這兩個動做，因此要把這兩個動做單獨剝離出來設計，化整爲零大法啊。。。。。
      從專業的角度來看待這個問題，首先小程序總完成既定的u，不存在二義性，這樣子在任何地方複用，升級均可以保持他功能的惟一性，而不是一個函數同時要完成幾項不一樣的業務處理，這種貧血設計是嚴格不建議使用的，從維護的角度來看待問題：大程序相對複雜一些，也給人們帶來了理解的障礙，程序的規模越大，就愈加背離了架構師的初衷，代碼的行數也會成爲維護人員的噩夢，1000行的代碼是什麼概念，~~~ 寫這種代碼的程序員 要好好地反思反思了。固然，任何業務也許總會出現一些讓人難以理解的業務與程序，無論她的規模大小，這是由於自己他們的執行的功能就很難懂，可是這樣的程序必經是少數，本人很推崇 8/2 法則，一個框架能解決80%的問題，那就足夠了，剩下的20% 則徹底能夠特殊化處理。對於通常的初級、中級程序員而言，小的程序是容易看懂的，先對於大程序而言，商家的維護成本能夠下降。
     小程序從維護和優化角度講，都是值得推崇的，這一點我很堅信，若是出現 單點的故障，能夠很快找到一個代替的方案去替換他，而無需驚動整個業務流程，抑或優化，抑或替換，惟一影響的就是節點本身。
     從內存使用角度看，小的程序對於內存消耗更加具備優點，由於他們短小，因此運行時佔用內存很小，執行完則可徹底釋放內存。這大大下降了程序持有內存的時間，下降了內存交換與分頁的請求，若是對於Java程序而言，內存的回收是影響性能的很大因素，小的程序能夠下降JVM對內存回收的計算深度，便於jvm更好地進行內存回收。
     小程序更加容易被複用，小 設計的目的就是爲了複用，越大的東西越不容易複用，在現實的世界中，也是這樣子的。有小程序組裝的業務流程更加能適應多變的業務，由於每一個小程序之間的鏈接是基於某種契約配置的，而不是基於硬編碼 鑄就的（可能會犧牲一些性能，依舊用8/2法則來回答 哈哈）。
     經過我這幾年的不斷積累，愈來愈喜歡把程序往 小 的方面切割，隨着項目的不斷壯大，感受本身越遊刃有餘。樂高積木 就是一個偉大的發明，由於我創造的積木形狀越多，後期可服用的也越多，感受本身 是 活字印刷術 通常了 ~~ 神奇~~~~
   讓每一個程序片斷只完成一個功能，儘可能保持入參 與 出參的簡潔性。小程序從設計到編寫 到維護，都有無比擬的優越習性，對將來業務發展的包容性將更加好，能夠應對未來更加複雜的業務，作出較好的應對。

   讓每個程序只作好一件事    這就是  小  的內涵，也是我結尾要說的一句話。 
       如今時間  23：47 分，關於 小 既是美的話題 就此打住， 洗漱休息。一我的的家  顯的格外的冷清~~~~~~