很合理啊，因為寫文件能加深你對問題的理解，擴充套件你的思路，使你不是單純為了實現這個功能去實現它。所以我覺得寫文件時間比寫程式碼時間長很合理，程式設計師和碼農是有區別的對吧?

普通程式設計師來回答：文件很重要，寫文件多花點時間很合理。（內心：老子從來不寫，不一樣好好的！）

走向管理的程式設計師回答：文件是思想指導，戰略路線，文件寫不出來，說明思路不清晰，這樣寫出來的程式碼怎麼能放心提交呢？沒文件後期怎麼維護呢？寫好文件再寫程式碼事半功倍啊！（內心：我寫文件，程式碼部分就交給你們這些小弟了）

程式碼狂人：老子其實根本不用寫文件，都在腦子裡面存著，存得整整齊齊。要不是怕你們這些菜鳥看不懂老子這麼高階的程式碼，老子才不需要文件。（內心就是這麼想的）

上面開開玩笑，總的來說呢，不管菜鳥還是大神，文件肯定要啊，就跟人說話一樣，要先想好了再說，思路不清晰，說話肯定也是東一句西一句毫無邏輯，越說越說不清楚。當你每次說話之前，都能想清楚再說，久而久之，你不需要刻意去整理思路，你也有了自己的說話套路。所以文件這個事，說大點，其實是一種方法論，就是先計劃，再行動。

一定要寫文件，寫文件也是自我整理的一個過程，有時確實時間會比寫程式碼時間長，但是寫時間長了，有些就會成了套路了，也就寫的越來越快了，還有當你牛x到一定程度貌似可能也可以簡化嘍！

我想說沒有什麼合理不合理，關鍵是看這個程式設計師需不需要這個文件！能很清晰的，簡單的寫出程式碼並能給別人詳細口頭闡述過程的程式設計師肯定不想寫也懶得寫，因為這個文件對他來說只是浪費時間！再說了程式更新換代快，文件存在的價值可想而知了，除了存根好像沒什麼意義！但是如果程式設計師寫的文件要讓另一個程式設計師寫成程式碼，卻意義非凡，前提是文件要精準可行註解無誤！好的文件即使缺少了這個寫文件的程式設計師別的程式設計師照樣可以寫好程式碼！好的程式設計師是應該能寫好文件更能寫好程式碼的人！

工作是分很多性質的，也許你認為程式猿這份工作就應該只看程式碼，設計師好好作圖就行了，為什麼還要和甲方溝通到難受死。

但是拋開工作不談，人都是需要social的，社交性的。不管是做程式猿要寫文件這份事來看還是需要去做別的事，你在承擔你認為的工作的同時，也是需要給自己上司交一份報告的。

姑且認為就是這份報告，但是你的時間都花在文件上了，說明你程式碼碼的很好，但是文件總結歸納，可能就缺乏滿足上司對了解你工作的權力的技能了。

有點繞哈，但就是這個意思，你目前缺乏滿足你目前工作的技能，千萬不要認為程式猿只會碼程式碼就好，好比在一家公司完全不會社交的人是生存不下去的。

或者說你誤解了你目前工作的本質，才會在這很不滿的表示為何寫文件的時間比敲程式碼的時間還要多，鍛鍊一下這方面的技能哈。

寫文件和寫程式碼一樣，是一個程式設計師必備的技能之一。

大部分的專案都是需要團隊進行配合的，而團隊配合之間，很多是無法使用原始碼進行工作的記錄和流轉的，所以就需要使用文件了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

完全理解。寫文件比寫程式碼的時間長，很大可能是公司的原因。比如公司的研發體系比較正規，遵循業界的某個標準。在這個標準下，每一次程式碼的提交都要伴隨著若干個必寫的文件，也就是需要走流程。哪怕改一個錯別字，也要把整個頁面的業務邏輯描述一下，修改的相關性和影響分析一下。如果有這總情況，一般寫程式碼的時間只佔總體時間的不到五分之一。如果遇到這樣的公司，就要考慮一下你的前途了，在這種環境下，程式設計師的個人能力提升是比較慢的，你的存在是為了保持整個流程體系的完整性。程式碼只佔很少的一部分，你的大部分時間是在維護整個系統的穩定性。

個人認為，有些文件是必須要寫的，有些文件是可以省略掉的，不能一概而論。

資料庫設計文件：必須有！如果一個專案沒有資料庫設計文件，或者文件內容和實際情況不一致的話，別說是後進入專案的人了，就算是專案上的老人，後續工作也費勁兒。

介面文件：系統對方提供的各種介面，入參、出參、各個環境的介面地址等等。當然可以使用一些工具代替，比如Swagger。

各個環境的地址及配置手冊：每個環境的地址是多少？程式部署在哪裡？如果沒有這個文件的話，新員工來了之後可就費勁兒了，要一個個挨著問。

操作手冊：有的話最好，不過維護起來確實不容易。

開發之前寫的設計文件：我們一般是不寫設計文件的，但是據我所知很多公司是要寫這個的，而且要求還很嚴格。甚至我知道一個銀行的開發部，寫設計文件和實際開發的是兩撥人...兩撥人...

開發完了才寫的設計文件：這個是不是感同身受...上一家公司的時候，上線發版需要提供十幾個文件，其中就包括【概要設計文件】【詳細設計文件】等，開發完了再補，完全是應付流程嘛，浪費時間。

各種不應該開發人員寫的文件：你們見過開發寫【安全測試文件】麼？我們當時為了應付差事，可沒少瞎編亂造。