我總是認爲文件對於一個項目和一個團隊來說非常重要，應該定期和詳細地編寫文件。它可以讓事情平行進行，而不需要經常詢問有經驗的程序員。但是，我真的發現許多開發人員（甚至是領導）不會太在意文檔，只是把它們視爲理所當然，這讓我感覺很糟糕。文檔應該由熟練的程序員編寫？
那麼我對文件的態度是對的嗎？文件真的很重要嗎？我應該如何說服團隊領導對這些文件給予更多的關注？
如果文件很重要，第二個問題就會出現。 誰應該寫文件？ IMO，它們應該由像框架創建者（如果我們使用我們自己的框架），項目的重要部分（如db架構，整個架構等）等有經驗的程序員編寫。
的好處是顯而易見的，喜歡幫助人清新，有利於維護和更多。
從我看來因此，熟練的程序員（這裏定義可能不同）的基礎設施建設完成後，應該更加註重代碼比編寫書面文件。
我說得對嗎？
感謝您分享這些問題。
你的小組應建立一個軟件開發過程，它定義瞭如何去開發你的軟件產品。這一過程的一部分將定義要編寫的文檔，並且根據我的經驗，開發團隊的所有成員都共享文檔過程 - 它可以（也應該）成爲一個學習過程。
你的軟件開發過程中應確定其他題目爲好，如代碼評審，單元測試，配置管理等
有很多的方法的例子，從很輕到網絡上很沉重。
你沒有錯，但事實是文檔不會賺錢。如果有的話，糟糕的文檔可以增加收入，因爲你確保客戶需要你的支持合同。
文檔也是一種痛苦，因爲從理論上講，它應該之前發展做，但在現實中事情的變化所以真的只值創建/一個主要版本發佈後更新。
理想情況下，作者應該是業務分析師，而不是的開發者。
「理想情況下，作者應該是業務分析師，而不是開發人員」。這取決於觀衆是誰的文件。也許用戶級別的文檔應由業務分析師或技術撰稿人處理，但低級技術文檔通常需要由開發人員編寫。 – 2013-02-27 12:18:45
@KristopherJohnson我不同意。如果強迫一個MBA /某人悲慘地爲你準備好寫給你的javadoc，對於Oracle來說足夠好，那麼這對我來說已經足夠了。萬歲文盲編程！ – root 2013-08-01 16:53:14
重要的問題要問任何潛在的文檔的目標是什麼，使用目的和文檔的使用預期頻率？你提到幫助一個新人，但在實踐中，閱讀文檔更快，更有效，然後從另一個開發人員演練？演練需要花費時間，但編寫文檔的時間可能會少得多。
具有強大的業務案例和ROI而非備選方案的文檔可以創建，但可能出現的情況較少，您可以想象，創建文檔時沒有明確回答我最初的問題可以保證您不會爲其獲得投資回報。
我認爲這取決於每個團隊，但很多時候，程序員並不擅長編寫文檔。這就是爲什麼有像技術作家這樣的人。程序員應該參與每一步，因爲他們是主題專家，但作者應該寫。
+1，結合@ rexem的回答。 – devstuff 2009-11-01 03:37:27
您有幾種類型的文檔，其中有一個是你的責任：
文檔的每個函數，類，結構，成員作爲你完成它
理想情況下，你的方式做到這一點允許自動提取源文件（例如Doxygen）。只要一定要隨時去做。
至於客戶文檔推移，我的信念是：
我已經與公司只要不會爲最終產品支付全額，除非它附帶完整和全面的文檔。通常會阻止10％，以確保承包商有動力提供所有材料。
就測試人員而言，他們真的是你最好的朋友（或應該是）。他們是知道你的軟件如何和你一樣工作的人。是的，我同意，你應該至少有一個程序功能的大綱，這樣可以防止「增值」切線。讓測試人員來填補這個問題是有道理的，然後讓開發人員檢查它是否準確。
你甚至可以找到你自己說「不不不..它不會按照這種方式..測試人員得到這個錯誤...」，那麼你就火起來的應用程序來實現，他們得到了它正確:)在這方面，這對QA過程也有幫助。
查看文檔的另一種方法是CYA用途。如果你曾經有過不幸在項目中領導不產生文檔的情況，那麼可以將錯誤代碼歸咎於你。除非你用文檔保護自己。
說最好的客戶語言的人是應該寫文檔的人，即使他們不是最瞭解產品的人。他們應該與最瞭解該產品的人進行交流，但文檔不涉及編碼能力;這是關於溝通。
如果你溝通不好，無論你怎麼了解你的產品都無所謂，你的文檔將毫無用處。
我已經在所有技術項目文檔中使用了WIKI，這讓* all * devs很容易維護它。我最初寫了95％，但在此之後，它作爲一個維護良好，準確的文檔而生活，沒有成爲一個人（即我！）的負擔。 – 2009-11-01 03:19:49