需求代碼化，即將軟件開發需求抽象爲特定的領域語言，並使用管理代碼一樣的方式來管理需求，追蹤需求的變化 。同時，爲通過新的 API 來對接版本管理系統，以可視化需求，演變爲看板代碼化。
爲了解決某種需求/需要，我們計劃設計一個軟件系統。通過與利益相關者進行交流之後，確認了新的系統是有必要存在的。於是，我們產生了一系列的概念和想法，並通過諸如願景梳理、用戶分析等一系列的想法，我們將這些想法明確下來。
在開始軟件開發前，我們定義好了產品是什麼，隨後梳理出了用戶故事地圖。我們定義了在什麼場景下，需要哪些用戶，在哪裏做些什麼事情，並對這些行爲做出響應。有了這些定義之後，我們作爲這個系統的架構設計師，便開始思考需要保存、顯示哪些數據，才能完成這個業務目標。
在進入開發之前，這些想法設計等，都被明確爲軟件需求，簡稱爲需求。
軟件需求指爲用戶解決某一問題或達到某一目標所需的軟件功能；系統或系統構件爲了滿足合同、規約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能。
爲了進入萬物代碼化的世界，首先我們得準備一堆機制，以將物理世界的目標轉換爲軟件問題。即我們要將軟件需求，轉換爲代碼。
引子 1：需求關聯對應代碼
事實上，關於這部分的內容已經存在了很久了。
早期，我們在項目上使用 Atlassian Bamboo + Atlassian Jira 時，它們已經可以非常好地配合在一起。你可以從持續集成上，直接跳轉到需求處。
另外一種模式，則是透明的開源模式。如 GitHub 的 issue 與提交信息的關聯，使得我們可以通過 done #123or fixed #123 的形式來關聯一個 issue（可能是需求），並關閉這個 issue。
反之，我們可以通過一個需求，來找到對應的代碼提交。
引子 2：提交信息規範化
作爲一個懶散的開源項目造輪子工程師，我習慣性地採用了社區規範的提交信息，以便於生成項目的 ChangeLog。諸如於： docs(changelog): update change log to beta.5，它遵循的是如下的示例：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
如下是部分類型的示例：
build: 影響構建系統或外部依賴關係的更改（示例範圍：gulp，broccoli，npm）
ci: 更改我們的持續集成文件和腳本（示例範圍：Travis，Circle，BrowserStack，SauceLabs）
docs: 僅文檔更改
feat: 一個新功能
fix: 修復錯誤
perf: 改進性能的代碼更改
refactor: 代碼更改，既不修復錯誤也不添加功能
style: 不影響代碼含義的變化（空白，格式化，缺少分號等）
test: 添加缺失測試或更正現有測試
爲了這套提交信息模板，我們就可以結合 git-cz 這樣的工具，在本地進行提交信息的規範化。同時，在 Git 服務器裏，設置對應的提交信息門禁——即如果提交信息不滿足規範，則代碼無法提交到服務器中。
與之更爲相似的一個概念是：
代碼門禁能夠確保每一個進入主分支的commit都達到了一定的質量標準，例如：編譯必須通過，單元測試和接口測試必須通過，新代碼的覆蓋率不能低於某個水平，靜態代碼掃描必須通過。
引子 3：行爲驅動開發語言
BDD 這個東西，大家都比較熟了。這裏就不詳細介紹了：
行爲驅動開發（英語：Behavior-driven development，縮寫BDD）是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協作。
流行的 BDD 工具 Cucumber 背後是一個名爲 Gherkin 的 DSL，它用於描述需求及測試。
功能:
場景:
假設:
當:
並且:
那麼:
換句話來說，它可以作爲我們的需求描述語言規範。
引子 4：三段式結構
三段式，大家都比較熟悉，我們可以按自己的需求，將所有的東西都轉化爲三段式：
BDD 的：Given - When - Then
UI 設計的顯示 - 行動 - 響應
前端開發的：展示 - 事件 - 響應
HTTP 請求的：request - handle - response
代碼的：輸入參數 - 處理 - 輸出結果
測試的：Arrange-Act-Assert
……
如果不熟悉的話， 可以簡單地看一下我之前設計的一個設計語言示例：
SEE HomePage
DO [Click] "Login".Button
REACT Success: SHOW "Login Success".Toast with ANIMATE(bounce)
就這麼簡單。
引子 5：源碼控制管理而非數據庫
在上一篇文章《文檔代碼化》中，我們已經建議了開發人員使用像代碼一樣的文檔語言，使用 Git 來管理文檔。它有這麼一些優點：
高透明性
高自治性
不可篡改性
高安全性
這可不是區塊鏈技術，這是需求代碼化技術，【狗頭】。當我們的需求變成了代碼，那麼我們就有了一個去中心化的看板。
需求代碼化
好了，現在我們有相同的上下文，讓我們回到正題上：
需求代碼化，即將軟件開發需求抽象爲特定的領域語言，並使用管理代碼一樣的方式來管理需求，追蹤需求的變化 。同時，爲通過新的 API 來對接版本管理系統，以可視化需求，演變爲看板代碼化。
它具備這麼一些特徵：
使用標記語言編寫內容。如 Cucumber
可通過版本控制系統進行版本控制。如 git
與編程一致的編程體驗，還可以作爲測試代碼的一部分
支持集成到現有的看板系統中
可集成到 IDE 中協作
支持 Git 轉換爲 CRUD 接口
爲了進一步實現萬物即代碼，它還具備這麼一些特徵：
可對需求進行重構
可轉化爲設計語言
或許，聰明的你已經知道了怎麼做這樣的系統了。
如何實現需求即代碼
事實上，我們在五個引子中標明瞭我們所需要的要素：
設計需求代碼化 DSL
過渡 API 設計
REST 接口轉換 SCM 接口（如 Git）
靜態 API 生成（用於燃盡圖等）
IDE 集成看板
DSL 可視化看板
刪除原有的看板系統
稍有不同的是，我們要進一些額外的設計。
最小需求模型
在我們對需求進行建模的時候，我們需要考慮一個需求的最小要素，如下：
ID
開始時間
結束時間
優先級
狀態
作者
開發者
標題
【狗頭】，這個是我在設計 phodal/design 時候設計的字段，順便一提。
重新設計需求的組織形式
現有的看板系統都存在一個問題，只讓業務人員寫一個標準答案。而缺少中間的過程設計，因此如果想降低編寫需求的成本，那麼應該重新設計一下需求的組織形式。現有的需求的組織形式，有：『影響地圖』和『用戶旅程地圖』。
其實我們要做的事情很簡單，即我們只有最後能可視化出『用戶旅程地圖』即可，然後往 DSL 添加新的字段即可。
需求 DSL 的要素
如果現有的三段式 DSL 不滿足需求，那麼可以回過頭來看看需求的要素是什麼？
目標。系統的業務價值，基於價值確定功能和需求的優先級。
人員。使用系統的人員以及業務流程和目的。
系統。存在什麼系統，用戶界面是什麼樣，系統間如何交付，系統的性能怎麼樣？
數據。三者的關係，從最終用戶角度看到的業務數據對象、數據的生命週期、報告中數據對決策的影響。
基於這四要素，我們可以重新設計我們的需求 DSL。
NLP 建模過程
在我們的系統進一步完善之後，我們要採用 NLP（自然語言處理）對需求進行分析，從中提取上述所涉及的四要素，進而將需求轉換爲代碼。
提取名詞
抽象行爲
關注數據及狀態
建模
實例化
……
考慮到寫需求的業務人員並不會爲難這個系統（譬如寫一個多重否定），NLP 並不會太複雜的。
原型示例
接着，讓我們來看我去年寫的一個示例，基於 Cucumber + 其註釋設計的：
# id: TUgT7FxZg
# startDate: 2019-11-22T01:56:41Z
# endDate: 2019-11-22T02:06:48Z
# priority:
# status: thinking
# author: phodal
# title: image to dsl
# language: zh-CN
@math
Feature:image to dsl
Scenario: 作爲設計師，我想直接獲得一份草圖生成的 DSL
Given 設計
When 當我在設計的時候
Then 我能將草稿轉成 DSL
Then 這樣我能直接將草圖轉成 SVG
Then 開發人員可以直接修改代碼
通過 CLI 就可以查看對應的情況，諸如於：
+-----------+--------------------------------+----------------------+--------+--------+
| ID | TITLE | DATE | STATUS | AUTHOR |
+-----------+--------------------------------+----------------------+--------+--------+
| CYJlzObWR | add docs to README | 2019-11-21T15:33:50Z | | |
+-----------+--------------------------------+----------------------+--------+--------+
| Dyp0iOxZg | use cucumber tag as file s | 2019-11-21T15:45:47Z | | |
| | group | | | |
+-----------+--------------------------------+----------------------+--------+--------+
並且它作爲代碼的一部分，貫穿在整個應用的生命週期中。
GitHub：https://github.com/phodal/story
需求代碼化成熟度
爲了方便大家後期完善這個系統，我決定寫一個簡單的成熟度模型。
0. 模板化需求
最簡單的模式就是採用 Cucumber 的語法，它包含了現成的語法和 IDE 支持等。對於開發人員、測試人員、業務人員也比較熟悉。
1. 需求代碼化
如上。
2. 需求像代碼一樣管理
設定需求門禁
不滿足原則時（如 INVEST 原則），無法提交需求
3. 看板即代碼
簡單來說，就是：
支持 Git 的 CRUD
支持將現有的看板對接到 Git API
4. 需求關聯設計
NLP（自然語言處理），進行分詞的狀態轉換設計。
需求建模語言。
需求的自動化測試
即能從需求中，識別中目標、系統、人員和數據等四個要素。
5. 需求轉換代碼
需求轉換爲設計代碼 DSL，即我下一步要做的事情。
重構需求
Wow，現在我們已經成功地把文本代碼化了，那麼下一步就能重構這些代碼（需求了）。
結論
參考書籍：
-《軟件需求與可視化模型》