企業定製軟體開發的兩個核心問題

企業定製軟體開發不是電腦科學，需要解決的不是編譯原理也不是組合數學。那麼，企業定製軟體開發的核心問題是什嗎？

 

越來越感覺到，從事一個領域不需要有特別深刻的理解，但起碼要知道做這個領域的事情，需要解決的核心問題是什麼。比如說，開發C/S結構軟體，狀態同步（C/S狀態同步以及視窗之間的狀態同步）就是核心問題之一，而開發B/S結構的軟體，狀態同步就不是那麼核心的問題。如果事Crowdsourced Security Testing道需要有這些核心問題需要考慮，在日常應對接踵而來的具體的事務的時候，就能夠把解決問題的層次抬到更宏觀的層面。

 

目前而言，個人感覺企業定製軟體開發的核心問題有兩個：

1、如何保證所有參與者（包括客戶在內的Team Dev，以及終端使用者）的溝通強度，使其能夠滿足完成開發目標的需要

2、如何管理企業定製帶來的軟體自身內在的高複雜度，使得複雜度不會超過團隊的維護能力範圍

 

在前面一篇介紹組織的Blog中，談到了核心問題中的第一個，溝通強度問題。團隊而言，刨去個人能力，最重要的就是人與人之間的溝通。沒有好的溝通，即便團隊的個體能力都超級強，也無法形成合力。但只要有好的溝通，至少可以做到人盡其用。假設一個標準人的生產力是1/day。某些特彆強的人可以達到3/day。但是如果需要達到10/day的生產力才能在市場允許的時間下完成項目，那麼就無法用一個人來完成之間事情，所以才會有團隊存在的必要。但是有兩個標準人，並不會達到1+1=2/day的生產力。可能只有1.5。有三個標準人，更加不會達到1+1+1=3/day的生產力，很有可能有1.8。那麼是什麼制約了團隊的整體生產力，那就是溝通。當兩個相關聯的任務A和B是一個人做的時候，關於任務A的知識存在於左腦，關於任務B的知識存在於右腦。那麼結合兩個任務的知識把其組裝起來的溝通效率就是大腦內部的電訊號的速度。但是如何任務A是由Dev甲完成的，任務B是由Dev乙完成的，那麼整合兩個任務的效率就受到人嘴皮的震動頻率的約束，受到表達能力的約束，受到理解能力的約束。有人研究過，兩個人即便是面對面，傳輸的位元速率也要低於最早的撥號式Modem。更不用說，有的時候Team Dev是分布式的。在無法看到表情，肢體語言，無法共用白板，只能在越洋電話裡聽到聲音，而且其中還有一方是非工作時間，在這種情況下，1+1幾乎很難達到1/day的生產力。什麼是高效的團隊，就是能夠讓1+1的值儘可能大的團隊。如何變得高效，讓溝通變得更加高效。怎麼樣讓溝通變得高效高強度？這就是我們要處理的核心問題。

 

第一個問題可以應用於所有的人的團隊行為之中。人只要聚整合群，就會有溝通問題。所謂，有人的地方就有江湖。第二個問題則特定於企業定製軟體開發。對於互聯應用開發，也許複雜度的管理是其次的，最需要關注的是大使用者量下的可擴充性。但是對於企業定製軟體開發，由於業務自身的複雜度，導致了定製軟體的複雜度。特別是業務的組合，導致的組合複雜性。假設在理想情況下，一個系統可以分解為模組A，B，C，其複雜度都是2。在複雜度管理良好的情況下 ，這些模組是被明確劃分的，要理解A，只需要關注A，以及B與C少量與A互動的部分，也許理解的複雜度只是2 + 0.5.。但是在複雜度沒有管理的情況下，所有的“邏輯”（也就是複雜度）都是隨意地放置的。那麼也就是沒法辦法保證，讀A的邏輯只需要關注A，甚至這個A都是不存在的，你看到的知識一個系統，包含了A，B，C的功能，是完整的一塊。這個時候要真正瞭解這個系統行為，可能就需要2 * 2 * 2 = 8這麼高的代價了。隨著模組（變數，方法，類，包，模組，Bundle）的增加，我們需要同時理解的東西也在不斷增加。不去可以地管理複雜度，很有可能，我們需要瞭解一塊功能，就需要把所有的代碼都去閱讀一遍。或者說，改動了一個方法，使得整個項目都需要重新被測試，因為沒有地方是可以被信任的。如何管理複雜度？這就是我們要處理的核心問題。

 

有意思的事情是，這兩個核心問題是重疊的。把人，角色等同於類，介面，都抽象地看成點。把溝通理解為人與人之間的聯絡問題。把複雜度也理解為類與類的依賴問題。那麼溝通問題和複雜度的管理問題都是如何把這些點聯上線，組成一個高效的圖的問題。這個圖，就是一張關於“依賴”的圖。人與人之間的依賴，類與類之間的依賴，包與包之間的依賴。依賴的另外的一個名字就是Coupling。而我們追求的就是Cohesion。Coupling（耦合）/ Cohesion（內聚）這兩個詞的妙處在於，明白的人根據自己的經驗，一看就點頭。不明白的人，由於沒有對應的經驗，無論怎麼解釋，都是摸不著頭腦。正是因為其“妙不可言”性，所以我可以說這兩個詞就是所有問題的答案（你也無法反駁）。但至少我們可以知道企業定製軟體開發的核心問題其實就是一個：就是管理好人與人之間的Dependency，包與包之間的Dependency，使得資訊可以在高度依賴的人與人之間快速傳遞（強調Coupling帶來的訊息傳遞的效率），而理解又可以局限在高度內聚的模組內部（強調Cohesion帶來的維護便利），但同時又不能讓某人過度被依賴倒置工作過勞死了，被依賴得越多要求其體能越好，對於包的內聚也一樣，高內聚做到極致就是最小的編譯單元（類？），又會導致包的粒度過小，使得包的數量變得巨大，失去了維護的便利性。我們需要做的，就是在To Depend or Not To Depend中，根據情境作出取捨。

 

那麼抽象而言，無論是解決溝通問題還是複雜度問題都可以歸納為：

1、設定目標指標

2、度量現有的指標，觀測現有的依賴圖

3、做出依賴圖的調整計劃，並執行

4、觀察指標的變化

5、重複步驟3，4，直到目標達到

 

但是問題是：

1、如何度量指標？溝通的效率？代碼的品質？都很能度量。

2、如何觀測現有的依賴圖？包的依賴還可以觀測，但是團隊的協作是比較難觀測的。

3、如何對依賴圖做調整？重構？Change Agent？人不比代碼那麼容易改變。

4、如果指標不是簡單數字，怎麼比較？怎麼知道指標是朝著目標發生變化？

 

這四個問題，幾乎沒有硬的科學問題。管理複雜系統的複雜度，可能是一門硬的科學。但是夾雜了人的因素的企業定製軟體開發，一定不是一門硬的科學。那麼，數學公式不是這些問題的答案。那麼該朝哪個方向努力？

 

TO BE CONTINUED