項目開發過程中為了增加程序的可讀性和程序的健壯性，?方便后期程序的調試和維護，所以需要在開發過程中統一技術規范，一般會在項目初期確定好相關文檔作為這一統一的規范。不同公司會對文檔做不同要求，劃不同的分類，但一般來說（或者拿自己的經驗說）大致可以分為需求文檔、接口文檔、流程圖（可以單獨作為一份文件可以作為附件附在文檔中）、變更文件等。

一、需求文檔

在項目啟動之后，項目的目標已經明確了，那么就要開始著手干活了，但是在干活之前，需要對整個項目分析透徹。那么，如何對業務進行分析呢，看以下的建議。

首先，開發人員要有隨意轉換身份的意識和能力。

A、明確產品功能

在分析業務時，站在用戶的角度上，思考要做的產品能實現什么功能。把所有的功能點列出來！

B、分析某一功能點的流程

在羅列了所有的功能之后，需要站在開發者的角度分析每一個功能點，考慮從客戶端到后臺操作數據庫的整個流程，可以從是什么、為什么、在哪、怎么做、誰來做、做完如何反饋、反饋給誰、上傳到哪、服務器用什么數據庫、數據庫需要什么表、表里有什么字段、每個字段的屬性及意義等等。比如，我要要做一個軟件中個人頭像上傳的功能，首先明確我做的是上傳功能；為什么要上傳？因為個人資料需要頭像；怎么做上傳？通過網絡I/O實現；這個功能在什么位置？軟件有個個人中心模塊，個人中心里有個個人信息子模塊，在這個模塊里可以上傳頭像；誰上傳？已經登錄的用戶；上傳完之后如何反饋？彈窗提示上傳成功；反饋給誰？客戶端已登錄的用戶；上傳到哪？服務器上；用什么數據庫？MySQL;需要什么表？（存到）用戶表；表里有什么字段？用戶信息的基本字段；每個字段的屬性及意義？略。在思考完這些問題之后，可以把一個功能點串成一條完整的從前端到數據庫的線。

C、整合各個功能點–明確分工

在串完所有的功能點之后，站在一個高一層次的角度，把每個功能點之間的聯系理清楚，按照相互的聯系分工合作，優化其中的細節問題。

D、撰寫需求文檔

分工完成之后，按照第二步分析的內容，每個人把自己負責的功能整理成文檔，最后合并文檔，作為統一的需求文檔。

E、繪制業務流程圖

需求文檔確定之后，繪制整個項目的業務流程圖，這時候的流程圖只需要包含前端的業務流程，后臺實現的流程圖不需要在需求文檔中體現，而是放在后面的接口文檔中。

二、接口文檔

不同公司對接口文檔的要求也不盡相同，但包括的內容卻是大同小異的。封面、標題、審批頁、修訂歷史以及格式字體等等風格迥異的次要內容不做贅述，只講干貨！干貨！干貨！

A、請求地址

需要哪個線上地址就寫哪個。注意不要反低級錯誤，比如寫錯某個字母或者大小寫問題。

B、接口信息

說明請求方式，是POST還是GET。

C、功能描述

清晰地描述接口功能，要求言簡意賅，不要寫太多廢話，也不要遺漏任何細節。

D、接口參數說明

聲明參數的名稱，嚴格要求與調用一致，包括大小寫；

簡單說明參數的含義；

參數的數據類型，是string?、int?還是long等（例如參數為@RequestParam(“appKey”)? String?appKey,? @RequestParam(“randomId”)? Integer?randomId）；

備注部分，說明參數值是需要哪個公司提供，并詳細說明參數怎么生成的，例如時間戳，是哪個時間段的；參數是否必填，一些參數是必須要有的，有些是可選參數，一定要注意寫清晰。

E、返回值說明

有一個模板返回值，并說明每個返回參數的意義。提供一個真實的調用接口，真實的返回值。

F、接口調用限制

為了安全，雙方采用一個一致的加密算法，保證接口調用的安全。

G、文檔維護

文檔維護時，修改內容部分需要有修改人、修改日期、版本號的信息。

三、流程圖

流程圖可以單獨作為一份文件，也可以作為附件附在對應的文檔中，具體執行按要求來。

業務流程圖

程序結構圖

程序流程圖

四、變更文件

在開發過程中如果出現與預期計劃、文檔不一致的地方，則視為發生變更，此時大致需要提供以下信息：

A、版本歷史（版本號、基本信息）

B、變更前現狀

C、變更內容

D、影響評估

E、審批
————————————————
版權聲明：本文為CSDN博主「Fuzz_」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_36186690/article/details/82903265