前言
在前面關於ScalableIO的博客中我提到程序設計其實是一門管理科學，好的軟件架構是在構建一個好的管理模型。有讀者給我私信希望我就軟件架構與管理這個話題展開聊一聊。這個需求真是不好接。因爲在這個方面，之前我只是抓住了一些零散的感悟，並沒有形成一個系統的思考。這個星期我也嘗試着把這些零散的點串聯起來，同時查閱了一些資料，總結了這樣一篇博客。
定義
要探索兩個事物之間的聯繫，我認爲首先要理解他們的定義。很可惜，我沒有找到公認的絕對權威的定義。藉助搜索引擎找到幾個我認爲比較靠譜的解釋。
關於管理的解釋：
-
廣義的管理是指應用科學的手段安排組織社會活動，使其有序進行。狹義的管理是指爲保證一個單位全部業務活動而實施的一系列計劃、組織、協調、控制和決策的活動。
-
所謂管理，是指同別人一起，或通過別人使活動完成得更有效的過程。
關於軟件架構的解釋：
-
軟件架構是指一個系統的基礎組織，它具體體現在：系統的構建，構件之間、構件與環境之間的關係，以及指導其設計和演化的原則。（IEEE1471-2000）
上面都是教科書式的條款，乍一看好像沒什麼營養，似乎都是人人都知道的道理。因爲要寫這篇博客的關係，我認真地對這些概念進行了思考和資料搜索。我圈幾個點，後面詳細解釋的時候會用到。分別是組織，構件，協調，決策，變化。這些關鍵字都是從上面提取出的，下面我們一起來看一下，這兩者之間有什麼聯繫。
組織
我這裏說的組織是一個動詞。就是將一組對象聚集起來，爲了同一個目標去做事。在管理中這個組織的對象是人或者部門。在軟件架構中組織的對象是構件（模塊）。這兩者差別看似很大，因爲人是有自己的思想和情緒的，而代碼是沒有自己的思維的，如何能夠相提並論。是的，由於組織的對象不同，所以我們在實施過程中所使用的技巧，需要的能力，知識，肯定是不一樣的。但是我認爲從實施準則上來說，兩者是一致的。下面我們就來具體說說。
切分
組織行爲是對一系列對象實施的。那麼對於組織者來說是不是應該先決定一下每個對象的職能是什麼，到底需要多少個對象。這就是功能切分。對於管理來說，就是要決定用多少人，每個人做什麼事情。對於軟件架構來說就是要決定系統劃分爲多少個模塊，每個模塊的功能是什麼。那麼這個劃分的準則是什麼？這就要回歸到組織活動的目的。
對於管理來說，目的是降低成本提升效率。如何提升效率，我認爲應該是專注和專業（可以參考流水線生產模式）。幫助個體劃分一個simple和clean的職能，能夠幫助他提高專注度，最大化生產效率，而且能夠提升生產質量。因爲專一所以高效，因爲專注所以專業，因爲專業所以質優。所以爲了追求極致的效率，管理劃分的準則是專一。
對於軟件架構來講，目的是幫助軟件系統更好的應對環境的變化，嗯，是更好的應付產品經理。他的模塊劃分的基本準則就是我們常說的那句高內聚低耦合。高內聚就是專一。一個模塊內部封裝同一類別的功能，同一類功能也一定要放到同一個模塊內部避免實現分散，這就是高內聚。這樣在應對未來的變化時，我們才能夠以最小的變化代價去滿足產品的需求。
可見在劃分活動中，雖然各自的目的不同，但是管理和軟件架構所依賴的基本準則是一致的，就是專一。
組合
有切分必然有組合，組合就是爲了形成切分個體的最大合力。迴歸到管理提升效率的目的上來。如何提升，我認爲應該是簡化，就是個體之間需要對接的內容越少越好，這樣才能降低溝通成本。將每個個體之間的交互依賴降到最低，幫助個體更專注更高效（構建一個獨立的執行環境）。可以通過兩個手段，首先在邊界劃分的時候就簡化和明確邊界。第二個是將對接的功能進行聚焦，如果邊界實在無法簡化，則可以將邊界對接的職能聚焦到獨立個體身上，從而保證大部分個體的專注。
對於軟件架構來講，組合的基本準則就是低耦合。低耦合的目的就是減少模塊與模塊之間的接口依賴。將模塊之間的依賴以數量有限的標準接口的形式定義出來。通過標準接口依賴的方式能夠幫助我們在軟件變化的過程實現模塊的插拔式替換，從而更靈活的應對環境的變化。
可見在組合過程中，兩者的基本準則都是簡化連接。對於管理來說這樣可以降低溝通協作成本提升協作效率，對於軟件架構來說可以降低模塊替換成本提升架構靈活性。
變化
阿里有一句土話叫做“唯一不變的就是變化”，相信很多人都聽說過。所以變化是常態，外部環境，需求變化了，我們的管理流程和系統架構也要隨之變化。爲了應對變化，要勇於“及時重構”。沒有一個人能夠看到未來，因此在管理流程和系統結構上總是會有缺陷。當發現不能適應新的環境，或者感覺到應對吃力的時候。我們的組織架構，系統架構都要及時重構。阿里的逍遙子曾經說“我們總是在最好的時候變陣”，這裏的變陣就是管理重構。對於軟件架構來說及時重構更是一個基本準則（推薦一本《讀代碼大全》）。
說了這麼多空話，來結合Web開發中MVC分離的思想，來對比介紹一下。我們知道MVC分離的思想是一套非常成熟的Web層次劃分準則。其中DAO層與業務解耦就是非常重要的設計。但是我之前看到一些工程師在開發過程中違背了這一準則。將大量的業務邏輯下沉到DAO層，通過SQL的方式實現一些業務關聯邏輯（通過多表JOIN 的方式）。這種方式違背了分層思想。一旦外部環境發生變化，比如說數據量激增需要進行分庫分表操作或者要切換到NOSQL數據庫，這種實現方式就會被徹底顛覆，重構代價很大。更進一步分析，這個實現有一個潛在的邊界連接關係。就是數據庫性能的影響。一類複雜的耗時的業務SQL，可能會將其他業務的數據庫請求BLOCK，造成大面積的業務超時。這就是因爲設計者違背了模塊劃分儘量單一，模塊間連接儘量少的設計原則導致的。
後話
最近翻看一些資料發現我這裏的比較還是很片面的一部分。這裏主要還是從做事的角度來進行分析的。實際的管理還涉及很多方面，比如個體熱情激發，能力培養等等多個方面。除了做事，管理還需要考慮個體的情緒，能力等等。而在軟件架構中，還要考慮使用技術的物理邊界，這也導致兩者在執行和決策時需要不同專業能力。
以上是我結合軟件架構設計中的一些感悟進行的簡單分析，有點牽強附會了，歡迎大家交流。再次推薦《讀代碼大全》。
