不是他個人的問題，是管理的問題。把這個納入考核指標，看看還寫不寫。說白了就是公司沒有一套正兒八經的研發管理辦法和規範。

這種現象普遍存在，尤其是一些小公司。根本就沒有這麼多時間來寫這玩意，因為需求隨時改。很多公司一開始也是堅持寫介面文件，寫著寫著就不寫了。原因有以下幾點：

寫藉口文件無形中縮短前後端聯調介面的時間。前後端定義好，然後就按照介面定義來走，減少了溝通成本。新接手的人也知道該怎麼規範起來。但理想很豐滿，現實很骨感。有一句話說得好，做開發的永遠不要相信產品的話，一個專案就是在不斷的更改中才會慢慢的成長。即便是非常優秀的產品經理，他也無法阻擋需求的更改。優秀的產品經理只能說避免很多沒有必要的需求，考慮的更全面一點。

一旦需求改的太頻繁，需求多了，也就是忙起來了，寫程式碼的時間都不夠，就不會寫什麼介面文件了。直接把介面告訴前端，前端再打印出來，看看是什麼格式，然後根據需要傳的引數來進行聯調。其中遇到什麼問題就再反饋給後端。

隨著這樣的習慣，慢慢的後端就更不寫介面詳細文件了。不過這樣有一個弊端，那就是有人員變動的時候，這參與進來的成本就大很多。更何況每個人寫程式碼的風格不太一樣。

其實聯調介面，對著文件來，真的是減少了前端的開發工作量。但是很多公司技術部門老大沒有這方面的規定。所以誰都想能偷懶就偷懶，你前端人員讓他們寫，他們是不會聽你的。因為你不是他們的老大。

我上家公司就是這樣，後端有四個人，每個人寫的介面格式都不一樣。同樣的一個欄位名，有的人是這個單詞，有的人是那個單詞，甚至有的人型別都不一樣，他們從來也沒有寫介面需求的習慣。因為前幾年前後端分離不是那麼火，前端做的工作僅僅就是把設計師設計的圖，然後切成靜態頁面。然後丟給後端，後端聯調介面就不需要什麼介面文件了。後端怎麼寫的他自己都知道。

因為寫介面文件不僅僅規範起來，其實也是一個證據的證明。如果後端的人開始寫了這個定義，後面沒有按照這個來，出了問題，到時候鍋想甩都甩不掉。

另外直接說不想寫，到時候你告訴領導，寫文件是那個人不想寫，估計也少不了一頓批。以忙為由，這樣領導聽起來就可以理解。

我個人覺得很有必要把這個需求文件規範起來，既然大家是一個團隊，如果不規範起來，這樣不僅不能提高開發效率，反而後期出現的問題也會越來越多。團隊是需要磨合的，而不是隨心所欲的，團隊不磨合，那這個團隊永遠不會強大起來，甚至可以說是一盤散沙。

規範不是按照一個人的的意思來，而是大家都提出有用的建議，把各個人的優點都集中起來。然後大家都按照這個規則按一處使勁，這樣的產品才會越來越好。你覺得呢？

作為一名IT行業的從業者，我來回答一下這個問題。

首先，是否需要寫介面文件往往與專案規模有比較直接的關係，一些大中型專案是一定要寫介面文件的，這一點程式設計師通常也是比較清楚的，而且文件的編寫通常也有一個專門的負責人，往往也需要多個程式設計師的配合才能完成。

程式設計師之所以不寫介面文件，通常處於三方面原因，其一是專案規模本身很小，介面設計也比較簡單，此時程式設計師往往不會單獨抽出時間來寫介面文件，實際上這部分工作很多人都可以完成，也沒有必要一定要讓程式設計師做；其二是專案本身的介面設計沒有最終敲定，此時程式設計師希望等介面確定之後再寫，這也是比較常見的原因之一；其三是程式設計師本身對於整個專案的介面不瞭解。

對於程式設計師來說，編寫介面文件通常並不是一件很願意做的事情，除了以上幾點原因之外，程式設計師編寫介面文件通常沒有單獨的任務指標，而且編寫介面文件通常比較耗費時間，這也是很多程式設計師不願意編寫介面文件的一個重要原因。實際上，在很多專案組中，專案經理通常會參與介面文件的編寫工作，另外還會配備專門的人員來完成介面文件的最終彙總。

正常情況下，介面文件在最終生成之後，通常還需要一個詳細的校驗過程，這個過程需要根據介面文件的描述，來完成對應介面的驗證。按照不同的專案應用場景，介面也會有不同的應用場景，通常會向不同的使用者開放不同的介面，此時也需要有詳細的說明。

前後端對接，一般前段開發人員一般都需要後端人員提供介面文件，但是現在swagger文件已經完全可以提供該功能。很多情況下後端開發程式設計師整合一個swagger進去，會自動生成相應的文件。

可以給後端開發人員一定的時間去學習swagger或者整合swagger進專案。

因為壓根就不需要寫介面文件，後端引入swagger介面文件會自動生成，程式碼改了介面文件也會自動更新，同時前端不管是用web還是客戶端c#介面呼叫這塊的程式碼都是可以自動生成的（注：js有jar包翻譯工具，c#可以用模板檔案自動生成程式碼），程式工資開那麼高，把精力放在沒有技術含量的寫文件上不知道怎麼想的。

一般公司都會開發一套自己的介面系統吧

後臺程式碼一提交，自動根據介面在介面系統中生成介面文件

前端可以查詢介面系統進行介面呼叫

後臺也可以在介面系統中進行介面測試

自動化生成～省

程式設計師最不喜歡的兩件事：

1：別人不寫文件；

2：別人讓自己寫文件；

不過還好也有偷懶的辦法，比如很久以前本人就在python flask 上做些包裝，達到自動生成文件的效果，當然現在有一個更強大的框架叫fastapi

介面文件是模組或系統之間交換資訊的格式檔案，要寫介面檔案必須對整個系統比較熟悉。最好有一定的工作經驗。不是誰都能寫的。

如果是一個人的小專案，反正是一個人用，有問題自己修改，所以隨便寫隨時改，沒什麼壓力。也不可能推給別人。

如果是團隊專案，那就得謹慎行事了。一般最好是對系統比較全面瞭解的老手來寫，文件完成以後還要把全專案的人叫到一起，一點一點的講解，看是否有缺陷，一旦定稿以後，不能隨便修改，否則增加大家的負擔。耽誤大家的進度。壓力是比較大的。

我曾經參加過多團隊合作的大型專案。介面的定義有專門的總體組，他們定義格式框架，每個系統把自己相關的資訊字典上報上去。比如你有哪些裝置，有哪些告警等等。然後再由總體組整合，再召集所有系統的技術負責人進行評審。因為這個涉及多個系統之間的資料交換，每次評審至少三天。光評審會都開過幾次。最後定稿還邀請第三方的專家。可見介面之重要性。

因此回到上面的話題，寫介面文件真的不是隨便就能寫出來的，忙沒有時間，確實是個藉口，也有可能是不願意承擔責任。