1樓：程式設計師職場大萌哥
非常需要，文件是公升級的關鍵，否則你一直就是個打工人。
從傳播學來講，文件是有傳播，以及儲存的價值。而什麼時候需要文件呢？
你所寫的東西，能被更多人復用。
而能復用說明你的經驗，是具有通用性的，你應該開心，自己的東西能夠形成文件。
文件是會給自己帶來影響力，同時文件最簡單的價值就是，讓自己對技術做了梳理，不要再有盲點。
不寫文件的程式設計師，終究會淪為沒有沉澱，也就是即使有貨，也會倒不出來。
寫文件會讓意識流的內容，變成順序的整理，為邏輯做乙個完整的覆盤。
所以，寫文件是程式設計師成長過程中，非常有必要的，而且是必須的。
誰寫文件？我們看下工作中哪些人寫？
領導寫文件用作匯報，以及推動進度。
開發開發寫文件，一般而言比如開發了乙個SDK，做了乙個通用元件，寫了乙個工具。
要記住一點，文件更容易傳播，而如果不寫文件，乙個是會忘記，乙個是別人遇到問題會找你，而你一直去講重複的內容，你也沒時間成長了。
所以，文件很重要。
再乙個，說太多，最終考核評優，你說你拿出來你輸出的文件好，還是你說你掌握了很多技能，但就是沒寫。
寫下來就是公司的財富，不寫就是你自己的而已。那麼你認為公司喜歡哪個呢？
從這點去看，你寫下來也是有好處的，對自己獲得優秀員工，非常重要！
2樓：哎呀
文件才是最容易忽略被的核心部分，
文件貫穿了乙個產品的生命週期，
需求文件
概要設計文件
詳細設計文件
介面文件
對接文件
開發文件/使用說明
變更文件
文件就像乙個產品的履歷，記錄了產品各個階段的發生的重要事情，每個文件編寫者在對於當前任務要有足夠多的思考才能把文件寫的清楚，明白，否則當前編寫者並不理解自己在幹啥，這是文件第一意義，讓當前責任人真正的思考過，第二意義，後來接手的人明白這個產品經歷了那些，如果做變更，整體的影響更容易評估，否則就是盲人摸象，如果文件沒有及時更新，文件的意義就不復存在。編寫文件非常爽，更新文件火葬場，更新文件才是程式設計師的時刻注意的事情
3樓：23號新秀
寫文件是程式設計師最重要的工作啊,不僅僅是程式設計師,就是以後高P了文件也是非常非常重要的.
寫程式就相當於平常寫作業,寫文件相當於期末考試,你天天寫作業最後別人寫了文件拿了高分,這不是為他人做嫁衣嗎?
不寫文件的程式設計師也有,如果身家超過1000w刀我覺得幹啥都行.
4樓：王sir說大資料
寫文件的能力極其重要，這個重要性可能需要在你工作後5年左右的時間體現出來。
除了前面各位答主的回答的開發必備的文件，比如：需求文件、需求分析文件、概設、詳設、測試報告、使用說明文件等等，個人需要寫一下針對這些文件解決了什麼問題的想法，以及這些文件將來誰會看，看這些文件對個人的提公升發展有什麼好處或者價值。
舉個例子
絕大部分程式設計師的終極目標都是架構師，那麼要做到架構師這個級別，需要哪些能力呢？
首要的也是最重要的就是題主提到的文件能力，這些個文件能使整個專案組的人知道你要傳遞的設計方案和架構。
除此之外，個人還要寫一些日常處理問題的總結，不斷的鍛鍊自己的文筆，說不定，將來這也是一條路子，當你到40歲幹不動的時候，第一代程式設計師認識到這點，大部分悔之晚矣。
5樓：cowbobi
任何乙個人在崗位上成長都需要有東西沉澱下來，而這個最直觀的體現就是文件，對程式設計師也是一樣，有的是崗位要求需求，有的崗位上沒這樣的要求，但無論怎麼樣都應該要有意識的把自己在自己領域內的所得通過文件來呈現，並分享，反饋給別人。
6樓：影子迷魚
寫文件是不可能的，但是不寫文件也是不可能的。
其實，寫文件，有助於幫自己整個人梳理專案的邏輯，能對專案的各個流程加深理解，這樣在下次面試的時候，能更好的應付面試官哦。
當然，一般專案的文件，一般都有模板，例如開發文件這些。 都是套就好了。
在開發中，介面文件的話，可以了解一下swagger。現在開源社群也有很多任務具可以使用。
7樓：蝦趣
首先需要寫文件，也很重要。
其次，有一句話：程式設計師討厭寫文件，更討厭別人不寫文件。
對於多數公司，都會很注重文件，或早或晚而已。隨著團隊和公司的成長，重視文件是必然的。
對於程式猿來說，經常可以接觸到的文件大概如下：
主要由PM（產品經理）來寫，程式猿開發時也是基於這個需求文件來進行開發與業務實現。
程式猿來寫。本人作為乙個Android攻城獅，最討厭的就是後端不寫介面文件，或者不按照介面文件進行開發，或者介面以及介面文件有改動不及時通知移動端。
主要由QA（測試工程師）來寫。針對每次的需求迭代（也對應著上述PM的需求文件），編寫的測試用例。
主要由架構師，相對資深一些的程式猿來寫。某次的重構，某個功能模組的實現，乙個新系統的設計，方案的公升級等，都可能是技術方案文件出現的場景。裡面可能涉及了技術選型，方案的對比，架構的設計等。
再具體一些，可能還會有系統設計的流程圖，UML架構類圖等。
而負責業務實現的程式猿，則依照這些技術方案文件進行coding。
技術方案是指導，架構設計是骨架，業務實現是填補血肉。
有些公司或者團隊技術氛圍活躍，會有定時的內部技術分享會，基本都會有文件留存。不寫文件，如何分享？技術問題。光靠嘴說不清的。
說點更接地氣的一些：
文件，可以避免程式猿背鍋，或者幫助我們甩鍋。
文件，在技術團隊內部，一種資產，是技術的沉澱。
8樓：sc30
要寫。前司不寫文件，哪怕有也是純業務流程，跟策劃案子差不多。人人都在裝忙沒有技術追求。能力都是寫些簡單業務。
現在公司我入職就有很多文件，介紹了各種功能設計前的打算，以及遇到的問題，查閱了什麼資料利用了什麼方法解決了問題。作為新人我能很快融入這個團隊。
同事們也很放心地解決他們的問題，我們通過文件就可以了解這個專案要點。我也在閱讀過程中幫他們完善文件，補充了一些作為新人可能會遇到的坑，然後怎麼解決。
程式設計師能高效點不好麼？為什麼一定要在那莽加班？
9樓：IT消磨時間
非常有必要寫文件，一方面是要跟外面對接的時候要用到，另外就是假如離職了需要交接工作也會用到。其實還有一方面就是哪天領導需要了解什麼東西，此時你恰好有這個文件，發給領導一看哪怕寫的不是很好也能給領導留下一些印象，很有利於以後的漲薪。
不過現在有不少框架裡面都自帶入參出參的文件，比如swagger。但是還是建議保留相關文件，這樣也方便以後檢視。
2、建議畫一些流程圖，時序圖，一方面有利於自己對業務的理解，另外就是對自己的晉公升特別有幫助，人總是想著往上爬。不論是做專案經理還是技術經理，做匯報或者講解產品的時候流程圖，時序圖是必須要畫的。
10樓：放手離傷
我認為寫文件很有必要，文件不僅是乙個交流工具，還十分方便後期覆盤。
程式開發設計的知識點太多了，再日常工作中記錄技術文件或者需求文件，再遇到類似問題是能很好的查詢，畢竟好記性不如爛筆頭。
11樓：
最討厭別人不寫文件，最討厭別人讓寫文件
以下兩個應該是必須的
介面文件
系統架構
然後根據業務需要來補充具體的技術方案，以及通過注釋來說明
12樓：
寫，設計文件必須要寫，尤其是 uml 圖，寫完給 leader review，能從根本上規避很多開發階段才能暴露出來的問題。
13樓：AI落地工程師
如果只是你乙個人開發產品、維護產品，那麼文件可有可無。如果是多人、跨部門協作開發，並且開發的產品需要提供別人二次整合、開發等，那麼必要的文件是一定要寫的，強調一下：必要的文件，主要的原因有二：
1、方便別人繼續開發使用；2、產品提供給不同客戶時，免得你重複回答別人的問題和疑惑。有實力不寫文件的程式設計師，要不是大牛，要不就是耍無賴，各人見解，勿噴。
14樓：小翠
關於文件，先說個普遍現象，那就是程式設計師討厭自己寫文件，但又討厭別人不寫文件。
在整個軟體開發過程中，程式設計師（以下簡稱開發）主要編寫的文件有如下幾類：
一、技術設計方案
軟體變更的源頭是因為業務需求的變化，所以產品經理收集需求、分析訴求、設計功能之後一般會有個需求評審。需求評審完畢，進入開發設計階段。開發設計的目的是說明如何把產品的功能設計進行落地，該文件主要包含模型設計（比如表設計、模型狀態機流轉、模型的依賴關係）、核心功能設計（比如複雜的計算邏輯、引入的中介軟體技術選型、跨系統的依賴關係和互動方式）、介面設計（系統呼叫的介面、前後端的介面）、開發節奏（關鍵時間節點以及deadline）、工作量分配和評估（模組指定給誰以及開發人日）、風險評估（向下相容性、引入其他依賴的穩定性風險）。
開發設計是開發同學主要參與的以及參與次數最多的一類文件，這一類文件力求簡潔、詳細、全面。能用圖說明的問題就不要用文字了。評判一篇技術方案好壞的標準：
是否可以讓乙個新人看完之後可以立即投入開發
二、系統使用說明
該類文件的目的是作為使用者使用的指引，一般涉及到功能總劃分、功能詳情。小白使用者通過此類文件可以對系統的整體功能有個大致的了解，當有具體的使用場景時可以通過目錄檢索找到操作路徑。
三、常見問題FAQ
這部分應該也是使用說明的一部分，但我這邊把它拆出來的目的是為了強調此類文件對使用者的重要性。系統使用過程中，由於使用者操作不當、系統設計缺陷、系統bug、現有中介軟體的開放能力不足等其他原因會造成一些阻塞性的問題，FAQ就是為了回答此類問題，減少人工答疑的壓力。
四、系統架構規劃
架構規劃一般是開發同學自發的舉措，目的一般是提公升系統的吞吐量（降低RT增加併發）、提公升系統的擴充套件性（DDD，敏捷開發）。
寫在最後：
寫文件很重要，寫好的文件更重要。
但是我天生不喜歡寫文件 。
15樓：雨傘下面看世界
需要啊，有效的傳達資訊，這是基本素質了。
至於寫哪些我覺得沒有定論，看需要。但是文件寫清楚排版整好點那是必須的。看乙個閱讀體驗糟糕的文件，寧願不看啊。
16樓：
需要如果你負責乙個模組，用C寫乙個動態鏈結庫給別人用
你要寫文件說明，你的模組的功能，有提供哪些函式來實現你承諾的功能，這些函式又分別需要什麼樣的入參（包括型別、取值範圍、作用等），返回什麼樣的出參
如果你負責乙個服務，用golang寫乙個程序提供遠端呼叫
你要寫文件說明，用什麼協議提供服務，有哪些介面，這些介面的入參和出參（類似上面），另外還可以附上預設超時時間、壓測資料等
如果你負責乙個系統，基於Kubernetes搭建乙個微服務平台
你要寫文件說明，基礎的技術選型的理由，包括現在的主流方向有哪些選擇，從哪些維度去比較他們的優劣；設計的時候遵循的一些原則，如果別人想進一步了解的話，需要先去掌握哪些基礎知識
總之，你交付乙個成品，面對這件成品的使用者，你應該告訴他什麼，或者說他可能會提出的問題的答案，都是你應該寫在文件裡的
當然，這是乙個很理想的狀態
也許很難做到，但是，我們應該知道，什麼是對的
另外，不寫文件的程式設計師也許頗有成就，但不會寫文件的程式設計師，應該是沒有前途的
前端程式設計師需不需要學linux，vim？
jiangtao9999 Windows 程式的前端開發，不需要學這倆東西。但是你真的這輩子就不碰 Linux 不碰字元介面的簡單開發了嗎？你真的要在你現在的崗位一輩子，不會去其他行業或者其他系統的開發了嗎？或者，你的學習能力非常強，什麼東西，都能到眼前了才開始學，但是又能非常快的學會嗎？ lwz ...
程式設計師 其實是碼農 需不需要考研來充實自己？
個人感覺分不同的方向吧 我是做計算機的，但是我不喜歡被人叫程式設計師，喜歡做工程師。如果你是做嵌入式領域，且想有更深入的發展，那我覺得研究生還是很有必要的 演算法領域可能不只要考研，考博更好 網際網路前端類和web類的程式設計師，個人感覺不需要考研，實際經驗的積累更加重要，技術門檻不高，更新速度快 ...
程式設計師紛紛考公，是否說明我們不需要太多有專業知識的人？
不知道 前輩們撐到35歲已經禿頂性功能喪失了，紛紛打退堂鼓想謀條後路。後輩們掂量了一下自己那65kg，覺得趁早上還能一柱擎天，趕緊加入考公大軍上岸了好。 為什麼現代社會和利出一孔不相容。因為一旦利出一孔和生產力的改良發展不相容。稍微聰明一點的都去卷那一孔了，生產力就沒人改良了。此消彼長快速被競爭對手...