?【摘要】程序員常會說：我最討厭別人寫的代碼沒有文檔，我也最討厭自己需要寫文檔。

有一個很老的梗: 我最討厭別人寫的代碼沒有文檔，我也最討厭自己需要寫文檔。

有這種想法的程序員應該算是一個老鳥了，對于大多數程序員來說，對于他們來說: 文檔是什么。

對于大規模，超大規模的項目，并且歷時很長，需要大量人員協同開發的項目，沒有文檔簡直不可想象。但是由于時間緊，任務重，大多數的項目中的開發者都沒時間寫文檔，而且，文檔也不計入考核指標，導致開發者也沒有動機寫文檔。這就造成了很多項目都缺少規范化文檔，項目的交接和接口的對齊都是靠口口相傳，接口定義準確度低，并且項目的整體開發效率低下。

作為一個文檔愛好者的筆者來說，平常很重要的一件事兒就是將自己的工作歸納總結并整理成文檔。即便如此，筆者也面臨著很多問題：

• 需求很快就變了，光是改代碼就已經耗盡了我的精力了，哪有時間同步文檔。

• 要么先改代碼，要么先改文檔，總之文檔和代碼之間存在一個不一致錯位期。

除此之外，由于我們主要從事AI相關能力的研發，所以在開發過程中還存在以下特殊的問題：

• 開發者不得不寫大量重復的網絡編程相關的業務代碼，這些代碼的質量通常不高，并且在后期的反復修改中變得越來越臃腫，從而難以維護。

• 因為重復的業務代碼開發工作占比過大，嚴重壓縮智能化研發人員在AI方面的精力投入，這就導致了企業投入大量人力卻無法得到好的效果。

經過不斷的摸索和實踐，AIMS項目組采取了一套文檔驅動的開發模式，可以有效地解決上述在項目中廣泛存在的問題。

1、AI接口開發的特點

不同于傳統API的CRUD接口的開發，AI的開發模式通常包含了以下步驟：

• 數據清洗；

• 模型訓練；

• 參數調優；

• API上線。

前三項都是我們組的強項，也是我們的工作重點。但是在實際工作中，卻是API上線消耗了我們的大部分精力。AIMS項目組大都從事的是AI方向相關的工作，對于API的相關庫flask、tornado也不是很熟悉，這就導致開發人員需要花大量時間去了解網絡編程相關內容，開發出來的程序質量可能也不是很高。而且，在接口開發后，還需要準備一份Swagger UI給前端的開發人員，這又是一項繁重的工作。為了解決如上所述的痛點問題，AI接口開發就需要滿足以下兩個特點和需求：

• API的核心函數是現成的；

• 需要將API開發工作量降到最低。

2、文檔驅動的開發模式

我們發現API的接口文檔中已經包含了實現API接口的所有信息。也就是說，API接口文檔的信息熵和API接口代碼的信息熵是一樣的。因此，我們只需要完成代碼或者文檔中的一項即可，另外一項可以交給框架自動生成，這就避免了把同樣一件事情重復做兩遍的問題。考慮到文檔不論從可讀性、易寫性還是可維護性都勝過代碼，我們決定寫文檔，然后根據文檔生成對應的代碼。

我們參考了OpenAPI Specification3.0.1標準，以及JSON Schema定義了一套API描述語言，開發者基于這個API描述語言撰寫API文檔。當完成文檔時，API的開發工作也隨之完成，大大節省了API接口的開發工作量。經過初步估計，使用文檔驅動模式開發一個API接口，通常可以減少40%–70%的工作量。

3、AIMS框架介紹

為了實現文檔驅動的開發模式，AIMS基于tornado實現了一套Web后端框架，如下圖所示。

(1)ApplicationRouter組件

每一個API都會有一個路徑，即一個正則表達式[1]。一個微服務中的多個API的所有路徑會組成一個API路徑列表。

當Application Router接收到請求時，會根據請求中的URI在路由表中查找。如果匹配到某一個Request Handler，路由模塊會將請求轉發給響應的Request Handler。如果所有的路徑都不匹配，則返回404結果[2]。

(2)RequestHandler組件

Request Handler處理來自Application Router的響應，是AIMS架構的核心，而Document則是Request Handler的核心。在AIMS架構中，Document是指函數的文檔，即__doc__。Request Handler是在服務的啟動階段動態生成的。

事實上，在AIMS架構圖中，只有Document是開發者必須寫的[3]。其它的組件都是由AIMS提供的，或者是由Document自動生成的，所以AIMS開發模式也被稱為文檔驅動型開發模式。開發者只需要維護Document即可，從而實現減少開發者工作量的目的。

(3)Watchman組件

Watchman組件可以通過設置來訂閱某些接口的異常，當被訂閱接口出現任何異常時，Exception Handler便會觸發Watchman組件。

因為Recorder組件記錄了Arguments，Watchman甚至可以自動產生一個可以復現該問題的測試用例，方便開發人員定位問題。

(4)Recorder組件

Recorder是一個采集器，可以采集每一次請求的所有細節信息，包括請求ID、請求參數、遠程IP、被調用的接口、響應時間、工作目錄和進程號等各種信息。這些數據具有以下兩個作用:

• 系統的維護者可以利用Recorder中的數據快速定位，復現現網問題，可以看做是一個更強大的日志系統。

• 通過請求ID，訓練數據收集系統可以將請求參數、響應數據與用戶反饋數據關聯起來，這就相當于是一條有標記的數據。

(5)Logger組件

Logger是AIMS封裝的日志模塊，用法和python自帶的logging.Logger使用方式一致，最大限度地降低開發者的學習成本。

補充說明

我們注意到，在AIMS架構圖中，Argument Parser、Schema Checker、Swagger UI和OpenAPISpecification是同源的，即都是來自Document。這就不會出現文檔(Swagger UI、OpenAPI Specification)與函數實現(Argument Parser、Schema Checker)不一致的情況。開發者也不需要同時維護Argument Parser、Schema Checker、Swagger UI和OpenAPI Specification相關代碼。

以上就是文檔驅動開發在AIMS框架中的優勢，既降低了開發者的工作量，又解決了一致性的問題。事實證明，自動產生的組件質量也是優于開發者自行開發的代碼，并且不易出錯，從而提升整體服務的質量以及穩定性。

[1] 在AIMS開發中，這個字段是寫在__doc__中的api_path字段中。
[2] 事實上，路由模塊會將請求轉發給NotFoundRequestHandler，然后由NotFoundRequestHandler進行響應。
[3] 在AI相關微服務開發過程中，Function，也就是核心功能函數，是已經準備好的。

本文分享自華為云社區《文檔驅動開發模式在 AIMS 中的應用與實踐》，原文作者：zqmillet 。

點擊關注，第一時間了解華為云新鮮技術~

總結

以上是生活随笔為你收集整理的开发接口文档_更优更稳更好，看文档驱动开发模式在AIMS中的优势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。