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