程式碼之道

第2部分 (第2/4頁)

的那樣，浪費和災難在工作中常常相依相伴。關於這一點，沒什麼比組織的溝通（本章的幾個欄目都會涉及這個話題），以及專案之間的自由時間的合理使用來得更為明顯。這些領域影響的不僅僅是個人，而且是整個團隊。因此，它們的影響也是成倍於其他領域的影響。

在我的恐怖字典中，規格說明文件（規範書）和會議始終佔據著特殊的位置。我想可能是因為工程師花了太多的時間在會議上，而且常常還是在討論規範書的原因吧。儘管我很希望這兩樣東西在我們熟知的世界中消失，但它們之所以存在必定還是有它們的用途的。我們能做的，是要關注那個真實的用途，而把其他多餘的東西統統拋棄。

在這一章中，I。　M。　Wright介紹了一些策略去消除常見的低下效率。第一個欄目談到了最後時刻的規範書變更。第二個欄目解決了專案之間的空閒時間的合理使用問題。第三個欄目聚焦在如何盡力消除會議的弊病。最後兩個欄目竭力想徹底拋棄規範書，如果那不可行，至少也要讓規範書短小精悍一點。

其他欄目在組織溝通方面會有更加充分的論述——從跨團隊協商到跟非技術人員交流的方方面面。那些欄目還介紹了“個人”可以採取的改進措施。但本章這些欄目重在講述“組織”能夠採取的措施，以便最好地使用它們有限的時間。

——Eric

對於每次變更，攪動，攪動，攪動

2001年7月1日：“遲到的規範書：生活現實或先天不足”

你已經達到了“編碼完成”（Code　plete）的階段，你正在全力修復Bug，這時候看看你的郵箱裡收到了什麼？啊，太有趣了，居然是一份新的規範書！把它一腳揣開，如何？請稍等，這可是以前的規範書不小心遺漏掉的一個關鍵功能，或者像我們常說的那樣，“程式碼本身就是規範書。”

作者注：編碼完成（Code　plete），是指開發者認為對於某個功能所有必要的實現程式碼都已經簽入到原始碼控制系統的一種狀態。通常這只是一個主觀判斷，而更好的做法實際上應該基於質量標準來度量（那時候經常稱作為“Feature　plete”，即“功能完成”）。

可以想象，測試人員被激怒了。因為他們沒有及時拿到規範書，並且他們覺得“被排除在了專案開發週期之外”。實在太晚了！程式碼的表現跟規範書不符，但他們還沒測試過。開發人員也感到焦躁不安，因為他們原以為功能已經完成了，但實際上測試人員卻在瘋狂抱怨他們實現的是一個“錯誤”的東西，這將導致大量的返工。更糟糕的是，開發人員當初實現的功能根本就沒有在文件中被正確定義好。於是，大家對新的規範書展開爭論，發現漏洞，然後再更改，攪動實現程式碼，直到專案失敗——而這時候本該是產品的穩定化階段。這下大家都“開心”了！

也許在極端情況下，變更還不止一次。但這的確有可能發生。即使變更沒有那麼晚，規範書常常也是不完整的，或者在尚未被開發人員及時複審和檢查之前就匆忙交付開發了。

結果怎麼樣呢？攪動程式碼，一次又一次地更改以前的實現。開發人員開始編碼的時間太早了！規範書本身就有問題，因此程式碼自然也有問題。當有人指出這些問題的時候，特別會議召開了，但有人被遺漏、缺席了這個會議，程式碼返工重寫之後，那個被遺漏的人發現了其他地方的錯誤，於是需要召開更多的特別會議，就這樣週而復始、永無寧日。

有什麼辦法可以解決這個問題呢？有些人可能會說：“專案經理是人渣，應該纏著他，直到他把工作做好。”這聽起來有點殘酷，哪怕是我也有這樣的感覺。規範書來得太晚，這是生活的現實，問題在於你處理它的方式。我見到過有如下一些不同的方法。

作者注：我能想象，一些極限程式設計愛好者在那邊嚷嚷了：“給他們一個房間！”（一個團隊房間。）我在後面的一個欄目——“停止寫規範書，跟功能小組呆在一起”——也會談到這個觀點。然而，微軟是一個相當多樣化的環境。不是每個團隊都能呆在同一個地方的，文件通常是解決團隊之間的相互依賴問題的必要手段。因此，也並不是一個解決方案能夠解決所有的問題。

書　包　網　txt小說上傳分享

走廊會議

第一種方法是走廊會議。當一個開發人員發現手頭的規範書存在漏洞，這時候專案經理正好路過，於是一個走廊會議就開始了，一些問題透過這種方式得到了解決。那個開發人員很開心地