摘要：程序員常會說：我最討厭別人寫的代碼沒有文檔，我也最討厭自己需要寫文檔。
有一個很老的梗: 我最討厭別人寫的代碼沒有文檔，我也最討厭自己需要寫文檔。
有這種想法的程序員應該算是一個老鳥了，對於大多數程序員來說，對於他們來說: 文檔是什么。
對於大規模，超大規模的項目，並且歷時很長，需要大量人員協同開發的項目，沒有文檔簡直不可想象。但是由於時間緊，任務重，大多數的項目中的開發者都沒時間寫文檔，而且，文檔也不計入考核指標，導致開發者也沒有動機寫文檔。這就造成了很多項目都缺少規范化文檔，項目的交接和接口的對齊都是靠口口相傳，接口定義准確度低，並且項目的整體開發效率低下。
作為一個文檔愛好者的筆者來說，平常很重要的一件事兒就是將自己的工作歸納總結並整理成文檔。即便如此，筆者也面臨着很多問題：
- 需求很快就變了，光是改代碼就已經耗盡了我的精力了，哪有時間同步文檔。
- 要么先改代碼，要么先改文檔，總之文檔和代碼之間存在一個不一致錯位期。
除此之外，由於我們主要從事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后端框架，如下圖所示。
3.1. Application Router組件
每一個API都會有一個路徑，即一個正則表達式[1]。一個微服務中的多個API的所有路徑會組成一個API路徑列表。
當Application Router接收到請求時，會根據請求中的URI在路由表中查找。如果匹配到某一個Request Handler，路由模塊會將請求轉發給響應的Request Handler。如果所有的路徑都不匹配，則返回404結果[2]。
3.2. Request Handler組件
Request Handler處理來自Application Router的響應，是AIMS架構的核心，而Document則是Request Handler的核心。在AIMS架構中，Document是指函數的文檔，即__doc__。Request Handler是在服務的啟動階段動態生成的。
事實上，在AIMS架構圖中，只有Document是開發者必須寫的[3]。其它的組件都是由AIMS提供的，或者是由Document自動生成的，所以AIMS開發模式也被稱為文檔驅動型開發模式。開發者只需要維護Document即可，從而實現減少開發者工作量的目的。
3.3. Watchman組件
Watchman組件可以通過設置來訂閱某些接口的異常，當被訂閱接口出現任何異常時，Exception Handler便會觸發Watchman組件。
因為Recorder組件記錄了Arguments，Watchman甚至可以自動產生一個可以復現該問題的測試用例，方便開發人員定位問題。
3.4. Recorder組件
Recorder是一個采集器，可以采集每一次請求的所有細節信息，包括請求ID、請求參數、遠程IP、被調用的接口、響應時間、工作目錄和進程號等各種信息。這些數據具有以下兩個作用:
- 系統的維護者可以利用Recorder中的數據快速定位，復現現網問題，可以看做是一個更強大的日志系統。
- 通過請求ID，訓練數據收集系統可以將請求參數、響應數據與用戶反饋數據關聯起來，這就相當於是一條有標記的數據。
3.5. Logger組件
Logger是AIMS封裝的日志模塊，用法和python自帶的logging.Logger使用方式一致，最大限度地降低開發者的學習成本。
4. 補充說明
我們注意到，在AIMS架構圖中，Argument Parser、Schema Checker、Swagger UI和OpenAPI Specification是同源的，即都是來自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 。