寫文檔和寫代碼一樣，是一個程序員必備的技能之一。
大部分的項目都是需要團隊進行配合的，而團隊配合之間，很多是無法使用源代碼進行工作的記錄和流轉的，所以就需要使用文檔了。
不過，如果寫文檔的時間比寫代碼的時間還多的話，這就有問題了。
對于一個程序員來說，寫代碼速度和質(zhì)量，肯定是直接生產(chǎn)效率的體現(xiàn)，如果將自己的大部分時間都花在文檔上面，那就說明了程序員的生產(chǎn)效率存在問題。
可能我們就需要分析，是不是自己出了什么問題了？
對寫文檔很反感？
很多人在開始的時候，都會有這個階段，就是對寫文檔十分的反感。我曾經(jīng)也有過這樣的一段時間，覺得我寫代碼很開心，寫文檔很苦惱。
所以，寫代碼的時候，我進度很快源碼，但是寫文檔的時候，就半年寫不出一個屁出來。以至于我花在文檔上的時間比在代碼上多了。
這個時候，我們還是需要現(xiàn)正視寫文檔這件事情。其實這件事比寫代碼要簡單源碼，而且在寫代碼前后撰寫文檔的過程中，也等于對自己的代碼進行預演和復查了。
很多時候，我們在自己寫文檔的時候，還能發(fā)現(xiàn)一些自己業(yè)務邏輯中不正確的部分然后提前就進行修改了。
所以，不要覺得文檔是無意義的，真的有一天，你成為了架構師的時候，你寫文檔的日子就真的比寫代碼多了。
時間安排上的不合理？
我們在寫文檔的時候，一般都在思慮成熟以后再下筆。如果我們是邊想邊寫，可能就會寫著寫著，發(fā)現(xiàn)自己跑偏了，然后思路需要重新整理，文檔也就需要重寫了。
重新整理思路是一個很快的過程，但是如果需要重寫文檔，就是比較麻煩的過程，這樣就浪費了自己大把的時間，最終的結果就可能是，自己花在文檔上的時間過多，但是用在代碼上的時間不夠，導致最后代碼的質(zhì)量不高。
所以，現(xiàn)在紙上隨便的寫寫畫畫，將自己的思路整理好了，再來整理文檔。
當然，我曾經(jīng)的做法是，在我將代碼都寫好以后，然后檢查代碼時，再來補功能分析文檔，雖然和規(guī)定的順序有所不一樣，但是我至少完成了文檔和代碼，并且效率也高。
我們都知道，很多的程序員在年齡到了一定的時候就會轉方向，有的喜歡研究技術，所以往架構方向發(fā)展，有的習慣協(xié)作管理，所以往項目經(jīng)理方向發(fā)展，還有的覺得產(chǎn)品設計是自己的愛好，所以轉了產(chǎn)品。
不管你未來的目標是什么，唯一能夠肯定的就是，寫文檔會成為你日常工作中最多的事情。
對于架構來說，架構的說明文檔，PPT等等會占據(jù)大量的時間，而且還有很多的時間會用來進行演講和溝通，寫代碼的時間可能有30%左右。
對于項目經(jīng)理來說，那代碼就和你沒緣了，每天就是各種各樣的文檔和報表，如果公司給你的權利夠多，可能還需要做成本分析控制和預算，那些文檔就更細了。
對于產(chǎn)品來說，那也不需要寫代碼了，和運營、市場的往來會更加的頻繁，其他的就是各種原型圖，PRD等等。
所以，同學們，從現(xiàn)在開始就習慣文檔吧，免得未來要上一個臺階的時候，你覺得有壓力。
