企業定制軟件開發的兩個核心問題
企業定制軟件開發不是計算機科學，需要解決的不是編譯原理也不是組合數學。那么，企業定制軟件開發的核心問題是什么？
越來越感覺到，從事一個領域不需要有特別深刻的理解，但起碼要知道做這個領域的事情，需要解決的核心問題是什么。比如說，開發C/S結構軟件，狀態同步（C/S狀態同步以及窗口之間的狀態同步）就是核心問題之一，而開發B/S結構的軟件，狀態同步就不是那么核心的問題。如果事先知道需要有這些核心問題需要考慮，在日常應對接踵而來的具體的事務的時候，就能夠把解決問題的層次抬到更宏觀的層面。
目前而言，個人感覺企業定制軟件開發的核心問題有兩個：
1、如何保證所有參與者（包括客戶在內的開發團隊，以及最終用戶）的溝通強度，使其能夠滿足完成開發目標的需要
2、如何管理企業定制帶來的軟件自身內在的高復雜度，使得復雜度不會超過團隊的維護能力范圍
在前面一篇介紹組織的Blog中，談到了核心問題中的***個，溝通強度問題。團隊而言，刨去個人能力，最重要的就是人與人之間的溝通。沒有好的溝通，即便團隊的個體能力都超級強，也無法形成合力。但只要有好的溝通，至少可以做到人盡其用。假設一個標準人的生產力是1/day。某些特別強的人可以達到3/day。但是如果需要達到10/day的生產力才能在市場允許的時間下完成項目，那么就無法用一個人來完成之間事情，所以才會有團隊存在的必要。但是有兩個標準人，并不會達到1+1=2/day的生產力?？赡苤挥?.5。有三個標準人，更加不會達到1+1+1=3/day的生產力，很有可能有1.8。那么是什么制約了團隊的整體生產力，那就是溝通。當兩個相關聯的任務A和B是一個人做的時候，關于任務A的知識存在于左腦，關于任務B的知識存在于右腦。那么結合兩個任務的知識把其組裝起來的溝通效率就是大腦內部的電信號的速度。但是如何任務A是由Dev甲完成的，任務B是由Dev乙完成的，那么整合兩個任務的效率就受到人嘴皮的震動頻率的約束，受到表達能力的約束，受到理解能力的約束。有人研究過，兩個人即便是面對面，傳輸的比特率也要低于最早的撥號式Modem。更不用說，有的時候開發團隊是分布式的。在無法看到表情，肢體語言，無法共享白板，只能在越洋電話里聽到聲音，而且其中還有一方是非工作時間，在這種情況下，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、如果指標不是簡單數字，怎么比較？怎么知道指標是朝著目標發生變化？
這四個問題，幾乎沒有硬的科學問題。管理復雜系統的復雜度，可能是一門硬的科學。但是夾雜了人的因素的企業定制軟件開發，一定不是一門硬的科學。那么，數學公式不是這些問題的答案。那么該朝哪個方向努力？
【編輯推薦】
