為了解決系統實現與設計在持續迭代過程中的一致性等問題，BizWorks提供了一種代碼與平臺模型的雙向聯動機制。本文介紹BizWorks雙向聯動機制，以及如何使用BizWorks提供的相關能力，將代碼與平臺模型的雙向聯動順暢融入到已有的研發流程中。
背景信息
由于產品的迭代交付周期、人員的組成、成員能力和職責分配等因素，研發團隊的協作模式存在不同的風格，也會在團隊成長過程中形成一些特有的團隊默契和設計。BizWorks雙向聯動相關的功能點在模型設計、應用研發階段都有涉及，您可以按需靈活搭配使用，能夠適應不同團隊的風格。而對于我們某一特定的團隊或項目，通常希望能快速簡單上手，形成一種行之有效的研發流程。
BizWorks雙向聯動機制概述
模型是對領域知識嚴格的組織，且有選擇的抽象，是濃縮的知識。當然，只有其與實現之間具有緊密聯系，才是有用的模型，否則就與代碼的注釋一樣，“糟糕的注釋，不如沒有注釋”。雙向聯動機制的直接能力就是保持迭代過程中模型和代碼的緊密聯系。
平臺模型：BizWorks平臺可以幫助我們設計、審查、分發、沉淀、演進企業數智化轉型中的各類重要模型，模型自然是平臺的核心之一。我們將沉淀到平臺中的模型稱為平臺模型。
代碼反映模型：遵照BWAF規范、通過平臺生成的代碼或通過人工識別標注關聯的代碼，代碼實現也可以反映出其對應的模型。我們將代碼中反映出來的模型稱為代碼反映模型，在IDEA插件中相對于平臺模型，也簡稱代碼反映模型為本地模型（研發人員本地代碼反映出的模型）。
平臺模型和代碼的雙向聯動主要邏輯行為有代碼生成、代碼掃描、模型上報。在平臺和IDE插件中分別有不同的操作與之對應。
雙向聯動研發流程
不區分角色權限的簡單雙向聯動研發流程
簡單流程考慮研發人員同時擁有模型和代碼的操作權限，研發人員對自己實現業務所對應的代碼與模型同時負責。在這種場景下，不嚴格區分模型設計角色或代碼編寫角色。簡單雙向聯動研發流程如下圖所示。
研發人員可以在流程中隨時修改自己負責的代碼和平臺模型，通過BizWorks使其雙向一致。您也可以選擇發起代碼評審，讓更多的研發人員一起評審代碼和模型設計。
上圖中雙向聯動研發流程的詳情如下：
應用創建，并綁定關聯關系：BizWorks平臺DevOps核心之一是應用，所以需要先創建應用。同時關聯業務領域和商業能力。具體操作，請參見創建和管理中心應用。
腳手架生成：應用創建后，我們會以應用為維度組織代碼。您可以選擇關聯已有倉庫或創建新的倉庫，然后通過平臺的腳手架生成功能生成初始的代碼腳手架。具體操作，請參見生成代碼。
DDL腳本導出創建庫表：除了代碼腳手架的生成之外，我們也會借助DDL腳本導出快速創建好對應的庫表。
拉出迭代開發分支：進入正常的迭代開發節奏，假設每個迭代會有特定的開發分支（或特定的Feature分支或其他分支，取決于我們的分支模型）。
Pull開發分支代碼：以研發人員的視角，在本地Checkout出開發分支代碼。
在本地開發：研發人員正常開發。
模型變更：在平臺對模型進行變更，如添加字段、修改方法簽名或新增模型等。
通過IDE插件同步模型信息到本地，進行實時一致性校驗：IDE插件可以在同步平臺模型信息后對代碼反映模型進行對比校驗。更多信息，請參見查看和調整BizWorks相關校驗規則提示級別和觸發檢查和快速修復本地代碼。
通過IDE插件增量生成，同步模型變更到本地代碼：IDE插件可以直接將模型的變更同步到本地模型對應的代碼上。具體操作，請參見同步平臺模型到本地代碼。
通過IDE插件標注代碼為模型或創建新的模型：您也可以在本地通過標注或創建等方式修改已有模型，或新增模型。具體操作，請參見快速標記代碼為模型和手動新建本地模型代碼。
提交推送代碼，按需發起代碼評審：本地代碼修改可以正常提交推送和代碼評審。
通過IDE插件，快速提交代碼中模型變更到平臺：本地通過步驟11新增或修改的代碼反映模型可以通過IDE插件快速掃描提交到平臺。具體操作，請參見在Tool Window掃描本地模型。
通過以上步驟普通的平臺模型的變更同步到代碼，以及代碼側的變更上報到平臺都已達成。接下來我們看一下數據模型的變動如何同步。
數據庫調整：平臺的數據模型調整，可通過步驟4修改庫表（這個步驟可以從直接修改數據庫開始）。
最新庫表導入數據模型：通過BizWorks平臺功能，將最新的庫表導入數據模型。
按需調整關聯：如果平臺模型版本有變動，可以在應用平臺的模型管理中關聯最新的模型版本。
平臺增量代碼生成：數據模型目前需要通過平臺的代碼生成功能增量生成模型變動到代碼中。增量生成的代碼可以基于已有分支生成到新分支。新生成的分支會生成到代碼倉庫中，后續研發人員可以拉取新分支到本地，并選取其中需要的部分修改合并到開發中的分支。
步驟17之后，可以重復步驟6之后的流程，不斷迭代修改代碼和平臺模型。
上述為研發階段簡單流程中平臺模型和代碼的雙向聯動流程。以上的流程介紹較為簡單，主要是介紹一種可能的且較為普遍的雙向聯動流程。上述流程各個步驟之間的順序也并非嚴格順序，可以靈活組合。
引入角色權限區分的雙向聯動研發流程
在不區分角色權限的簡單雙向聯動研發流程中，研發人員同時擁有模型和代碼的操作權限，對代碼和模型同時負責。但有些團隊可能對研發人員有較為明確的角色區分，只有特定的負責人需要對平臺模型設計和關鍵操作進行管控操作。因此，我們在簡單流程的基礎上引入權限區分。下圖中綠色部分線條是需要有權限管控的操作，黑色的線條是不需權限管控的研發操作。
上圖中的引入角色權限區分的雙向聯動研發流程與不區分角色權限的簡單雙向聯動研發流程的區別詳情如下：
步驟1~4無區別，步驟5由負責人創建好對應的迭代分支后，同時將迭代分支設為保護分支，只有迭代負責人有權限提交合并。
步驟6研發人員在本地拉取開發分支。
步驟7在開發分支基礎上Checkout Feature分支或個人開發分支，并在本地開發。因為迭代的開發分支是設保護的，屬于權限管控分支。研發人員需要在普通的分支上面開發，后續再通過代碼評審后合并到權限管控的迭代開發分支上。
步驟9~11單向從平臺同步平臺模型信息到本地，對本地代碼變更與不區分角色權限的簡單雙向聯動研發流程并無區別。
步驟12提交推送代碼并發起代碼評審，此處的代碼評審是必須的，迭代負責人需要對代碼以及代碼反映的模型進行審核。
步驟13代碼審核，Pull開發分支最新代碼，調整開發。在研發發起代碼審核后，迭代負責人需要審核和調整。除了代碼審核外，模型的審核負責人需要借助插件或平臺掃描代碼并與平臺模型對比。如果需要修改調整則需要拉取代碼到本地。
步驟14通過IDE插件雙向同步，負責人可以將代碼拉取到本地后借助IDE查看代碼Diff，也可以借助IDE插件對代碼和平臺模型進行雙向同步。因為負責人擁有模型修改權限，同步過程與不區分角色權限的簡單雙向聯動研發流程沒有區別，可以參考其步驟9~13。
步驟15~18為數據模型變動增量到代碼，與不區分角色權限的簡單雙向聯動研發流程并無區別。
上述流程中，對于代碼和代碼反映模型的變動需要有權限管控。
因為代碼反映的模型和代碼是一體的，所以借助代碼的保護分支、代碼評審、合并的權限管控機制，把代碼反映模型變動后的模型上報的操作管控機制融入其中。沒有權限的研發人員只可以單向同步平臺模型到代碼中。擁有權限的負責人在接受了代碼合并后，再按照不區分角色權限的簡單雙向聯動研發流程的上報機制把代碼反映模型上報到平臺，即完成了有權限區分下的雙向聯動。