標準化技術下的軟件開發

2019 年 10 月 8 日
筆記

聊到集成測試、單元測試等測試分類，我想大多數人都有類似困惑或討論，集成測試和 E2E 測試到底有啥區別。甚至還有一些系統測試、配置項測試等概念，不但讓我們這種非 QA 專業的人弄不清楚，在和我們的 QA 同學討論時也很難得到清晰的結論。

家裡有一台古董級別的筆記本，掌托和鍵盤幾乎已經被磨花了，一天突然想檢查下有沒有特別的資料然後好處理掉它。一份測試相關的國標文檔（GB/T 15532-2008）吸引了我的注意，這份文檔來自於剛畢業時在四川省軟件測試中心實習期間，而我幾乎已經忘記了那段經歷。

翻看這份文檔讓我打開了一個新世界的大門，我們目前討論研究的很多問題包括測試分類的定義，已經被業界討論過很多次，甚至被制定成清晰的文檔和規範。

不僅是 GB/T 制定了相關標準和大量方法，IEEE 和 IOS 也定義了大量標準供業界參考。在軟件工程中，了解相關標準能給我們帶來非常多的好處，能幫助我們更好地做技術選型、企業應用集成、持續演進以及借力技術生態。

採用標準技術的優勢

發展成熟

在計算機科學領域，技術標準最成熟，和學術界最接近的是密碼學。在軟件行業中，最有意思的是很多人對造輪子非常感興趣（包括我），不過有一些輪子我不建議自己造，其中之一就是加密算法。不止一個人在聊天中談起對信息安全的看法時說，「要是我開發一個自己的加密算法、只有我自己的知道（甚至很多真的這麼幹了），肯定是天底下最安全的。」這是一種非常樸素的信息安全認識，自己的創造的「加密算法」也只是根據特定規則對信息的混淆和變換，安全性依賴於加密算法而非密匙，這甚至落後於凱撒密碼。

現代密碼學已經有大量的對稱加密、非對稱加密、HASH公開算法，甚至建立了一套完整的通信信息安全基礎設施（PKI）。因為加密算法足夠可靠，對於普通開發者而言，保證信息安全的是密匙而不是加密算法。與其閉門造車，不如選擇 RSA 等大師們的成果。

上面的例子是想說標準的技術大多經過學術界、工業界的驗證，相對來說比自己搗騰一個更為靠譜。

技術生態

選擇標準技術另外一個好處是保持開放，能構建出一個技術生態。

稍具規模的公司或者組織都有一個中心化的賬戶管理體系，在軟件公司我們有一大套內部系統和軟件需要和賬戶系統進行對接，賬戶系統還被要求以很細緻的粒度對權限進行管理。比如辦公室的 WIFI、JIRA、郵件、WIKI 等平台需要對接賬戶系統，一些採購的軟件可能並不需要我們進行修改就能實現接入，這其中需要一個約定。

其中一個規範叫做 LDAP，JIRA、郵件、開源 WIKI 平台支持 LDAP 服務器的接入，甚至國內的軟件產品例如禪道也支持 LDAP 接入。

LDAP 只是眾多開放標準的一部分，互聯網天生具有開放性，因此網絡通信和互聯網涉及的協議多如牛毛。例如我們的以太網協議 IEEE 802.x、HTTP 協議（RFC 723X）。僅僅網絡協議就有數千條，甚至有一點不忍心放上下面這張圖。

採用標準技術還有其他優勢，具體的實現很容易被替換。例如實現 HTTP 協議的客戶端很容易被替換，前幾天在和一個同事聊到他們在項目上把 Apache 的 HTTP Client 替換成了 OK HTTP；如果在項目中使用了符合 JCP 定義的 Java Bean Validator 也可以容易的在某些場景下被替換。

不過值得注意的是業界事實標準有時候和一些標準化組織制定的標準並不一致，OSI 7 層協議被稱為經典的網絡協議，但是目前廣泛形成的協議族是 TCP/IP 協議族。

日常相關的標準技術和組織

在使用開源項目做技術選型時，如果對技術標準有一些了解，可以幫我們更容易的了解一些技術的生態和工具鏈。比如上面的 LDAP，我們可以在採購軟件時優先考慮支持 LDAP 的產品，從而降低自行接入的成本；對於自己項目上更為具體的實現，如設計 API，我們可以選擇一套參考標準，如 JSON:API，讓溝通成本大大降低；在前後端協作上，如果採用 Swagger 的 OpenAPI 可以容易的找到一套開源工具幫我們完成文檔、SDK 生成等工作。

下面讓我們一起了解一些互聯網常見的技術標準和組織。

IETF

IETF 應該是互聯網標準組織中名氣最大的，它的全稱是國際互聯網工程任務組（The Internet Engineering Task Force）。IETF下屬有很多工作組（WG），專門負責一個領域標準的制定，例如 OAuth。IETF 工作的產出主要是 RFC 文檔（Request For Comments）。IETF 最知名的規範是 TCP/IP 協議族，但是我們日常相關更多關注應用層標準，就不介紹通信相關的協議了，下面是一些常見應用層的標準。

RFC 723X HTTP 協議族 HTTP 標準分為多個版本，目前在用的一般是 1.1。同時 HTTP 標準分為核心標準和拓展標準，例如緩存、會話、內容編碼等內容屬於拓展部分，在選擇 HTTP client 時，需要注意其實現程度可能並不完整。另外 method、狀態碼等枚舉類型在 IANA 中心可以找到。
OAuth 開放授權協議 OAuth 相關規範和HTTP類似，也分為核心和拓展。核心的標準文檔是 RFC 6749 ，而拓展的部分例如 Bearer token 以及 token 的獲取、驗證和JWT相關的規範都在另外的文檔中。值得一提的是，OAuth OpenID connect 不屬於 OAuth 的規範，所以認證並不是 OAuth 要求的。

(圖片來自：網絡)

JCP

JCP（Java Community Process) 是一個開放的國際組織，主要由 Java 開發者以及被授權者組成。Java 之所以能發展成目前這個規模，離不開標準化進程，JCP 中的一些規範不僅影響了 Java 世界，對其他語言，例如 PHP、Nodejs 也造成了巨大的影響。在日常服務器開發工作中，用到 JCP 標準非常多，例如數據驗證、數據庫訪問和服務器容器：

Bean Validation：在 Java 中數據校驗的規範化是 JCP 一個典型的實踐，從最早的 JSR 349 到 JSR 303，目前已經發展到了 Bean validation 2.0，並從之前只支持 J2EE 到開始支持 J2SE。Hibernate 最新的 validator 已經開始支持 2.0 的驗證規範。早期講 Java 的書談到使用 JSR 驗證容易讓人感到困惑，JSR 只是驗證規範，數據驗證是由其他的驗證器實現的。同時一些為 Java 之外編程語言設計的驗證框架也參考了 JCP 的標準。
JPA Java Persistence API：JPA 定義了對象關係映射以及如何持久化到數據中，JPA、ORM、Hibernate 在 Java 開發時是非常容易被混淆的概念。其中 ORM 只是一個對象映射的概念，JPA 規範了 ORM、數據訪問 API、查詢語言，Hibernate 對 JPA 進行了實現，JPA 其他的實現還有 Open JPA 和 Eclipse Link 等技術。
JAX-RS Java API for RESTful Web Services：JAX-RS 定義了 Restful API 構建相關的規範，包括一些常見的註解都來源這個規範，例如 @Path @GET 等，關於 JAX-RS 的實現除了 Spring 全家桶之外，還有 Jersey、RESTeasy 等實現。
Java Servlet：Servlet 可以說是 J2EE 中最重要的規範之一，如果不去看 Servlet 的規範很難理解 Servlet 到底是什麼，這也是很多公司面試一般都會問的問題。Servlet 定義了 J2EE 應用和服務器容器之間的約定，所以在開發過程中就需要特別注意 WEB 容器提供的額外的特性，以免造成耦合。

W3C

W3C 中文名稱是萬維網聯盟，是Web技術領域最具權威和影響力的國際中立性技術標準機構，主要負責制定瀏覽器上一些技術細節，降低瀏覽器上 HTML、CSS 渲染之間的差異，以及 DOM、XML 和 SVG 等技術。但是需要注意 JavaScript 不是 W3C 的範圍，但需要負責瀏覽器中 JavaScript API 也就是 DOM 規範的制定：

DOM 在前端開發中，如果想了解更多瀏覽器渲染原理和處理 DOM 節點，推薦閱讀 W3C 的規範文檔，DOM 規範文檔中描述了 DOM 節點的構建、移除以及事件等信息。
CSP 內容安全策略 CSP 制定了瀏覽器中加載資源的策略，通過配置讓瀏覽器是否能加載一些資源，例如腳本，能大大提高瀏覽器對 XSS 攻擊的防禦能力。
XML 嗯，XML 是W3C制定的規範。

W3C 的標準更多的是指導瀏覽器開發，對於前端開發來說，技術選型取決於瀏覽器支持情況。

(圖片來自：網絡)

ECMA

ECMA 中文名稱是歐洲計算機製造聯合會，主要負責計算機製造和編程相關的標準制定。ECMA 制定了許多編程語言的規範，例如 C#、C++ 等，有趣的是 Sun 公司曾經提交了 Java 相關標準給 ECMA 但是隨後又撤銷了。ECMA 下面有幾個我們可能特別關注的規範：ECMAScript、JSON 和辦公文檔規範。

ECMAScript ECMAScript 的前身是網景的 JavaScript 和微軟的 JScript，後來網景、微軟、sun 等公司提出標準化瀏覽器中的腳本語言，於是JavaScript 被提交到 ECMA，JavaScript 就成了 ECMA-262 標準化的腳本程序設計語言。目前實現 ECMAScript 規範的還有用來製作 Flash 的 ActionScript。
JSON 是一種輕量級的數據交換格式，實際上是 ECMAScript 的一個子集，但是目前來說和語言關係不大，JSON 過於常見，就不講了。
Office Open XML ECMA 下另外一個非常重要的規範，簡稱 OOXML，現已成為國際文檔格式標準。如果在項目中需要使用編程的方式解析 word 文檔，參考這個規範下的實現。

其他規範

一些組織或者廠商想推廣一些通用的技術方案，但是並沒有註冊到標準組織。其中有很多技術方案對日常工作很有價值，這裡也羅列出來：

JSON:API 有時候在設計 Restful 時很頭疼，Restful 只是一種設計理念，沒有具體的編碼實現，RESTful 甚至不是具體的規範。jsonapi.org 這個網站試圖創建一個規範來定義 RESTful API，並且定義了一個新的 MIME 類型 application/vnd.api+json 註冊到了 IANA。
HAL Hypertext Application Language 於是有一些組織開始着手準備把 Restful 的請求內容規範化，形成一個統一的語言，這就是 HAL。目前不止一個組織在制定相關規範，IETF 目前都還在草案階段。
RAML 當 RESTful API 被設計出來後，如何描述 API 模型又是一個挑戰，API 模型可以用於文檔、契約測試和SDK生成。如果這種模型被規範化，可以帶動整個工具鏈。API 模型目前有 RAML 和 Swagger 主導的 OpenAPI
Microformat 微格式在 HTML 或者 XML 中，為了讓標記語言更為語義化，用於第三方應用程序識別，出現了微格式這類規範。例如，航空公司通過 HTML 格式的郵件發送了機票信息，郵件客戶端可以通過微格式識別其中的關鍵信息，並添加到提示列表中。
Commonmark MarkDown 語法規範。
GraphQL API 查詢的語言通過發送 GraphQL 語句給服務器可以針對的返回特定的數據，避免多次請求和冗餘數據在網絡上傳輸。

總結

為技術標準化做出貢獻的組織還很多，特別是在軟件行業之外，建築、醫療、金融等行業也產出了大量的標準文檔。在知識的層層傳遞中有很多信息丟失了，標準文檔給我們提供了第一手、清晰的信息和方案。

遺憾的是我們在做的一些創新型的工作目前還沒有被標準化，CI/CD、敏捷實踐、微服務等。在 ThoughtWorks 辦公室每個人都耳熟能詳的技術或者術語還沒有出現在標準文檔中，也可能是我還沒了解到，不過各大組織的規範文檔不失為一座金礦，值得持續探索。

另外，中國是第一製造業大國，也是發達的互聯網國家。除了國家標準之外，參與國際標準制定還比較有限。互聯網協議幾乎是構建在 IEEE 貢獻的協議族之上，難以看到中國的影子，不過在 5G 時代有所發展。這兩年國內的開源項目發展迅速，也有一些大廠在向國際標準組織做出貢獻，很期待我們也能參與其中。

– 相關閱讀 –