與團隊審閱
在第 4 章中，我們將學習專業的工作流程，以改進設計系統，同時減少不一致性。本章涵蓋收集 UI 回饋並與團隊達成共識的技巧。這些生產流程被 Auth0、Shopify 和 Discovery Network 的人員使用。
單一事實來源或單一故障點
先前，我寫過設計系統是前端團隊的單一故障點。 本質上，設計系統是一種依賴性。 如果您變更設計系統元件，該變更會傳播到依賴的應用程式。 分發變更的機制是公正的——它同時發布改進和錯誤。
錯誤是設計系統的生存風險，因此我們將盡一切努力防止它們。 微小的調整最終會像滾雪球般變成無數的回歸。 如果沒有持續的維護策略，設計系統就會枯萎。
「但它在我的機器上可以運作啊！？」—— 每個人
與您的團隊一起視覺化審閱 UI 元件
視覺化審閱是確認使用者介面的行為和美觀的過程。 它發生在您開發 UI 時和團隊進行 QA 期間。
大多數開發人員都熟悉程式碼審閱，即從其他開發人員那裡收集程式碼回饋以提高程式碼品質的過程。 由於 UI 元件以圖形方式表達程式碼，因此視覺化審閱對於收集 UI/UX 回饋是必要的。
建立通用參考點
刪除 node_modules。重新安裝套件。清除 localstorage。刪除 Cookie。如果這些操作聽起來很熟悉，您就會知道確保隊友參考最新程式碼有多麼困難。當人們沒有相同的開發環境時，要辨別問題是由於本地環境還是實際錯誤引起的，簡直是一場噩夢。
幸運的是，作為前端開發人員，我們有一個通用的編譯目標：瀏覽器。 精明的團隊將他們的 Storybook 發布在線上，作為視覺化審閱的通用參考點，避免了本地開發環境固有的複雜性（無論如何，成為技術支援人員都很煩人）。
當可透過 URL 存取即時 UI 元件時，利害關係人可以從瀏覽器的舒適度確認 UI 的外觀和風格。 這表示開發人員、設計師和 PM 不必費心處理本地開發環境、傳遞螢幕截圖或參考過時的 UI。
「為每個 Pull Request 部署 Storybook 使視覺化審閱更容易，並幫助產品負責人以元件的角度思考。」—— Norbert de Langen，Storybook 核心維護者
發佈 Storybook
我們將使用 Chromatic 示範視覺化審閱工作流程，Chromatic 是 Storybook 維護者提供的免費發佈服務。 這讓您可以在雲端安全地部署和託管您的 Storybook，但將 Storybook 建置為靜態網站並部署到其他託管服務也非常簡單。
取得 Chromatic
首先，前往 chromatic.com 並使用您的 GitHub 帳戶註冊。
從那裡，選擇您的設計系統 repo。 在幕後，這將同步存取權限並檢測 PR 檢查。
透過 npm 安裝 chromatic 套件。
yarn add --dev chromatic
安裝完成後，執行以下命令來建置和部署您的 Storybook（您需要使用 Chromatic 在網站上提供的 project-token）
npx chromatic --project-token=<project-token>
透過複製提供的連結並將其貼到新的瀏覽器視窗中，瀏覽您發佈的 Storybook。 您會發現您的本機 Storybook 開發環境已在線上鏡像。
這讓您的團隊可以輕鬆地審閱真實呈現的 UI 元件，就像您在本地看到它們一樣。 這是在 Chromatic 中您會看到的確認訊息。
恭喜！ 既然您已設定發佈 Storybook 的基礎架構，讓我們透過持續整合來改進它。
持續整合
持續整合是維護現代 Web 應用程式的預設方式。 它允許您在每次推送程式碼時編寫測試、分析和部署等行為的腳本。 我們將借用此技術來將自己從重複的手動工作中解放出來。
我們將使用 GitHub Actions，它對我們適度的使用是免費的。 相同的原則也適用於其他 CI 服務。
在頂層新增一個 .github 目錄。 然後建立另一個名為 workflows 的目錄。
建立一個名為 chromatic.yml 的檔案，如下所示。 它將允許我們編寫我們的 CI 流程如何運作的腳本。 我們現在從小處著手，並隨著我們的進展繼續改進它
# Name of our action
name: 'Chromatic'
# The event that will trigger the action
on: push
# What the action will do
jobs:
test:
# The operating system it will run on
runs-on: ubuntu-latest
# The list of steps that the action will go through
steps:
- uses: actions/checkout@v2
with:
#👇 Fetches all history so Chromatic can compare against previous builds
fetch-depth: 0
- uses: actions/setup-node@v3
with:
#👇 Sets the version of Node.js to use
node-version: 16
- run: yarn
#👇 Adds Chromatic as a step in the workflow
- uses: chromaui/action@v1
# Options required for Chromatic's GitHub Action
with:
#👇 Chromatic projectToken, see https://storybook.dev.org.tw/tutorials/design-systems-for-developers/react/en/review/ to obtain it
projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
token: ${{ secrets.GITHUB_TOKEN }}
💡 為了簡潔起見，沒有提及 GitHub secrets。 Secrets 是 GitHub 提供的安全環境變數，因此您不需要硬式編碼 project-token。
使用以下命令新增變更
git add .
提交它
git commit -m "Storybook deployment with GitHub action"
最後，使用以下命令將其推送到遠端儲存庫
git push origin main
成功！ 我們改進了我們的基礎架構。
向您的團隊請求視覺化審閱
每當 Pull Request 包含 UI 變更時，與利害關係人啟動視覺化審閱流程以就將發布給使用者的內容達成共識會很有用。 這樣一來，就不會有不必要的意外或代價高昂的返工。
我們將透過在新分支上進行 UI 變更來示範視覺化審閱。
git checkout -b improve-button
首先，調整 Button 元件。 「讓它更突出」——我們的設計師會喜歡的。
// ...
const StyledButton = styled.button`
border: 10px solid red;
font-size: 20px;
`;
// ...
提交變更並將其推送到您的 GitHub 儲存庫。
git commit -am "make Button pop"
git push -u origin improve-button
導覽至 GitHub.com 並為 improve-button 分支開啟 Pull Request。 開啟後，發佈 Storybook 的 CI 工作將會執行。
在頁面底部的 PR 檢查清單中，按一下「Storybook 發佈」以檢視已發佈的包含新變更的 Storybook。
對於每個已變更的元件和 story，從瀏覽器網址列複製 URL，並將其貼到您的團隊管理任務的任何位置（GitHub、Asana、Jira 等），以幫助隊友快速審閱相關的 story。
將問題分配給您的隊友，並觀察回饋湧入。
在軟體開發中，大多數缺陷源於溝通不良而不是技術。 視覺化審閱有助於團隊在開發期間收集持續的回饋，以更快地發布設計系統。
「為每個 Pull Request 部署 Storybook 一直是我們在 Shopify 的設計系統 Polaris 中一直在做的事情，而且它非常有用。」Ben Scott，Shopify 工程師
測試您的設計系統
視覺化審閱非常寶貴；但是，手動審閱數百個元件 story 可能需要數小時。 理想情況下，我們希望僅看到有意的變更（新增/改進），並自動捕捉到意外的回歸。
在第 5 章中，我們將介紹在視覺化審閱期間減少雜訊並確保我們的元件隨著時間推移保持耐用性的測試策略。