寫文檔和寫代碼一樣，是一個程序員必備的技能之一。

大部分的項目都是需要團隊進行配合的，而團隊配合之間，很多是無法使用源代碼進行工作的記錄和流轉的，所以就需要使用文檔了。

不過，如果寫文檔的時間比寫代碼的時間還多的話，這就有問題了。

對于一個程序員來說，寫代碼速度和質量，肯定是直接生產效率的體現，如果將自己的大部分時間都花在文檔上面，那就說明了程序員的生產效率存在問題。

可能我們就需要分析，是不是自己出了什么問題了？

對寫文檔很反感？

很多人在開始的時候，都會有這個階段，就是對寫文檔十分的反感。我曾經也有過這樣的一段時間，覺得我寫代碼很開心，寫文檔很苦惱。

所以，寫代碼的時候，我進度很快源碼，但是寫文檔的時候，就半年寫不出一個屁出來。以至于我花在文檔上的時間比在代碼上多了。

這個時候，我們還是需要現正視寫文檔這件事情。其實這件事比寫代碼要簡單源碼，而且在寫代碼前后撰寫文檔的過程中，也等于對自己的代碼進行預演和復查了。

很多時候，我們在自己寫文檔的時候，還能發現一些自己業務邏輯中不正確的部分然后提前就進行修改了。

所以，不要覺得文檔是無意義的，真的有一天，你成為了架構師的時候，你寫文檔的日子就真的比寫代碼多了。

時間安排上的不合理？

我們在寫文檔的時候，一般都在思慮成熟以后再下筆。如果我們是邊想邊寫，可能就會寫著寫著，發現自己跑偏了，然后思路需要重新整理，文檔也就需要重寫了。

重新整理思路是一個很快的過程，但是如果需要重寫文檔，就是比較麻煩的過程，這樣就浪費了自己大把的時間，最終的結果就可能是，自己花在文檔上的時間過多，但是用在代碼上的時間不夠，導致最后代碼的質量不高。

所以，現在紙上隨便的寫寫畫畫，將自己的思路整理好了，再來整理文檔。

當然，我曾經的做法是，在我將代碼都寫好以后，然后檢查代碼時，再來補功能分析文檔，雖然和規定的順序有所不一樣，但是我至少完成了文檔和代碼，并且效率也高。

我們都知道，很多的程序員在年齡到了一定的時候就會轉方向，有的喜歡研究技術，所以往架構方向發展，有的習慣協作管理，所以往項目經理方向發展，還有的覺得產品設計是自己的愛好，所以轉了產品。

不管你未來的目標是什么，唯一能夠肯定的就是，寫文檔會成為你日常工作中最多的事情。

對于架構來說，架構的說明文檔，PPT等等會占據大量的時間，而且還有很多的時間會用來進行演講和溝通，寫代碼的時間可能有30%左右。

對于項目經理來說，那代碼就和你沒緣了，每天就是各種各樣的文檔和報表，如果公司給你的權利夠多，可能還需要做成本分析控制和預算，那些文檔就更細了。

對于產品來說，那也不需要寫代碼了，和運營、市場的往來會更加的頻繁，其他的就是各種原型圖，PRD等等。

所以，同學們，從現在開始就習慣文檔吧，免得未來要上一個臺階的時候，你覺得有壓力。