27.2

    三是怕懂點技術，卻喜歡瞎指揮的甲方老闆和負責人。

    就像伍濤現在遇到的情況一樣一樣。

    說實話，無論何時，軟件開發者都青睞那些闡述清晰、不能變更的應用需求。在實踐中，很多需求都是匆忙制定的，有時候甚至已經成為了正式形式；要求變更的原因，一部分是有糟糕的項目經理，另一部分則是來自上級或客戶本身的抱怨和干涉。

    總之，不論什麼原因，對需求變更的恐懼——尤其是在最後一分鐘要求變更——則永遠是開發者的心頭大恨。

    王有節想了想，抬頭掃視一圈。等都不再說話了，他才說道:這樣，小伍，等到你們下次和甲方一起開需求會的時候，我也參加。行吧？”

    “這當然太好了啊，還有什麼行不行的？！”伍濤馬上笑道。

    這個事情講完，又有一個小組長開始彙報。

    他說的這件事情，仍然是在上次會議上就已經提到過的關於文檔的問題。

    “毫不誇張地說，不管是誰切分的不帶說明文檔的代碼，或者是維護沒有開發文檔的舊軟件對我而言就是個噩夢。”

    這位組長說道，“在座的各位都知道，能坐下來理解一段沒有良好文檔，或註釋的已有代碼，本來就是很困難的。但是，如果連文檔或註釋都沒有，那就更糟了。”

    缺失好的文檔，甚至沒有文檔。上海分公司裡的這種狀況王有節也是他工作時間久了以後才知道的。

    但是，要知道，對大多數程序員來說，不管自己喜歡不喜歡，他們有時候也必須在別人的代碼上繼續工作。這時候，即使是一段有良好文檔的第三方代碼，都有可能也會變成一件麻煩事，它要求你做調試，重構，或結構化，使代碼適應可能幾個月前就已切分好的代碼。