企業(yè)定制軟件開發(fā)不是計算機科學，需要解決的不是編譯原理也不是組合數(shù)學。那么，企業(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è)定制軟件開發(fā)的核心問題有兩個：

1、如何保證所有參與者（包括客戶在內(nèi)的開發(fā)團隊，以及最終用戶）的溝通強度，使其能夠滿足完成開發(fā)目標的需要2、如何管理企業(yè)定制帶來的軟件自身內(nèi)在的高復雜度，使得復雜度不會超過團隊的維護能力范圍在前面一篇介紹組織的blog中，談到了核心問題中的第一個，溝通強度問題。團隊而言，刨去個人能力，最重要的就是人與人之間的溝通。沒有好的溝通，即便團隊的個體能力都超級強，也無法形成合力。但只要有好的溝通，至少可以做到人盡其用。假設(shè)一個標準人的生產(chǎn)力是1/day。某些特別強的人可以達到3/day。但是如果需要達到10/day的生產(chǎn)力才能在市場允許的時間下完成項目，那么就無法用一個人來完成之間事情，所以才會有團隊存在的必要。但是有兩個標準人，并不會達到1+1=2/day的生產(chǎn)力?？赡苤挥?.5。有三個標準人，更加不會達到1+1+1=3/day的生產(chǎn)力，很有可能有1.8。那么是什么制約了團隊的整體生產(chǎn)力，那就是溝通。當兩個相關(guān)聯(lián)的任務a和b是一個人做的時候，關(guān)于任務a的知識存在于左腦，關(guān)于任務b的知識存在于右腦。那么結(jié)合兩個任務的知識把其組裝起來的溝通效率就是大腦內(nèi)部的電信號的速度。但是如何任務a是由dev甲完成的，任務b是由dev乙完成的，那么整合兩個任務的效率就受到人嘴皮的震動頻率的約束，受到表達能力的約束，受到理解能力的約束。有人研究過，兩個人即便是面對面，傳輸?shù)谋忍芈室惨陀谧钤绲膿芴柺絤odem。更不用說，有的時候開發(fā)團隊是分布式的。在無法看到表情，肢體語言，無法共享白板，只能在越洋電話里聽到聲音，而且其中還有一方是非工作時間，在這種情況下，1+1幾乎很難達到1/day的生產(chǎn)力。什么是高效的團隊，就是能夠讓1+1的值盡可能大的團隊。如何變得高效，讓溝通變得更加高效。怎么樣讓溝通變得高效高強度？這就是我們要處理的核心問題。

第一個問題可以應用于所有的人的團隊行為之中。人只要聚集成群，就會有溝通問題。所謂，有人的地方就有江湖。第二個問題則特定于企業(yè)定制軟件開發(fā)。對于互聯(lián)應用開發(fā)，也許復雜度的管理是其次的，最需要關(guān)注的是大用戶量下的可擴展性。但是對于企業(yè)定制軟件開發(fā)，由于業(yè)務自身的復雜度，導致了定制軟件的復雜度。特別是業(yè)務的組合，導致的組合復雜性。假設(shè)在理想情況下，一個系統(tǒng)可以分解為模塊a，b，c，其復雜度都是2。在復雜度管理良好的情況下 ，這些模塊是被明確劃分的，要理解a，只需要關(guān)注a，以及b與c少量與a交互的部分，也許理解的復雜度只是2 + 0.5.。但是在復雜度沒有管理的情況下，所有的“邏輯”（也就是復雜度）都是隨意地放置的。那么也就是沒法辦法保證，讀a的邏輯只需要關(guān)注a，甚至這個a都是不存在的，你看到的知識一個系統(tǒng)，包含了a，b，c的功能，是完整的一塊。這個時候要真正了解這個系統(tǒng)行為，可能就需要2 * 2 * 2 = 8這么高的代價了。隨著模塊（變量，方法，類，包，模塊，bundle）的增加，我們需要同時理解的東西也在不斷增加。不去可以地管理復雜度，很有可能，我們需要了解一塊功能，就需要把所有的代碼都去閱讀一遍?；蛘哒f，改動了一個方法，使得整個項目都需要重新被測試，因為沒有地方是可以被信任的。如何管理復雜度？這就是我們要處理的核心問題。

有意思的事情是，這兩個核心問題是重疊的。把人，角色等同于類，接口，都抽象地看成點。把溝通理解為人與人之間的聯(lián)系問題。把復雜度也理解為類與類的依賴問題。那么溝通問題和復雜度的管理問題都是如何把這些點聯(lián)上線，組成一個高效的圖的問題。這個圖，就是一張關(guān)于“依賴”的圖。人與人之間的依賴，類與類之間的依賴，包與包之間的依賴。依賴的另外的一個名字就是coupling。而我們追求的就是cohesion。coupling（耦合）/ cohesion（內(nèi)聚）這兩個詞的妙處在于，明白的人根據(jù)自己的經(jīng)驗，一看就點頭。不明白的人，由于沒有對應的經(jīng)驗，無論怎么解釋，都是摸不著頭腦。正是因為其“妙不可言”性，所以我可以說這兩個詞就是所有問題的答案（你也無法反駁）。但至少我們可以知道企業(yè)定制軟件開發(fā)的核心問題其實就是一個：就是管理好人與人之間的dependency，包與包之間的dependency，使得信息可以在高度依賴的人與人之間快速傳遞（強調(diào)coupling帶來的消息傳遞的效率），而理解又可以局限在高度內(nèi)聚的模塊內(nèi)部（強調(diào)cohesion帶來的維護便利），但同時又不能讓某人過度被依賴倒置工作過勞死了，被依賴得越多要求其體能越好，對于包的內(nèi)聚也一樣，高內(nèi)聚做到極致就是最小的編譯單元（類？），又會導致包的粒度過小，使得包的數(shù)量變得巨大，失去了維護的便利性。我們需要做的，就是在to depend or not to depend中，根據(jù)場景作出取舍。

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

1、設(shè)置目標指標2、度量現(xiàn)有的指標，觀測現(xiàn)有的依賴圖3、做出依賴圖的調(diào)整計劃，并執(zhí)行4、觀察指標的變化5、重復步驟3，4，直到目標達到但是問題是：

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

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

3、如何對依賴圖做調(diào)整？重構(gòu)？change agent？人不比代碼那么容易改變。

4、如果指標不是簡單數(shù)字，怎么比較？怎么知道指標是朝著目標發(fā)生變化？

這四個問題，幾乎沒有硬的科學問題。管理復雜系統(tǒng)的復雜度，可能是一門硬的科學。但是夾雜了人的因素的企業(yè)定制軟件開發(fā)，一定不是一門硬的科學。那么，數(shù)學公式不是這些問題的答案。那么該朝哪個方向努力？