>>>  讀書—連接古今充實信仰  >>>

簡體     傳統

五 要多少只眼來馴服復雜
從宏觀上，可以說市集風格大大加速了調試和代碼演進，但是如果想從微觀（開發者和測試者日復一日的工作中）上，準確理解這是如何和怎樣起到作用的，卻又是另一回事了。在本章中（作于本書初版后三年，采納了閱讀本書，并身體力行的開發人員的意見），我們將關注其背后的機理，對于技術不感興趣的讀者可以安心的跳到下一章。
理解問題的一個關鍵在于認清如下的重要事實，那就是那些對源代碼知之甚少的用戶所提交的錯誤報告通常派不上大用場。因為他們一般只看到表面癥狀。在提交錯誤報告的時候，習慣從自身環境出發，這樣（一）會忽視重要的背景數據，（二）通常會遺漏重現錯誤的關鍵步驟。
更深層的問題是，開發者和測試者的思維模式不同。測試者是由表及里的看問題，而開發者則是自內而外。在封閉源代碼的開發環境里，他們被各自的角色羈絆，往往各說各話而且認為對方很難溝通。
開源開發打破了這種束縛。基于源代碼，測試者和開發者可以很容易建立一個統一的模型，并借此有效溝通。僅僅描述表面癥狀的問題報告和深入源代碼基礎抽象模型的報告，對于開發者而言作用是截然不同的。
在代碼層，即使一個不完整的提示性錯誤描述，都可以讓它們在大多數情況下得以修正。比如當某個公測人員指出：“在某某行存在邊界問題”，甚至只是說出“在某某條件下，變量溢出”的時候。通常進行一次對于問題代碼的快速掃描就足以鎖定成因，加以修復了。
所以，如果公測人員和核心開發者都對代碼心中有數，那么溝通和協作就很容易展開。這就意味著節省核心開發者的時間，即使協作者眾多。
另一個節約開發者時間的方法源自典型的開源通訊結構。我在文中使用了“核心開發者”一詞，這有別于“項目核心”和“項目外延”。（“項目核心”一般很小；通常包括一到三個核心開發者，當然如果只有一人也不足為怪；“項目外延”則通常包括數以百計的“公測人員”和“貢獻者”）
正如布魯克斯定律所言傳統軟件開發結構下的根本問題是：“為已經延期的項目增添人手會讓它拖的更久。”通俗的講，布魯克斯定律昭示了：項目的復雜度和通訊成本會以開發人數為基礎，呈現平方指數的增長態勢，而績效則僅能直線上升。
經驗證實，錯誤大多集中在（不同人編寫的）代碼的接口處，而溝通/協調成本則會隨著人員交流渠道的增加而增加，這就是布魯克斯定律建立的基礎。然而問題也會隨著開發者溝通渠道的增多而增加，后者恰好等于開發人數的平方。（更確切地說，是遵循N*(N-1)/2公式，其中N代表開發者人數）
布魯克斯定律（對于開發團隊過大所導致的令人担憂的結果）的分析是基于一個潛在假設的：即項目必須采用全向連通的通訊結構，也就是說每個人都能與其他任何人取得聯系。然而在開源項目中，外延開發是可以分離的平行子環節，彼此關聯甚少。代碼變動和錯誤報告都流經項目的核心團隊，只有在那里我們才需要担負“布魯克斯式”的管理成本。
代碼層的錯誤報告對開發大有助益的原因還有很多，然而它們都圍繞著一個事實。那就是：同一個錯誤在不同的操作習慣和環境下會表現出不同的癥狀。這類問題通常復雜隱蔽，難以重現和靜態捕捉，它們正是造成軟件長期問題的禍根。（比如動態內存管理出錯或者隨機窗口中斷的影響）
一則源自測試者的（源代碼層）試探性描述（例如“我覺得1250行附近像是有個信號處理窗口”或者“你在哪把緩存清零了？”），就可能會成為“當局者迷”的開發者同時解決六七個不同表象問題的關鍵線索。我們往往很難為五花八門的癥狀找到對應的錯誤，但是只要你發布的夠頻繁就無需為此担憂。因為其他協作者會很快的去查看自己提交的問題是否已經被修正了。多數情況下，源代碼層的錯誤報告可以讓許多問題沒有經過特定修補就消失殆盡。
對于復雜多變的錯誤，從表面癥狀探索其成因的途徑通常也很多。而對開發者和測試者而言，走哪條路則取決于他們自身所在的環境，而且也可能因為時間而產生一些無法預期的變化。實際上，開發者和測試者在為癥狀尋找病因的時候，都可以看作是對程序某部分運行狀態的“半隨機”取樣。錯誤越是隱蔽復雜，取樣對癥的成功率也就越低。
對于簡單易于重現的錯誤，重音應該落在“半”而不是“隨機”上；此時，調試技巧和對代碼以及其結構的熟識能派上大用場。然而對于復雜的錯誤，重音則轉向“隨機”。因為在這種情況下，眾人多管齊下比少數人循序漸進要強的多——即使這“少數人”的平均水品很高。
如果挖掘錯誤的途徑不一，很難憑表面現象預測的話，并行糾錯的效果就很明顯了。一個循序漸進的開發者可能一開始就選擇了一條復雜的途徑，當然他也可能一開始就選擇到了簡單的途徑。讓我們換一個角度，如果軟件發布的夠及時，那么眾人就可以多管齊下。他們其中很可能有人立即就能找到一條快捷的途徑，所以在極短的時間里就能修復問題。項目的維護人員看到改進，于是發布新版本。這樣，那些通過其他困難途徑探索同一個錯誤成因的人就可以在浪費掉更多時間之前停下來。【注1】
 
 注釋：
1. 根據為我提供不同難易追蹤途徑的讀者的推測，這種對多表象錯誤的追蹤的復雜度呈“指數”分布（我理解為高斯或者泊松分布，而且這聽上去很有道理）。要是能通過實證繪出類似分布曲線的話，絕對很有價值。假如其與等概率分布平行線大相徑庭，那么即使獨自開發也應該努力效仿市集模式。也就是限定追蹤問題的成因的時間，如果在限定時間內沒有結果，那么就跳轉到下一問題。堅持有時不見得是件好事……

埃里克.斯蒂芬.雷蒙 2014-07-01 18:21:09