關於文檔—回複main()

Main在他的一篇部落格中寫道：

重溫下敏捷宣言：人和互動重於過程和工具可以工作的軟體重於求全責備的文檔！-----我們公司似乎走了完全不同的路！與客戶合作重於合約談判隨時應對變化重於循規蹈矩！

關於文檔正好有些話要說就回複了一個，自己也做個記錄（超級自戀，哈哈）

其實大多數的公司可能都對文檔要求比較強（這是好一點的，那些連文檔都不要求的恐怕還不如這些公司）。我覺得文檔這個東西不能少，我們經常說文檔具有二義性，沒人看等等。但是要知道一個公司裡面不是都是程式員，還有產品經理，專案經理，組態管理人員，測試人員，維護團隊，部門經理，solution經理，marketing，sales.....你能讓他們去看代碼還是UML圖？文檔是一個很好的折中，是大家共用的對問題的理解。不同的文檔代表的是不同的角色對其他角色的承諾，當我們把文檔作為一種承諾的時候，也許就不會覺得文檔多餘了。而且文檔中的二義性也會降低。因為二義性只會讓你吃虧。

在我們公司是這樣的，A角色寫文檔與B角色review，這個文檔是A對B的承諾。文檔中任何的二義性，允許B向著自己有利的方面理解。當然這是一種理想情況，往往review的結果也是一個文檔，在這個文檔中描述B對A的文檔的認可。中間會有反覆和妥協，總得來說我覺得文檔是很重要的。

舉例來說，產品經理寫需求文檔，會跟項目組進行review，當文檔定稿了接下來會有很多角色根據這個文檔開展自己的工作。這就是產品經理對項目組的承諾：我承諾你們在給定的資源條件下完成的產品達到文檔的要求，我就認可你們的工作。好了，下面研發team寫自己的需求分析；測試組開始寫自己的測試案例；技術文檔組可能會寫一些相關文檔和使用者手冊等。需求分析又是一個文檔，但是是反過來的，研發組對產品經理的承諾：我們承諾在給定的資源條件下實現如文檔中描述的功能。這個時候誰的文檔也不敢亂寫了，當然也不會出現產品都出來了再補文檔的情況。

我不知道main()指的是不是只有設計文檔（相當於研發組對自己的承諾，這個意義要小一些）。胡亂侃兩句，哈哈。