一、什么是 Keystone ？
對軟件研發(fā)團(tuán)隊(duì)來說，越是頻繁地集成他們的代碼，工作就越輕松。同時(shí)，越頻繁發(fā)布功能迭代，產(chǎn)品就越有價(jià)值。但是團(tuán)隊(duì)并不想把開發(fā)了一半的功能暴露給用戶。對這種矛盾的一個(gè)有效的處理機(jī)制就是先構(gòu)建所有的后端代碼，集成到產(chǎn)品，但不提供用戶界面。這個(gè)功能可以在用戶端無感知的情況下被集成和測試，直到全部完成上線后，再將這個(gè)功能展現(xiàn)給用戶。就像是 Keystone（拱頂石，建筑學(xué)術(shù)語，通常引申為確保其他部件就位的核心關(guān)鍵點(diǎn)）。
二、限時(shí)特價(jià)促銷活動
舉一個(gè)簡單的例子，比如說給用戶推送一個(gè)限時(shí)特價(jià)商品。這樣的訂單一般都需要根據(jù)用戶位置、配送情況等信息確定價(jià)格。所以根據(jù)用戶位置、時(shí)間、商品類型等因素，決定了用戶是否會收到這種限時(shí)特價(jià)商品的推送信息。
總而言之，這是一個(gè)很復(fù)雜的電商運(yùn)作邏輯，因?yàn)樾枰婕皞}儲量、商品目錄、客戶服務(wù)等多個(gè)系統(tǒng)的協(xié)同。完成這樣一個(gè)流程的開發(fā)，可能需要幾周的的時(shí)間，同時(shí)，另一些功能可能需要每隔幾天就發(fā)布一次。而對客戶而言，特價(jià)商品推送只是訂單表格上的一個(gè)選擇框。
在這個(gè)項(xiàng)目中，可以讓選擇框作為 Keystone。研發(fā)團(tuán)隊(duì)可以跨多個(gè)產(chǎn)品發(fā)布周期進(jìn)行內(nèi)部系統(tǒng)的業(yè)務(wù)邏輯和接口開發(fā)。用戶感知不到這些代碼改動。最后一步是讓用戶看到這個(gè)特價(jià)推送的選擇框 UI 界面，通常這用不了多少開發(fā)時(shí)間。這種模式下，所有中間代碼都能夠參與集成，并隨著產(chǎn)品發(fā)布周期部署在線上，這樣就避免了長時(shí)間使用 feature branch（特性分支——一種分支管理模式）帶來的風(fēng)險(xiǎn)。
三、中間代碼和UI界面的測試方式
中間代碼需要像線上代碼一樣接受嚴(yán)格的測試。這需要系統(tǒng)（測試）分層搭建，而不是所有測試都依賴于用戶頁面的觸發(fā)。單元測試和 Test Pyramid（測試金字塔）中的低層測試都應(yīng)當(dāng)可以正常執(zhí)行。甚至 Broad Stack Test 都可以正常執(zhí)行，只要提供一定的機(jī)制使它們成為 Subcutaneous Tests。某些情況下，UI 層本身包含了復(fù)雜的行為，不過只要設(shè)計(jì)得當(dāng)，UI 也可以通過進(jìn)入 Humble Object 的方式得到測試。
并非所有應(yīng)用程序的構(gòu)建方式都支持這種大覆蓋面的"皮下"測試，但即使無法使用 Keystone 模式，這種設(shè)計(jì)原則也是有價(jià)值的。即使用最好的工具去自動化這一過程，從 UI 層觸發(fā)的測試也總是很難搭建的。將更多的測試轉(zhuǎn)移到界面層以下各層級，特別是單元測試層，可以顯著提升部署流水線的速度，實(shí)現(xiàn)持續(xù)交付。
當(dāng)然，大多數(shù)的 UI 變化會比添加一個(gè)選擇框復(fù)雜，即便如此，應(yīng)用 Keystone模式也并不會增加太多工作量。在 Web 應(yīng)用中，一個(gè)復(fù)雜的功能通常都是一個(gè)獨(dú)立頁面，可以作為一個(gè)整體構(gòu)建和測試。這種場景下，Keystone 就是一個(gè)鏈接。桌面應(yīng)用可能設(shè)計(jì)多個(gè)界面變化，這種情況下，Keystone 可以是一個(gè)能展示這些界面的菜單項(xiàng)。
盡管如此，確實(shí)存在一些場景用戶界面不能被簡單地打包通過一個(gè) Keystone 控制。這時(shí)候就需要用到功能開關(guān)了。即便在這種情況下，Keystone 的概念也能夠幫助我們將功能開關(guān)的實(shí)現(xiàn)限定在UI層控制上。這樣可以避免開關(guān)四處散落在后端代碼中，降低了開關(guān)應(yīng)用的復(fù)雜性，更好地貫徹單開關(guān)機(jī)制，也為后續(xù)的開關(guān)清理降低了難度。
四、總結(jié)
后端先行，最后再開發(fā) UI 界面的方式也存在一個(gè)潛在的風(fēng)險(xiǎn)，就是后端代碼的設(shè)計(jì)可能無法與后開發(fā)的UI協(xié)調(diào)一致，或者在后期UI實(shí)現(xiàn)時(shí)才發(fā)現(xiàn)設(shè)計(jì)點(diǎn)遺漏，這會導(dǎo)致反饋延遲并帶來糟糕的用戶體驗(yàn)。因此，只有在產(chǎn)品上支持功能垂直劃分，研發(fā)上能夠按功能粒度快速發(fā)布的團(tuán)隊(duì)中，Keystone 模式才能夠發(fā)揮最大的價(jià)值。
在這里我只是舉例了一個(gè)用戶界面的小例子，但同樣的方法適用于任何界面變化，例如 API。通過最后再提供用戶界面，并且保持簡潔的方式，即使是很大的功能升級，我們也可以通過逐個(gè)部分增量構(gòu)建、集成來完成。
在 FeatureProbe 就可以實(shí)現(xiàn) Keystone 模式，做到后端代碼與UI 界面分開部署測試。研發(fā)團(tuán)隊(duì)可以先開發(fā)后端代碼部署，用戶側(cè)無感知這一塊功能核心功能已經(jīng)部署到系統(tǒng)上了，確保新功能后端代碼沒有問題后，在 FeatureProbe 后臺操作頁面，可以一鍵開啟 UI 界面功能，測試 UI 界面功能沒有問題后，再將這個(gè)新功能開放給用戶。
目前 FeatureProbe 使用 Apache 2.0 License 協(xié)議已經(jīng)完全開源。你可以從 GitHub 或 Gitee 獲取到所有源碼。
與此同時(shí)，我們提供了無需部署的在線試用環(huán)境和一個(gè)僅需5分鐘即可體驗(yàn)的示例項(xiàng)目。
