企業(yè)定制軟件開發(fā)的兩個核心問題
企業(yè)定制軟件開發(fā)不是計算機科學(xué)，需要解決的不是編譯原理也不是組合數(shù)學(xué)。那么，企業(yè)定制軟件開發(fā)的核心問題是什么？
越來越感覺到，從事一個領(lǐng)域不需要有特別深刻的理解，但起碼要知道做這個領(lǐng)域的事情，需要解決的核心問題是什么。比如說，開發(fā)C/S結(jié)構(gòu)軟件，狀態(tài)同步（C/S狀態(tài)同步以及窗口之間的狀態(tài)同步）就是核心問題之一，而開發(fā)B/S結(jié)構(gòu)的軟件，狀態(tài)同步就不是那么核心的問題。如果事先知道需要有這些核心問題需要考慮，在日常應(yīng)對接踵而來的具體的事務(wù)的時候，就能夠把解決問題的層次抬到更宏觀的層面。
目前而言，個人感覺企業(yè)定制軟件開發(fā)的核心問題有兩個：
1、如何保證所有參與者（包括客戶在內(nèi)的開發(fā)團隊，以及最終用戶）的溝通強度，使其能夠滿足完成開發(fā)目標(biāo)的需要
2、如何管理企業(yè)定制帶來的軟件自身內(nèi)在的高復(fù)雜度，使得復(fù)雜度不會超過團隊的維護能力范圍
在前面一篇介紹組織的Blog中，談到了核心問題中的***個，溝通強度問題。團隊而言，刨去個人能力，最重要的就是人與人之間的溝通。沒有好的溝通，即便團隊的個體能力都超級強，也無法形成合力。但只要有好的溝通，至少可以做到人盡其用。假設(shè)一個標(biāo)準(zhǔn)人的生產(chǎn)力是1/day。某些特別強的人可以達到3/day。但是如果需要達到10/day的生產(chǎn)力才能在市場允許的時間下完成項目，那么就無法用一個人來完成之間事情，所以才會有團隊存在的必要。但是有兩個標(biāo)準(zhǔn)人，并不會達到1+1=2/day的生產(chǎn)力。可能只有1.5。有三個標(biāo)準(zhǔn)人，更加不會達到1+1+1=3/day的生產(chǎn)力，很有可能有1.8。那么是什么制約了團隊的整體生產(chǎn)力，那就是溝通。當(dāng)兩個相關(guān)聯(lián)的任務(wù)A和B是一個人做的時候，關(guān)于任務(wù)A的知識存在于左腦，關(guān)于任務(wù)B的知識存在于右腦。那么結(jié)合兩個任務(wù)的知識把其組裝起來的溝通效率就是大腦內(nèi)部的電信號的速度。但是如何任務(wù)A是由Dev甲完成的，任務(wù)B是由Dev乙完成的，那么整合兩個任務(wù)的效率就受到人嘴皮的震動頻率的約束，受到表達能力的約束，受到理解能力的約束。有人研究過，兩個人即便是面對面，傳輸?shù)谋忍芈室惨陀谧钤绲膿芴柺組odem。更不用說，有的時候開發(fā)團隊是分布式的。在無法看到表情，肢體語言，無法共享白板，只能在越洋電話里聽到聲音，而且其中還有一方是非工作時間，在這種情況下，1+1幾乎很難達到1/day的生產(chǎn)力。什么是高效的團隊，就是能夠讓1+1的值盡可能大的團隊。如何變得高效，讓溝通變得更加高效。怎么樣讓溝通變得高效高強度？這就是我們要處理的核心問題。
***個問題可以應(yīng)用于所有的人的團隊行為之中。人只要聚集成群，就會有溝通問題。所謂，有人的地方就有江湖。第二個問題則特定于企業(yè)定制軟件開發(fā)。對于互聯(lián)應(yīng)用開發(fā)，也許復(fù)雜度的管理是其次的，最需要關(guān)注的是大用戶量下的可擴展性。但是對于企業(yè)定制軟件開發(fā)，由于業(yè)務(wù)自身的復(fù)雜度，導(dǎo)致了定制軟件的復(fù)雜度。特別是業(yè)務(wù)的組合，導(dǎo)致的組合復(fù)雜性。假設(shè)在理想情況下，一個系統(tǒng)可以分解為模塊A，B，C，其復(fù)雜度都是2。在復(fù)雜度管理良好的情況下 ，這些模塊是被明確劃分的，要理解A，只需要關(guān)注A，以及B與C少量與A交互的部分，也許理解的復(fù)雜度只是2 + 0.5.。但是在復(fù)雜度沒有管理的情況下，所有的“邏輯”（也就是復(fù)雜度）都是隨意地放置的。那么也就是沒法辦法保證，讀A的邏輯只需要關(guān)注A，甚至這個A都是不存在的，你看到的知識一個系統(tǒng)，包含了A，B，C的功能，是完整的一塊。這個時候要真正了解這個系統(tǒng)行為，可能就需要2 * 2 * 2 = 8這么高的代價了。隨著模塊（變量，方法，類，包，模塊，Bundle）的增加，我們需要同時理解的東西也在不斷增加。不去可以地管理復(fù)雜度，很有可能，我們需要了解一塊功能，就需要把所有的代碼都去閱讀一遍?；蛘哒f，改動了一個方法，使得整個項目都需要重新被測試，因為沒有地方是可以被信任的。如何管理復(fù)雜度？這就是我們要處理的核心問題。
有意思的事情是，這兩個核心問題是重疊的。把人，角色等同于類，接口，都抽象地看成點。把溝通理解為人與人之間的聯(lián)系問題。把復(fù)雜度也理解為類與類的依賴問題。那么溝通問題和復(fù)雜度的管理問題都是如何把這些點聯(lián)上線，組成一個高效的圖的問題。這個圖，就是一張關(guān)于“依賴”的圖。人與人之間的依賴，類與類之間的依賴，包與包之間的依賴。依賴的另外的一個名字就是Coupling。而我們追求的就是Cohesion。Coupling（耦合）/ Cohesion（內(nèi)聚）這兩個詞的妙處在于，明白的人根據(jù)自己的經(jīng)驗，一看就點頭。不明白的人，由于沒有對應(yīng)的經(jīng)驗，無論怎么解釋，都是摸不著頭腦。正是因為其“妙不可言”性，所以我可以說這兩個詞就是所有問題的答案（你也無法反駁）。但至少我們可以知道企業(yè)定制軟件開發(fā)的核心問題其實就是一個：就是管理好人與人之間的Dependency，包與包之間的Dependency，使得信息可以在高度依賴的人與人之間快速傳遞（強調(diào)Coupling帶來的消息傳遞的效率），而理解又可以局限在高度內(nèi)聚的模塊內(nèi)部（強調(diào)Cohesion帶來的維護便利），但同時又不能讓某人過度被依賴倒置工作過勞死了，被依賴得越多要求其體能越好，對于包的內(nèi)聚也一樣，高內(nèi)聚做到***就是最小的編譯單元（類？），又會導(dǎo)致包的粒度過小，使得包的數(shù)量變得巨大，失去了維護的便利性。我們需要做的，就是在To Depend or Not To Depend中，根據(jù)場景作出取舍。
那么抽象而言，無論是解決溝通問題還是復(fù)雜度問題都可以歸納為：
1、設(shè)置目標(biāo)指標(biāo)
2、度量現(xiàn)有的指標(biāo)，觀測現(xiàn)有的依賴圖
3、做出依賴圖的調(diào)整計劃，并執(zhí)行
4、觀察指標(biāo)的變化
5、重復(fù)步驟3，4，直到目標(biāo)達到
但是問題是：
1、如何度量指標(biāo)？溝通的效率？代碼的質(zhì)量？都很能度量。
2、如何觀測現(xiàn)有的依賴圖？包的依賴還可以觀測，但是團隊的協(xié)作是比較難觀測的。
3、如何對依賴圖做調(diào)整？重構(gòu)？Change Agent？人不比代碼那么容易改變。
4、如果指標(biāo)不是簡單數(shù)字，怎么比較？怎么知道指標(biāo)是朝著目標(biāo)發(fā)生變化？
這四個問題，幾乎沒有硬的科學(xué)問題。管理復(fù)雜系統(tǒng)的復(fù)雜度，可能是一門硬的科學(xué)。但是夾雜了人的因素的企業(yè)定制軟件開發(fā)，一定不是一門硬的科學(xué)。那么，數(shù)學(xué)公式不是這些問題的答案。那么該朝哪個方向努力？
【編輯推薦】
