架構的合規性

JavaScript 架構生態系統的一致性

Shubhie Panicker
Shubhie Panicker

簡介網誌文章中,我們探討了我們如何學到了許多寶貴的經驗,同時說明如何建構及使用架構和工具,來開發及維護 Google 搜尋、Google 地圖和 Google 相簿等大規模網頁應用程式。事實證明,防止開發人員編寫可能對使用者體驗造成負面影響的程式碼,證明架構在效能與應用程式品質的轉變結果中扮演了關鍵角色。

Google 內部使用「一致性」一詞來描述這種方法,本文則介紹我們計劃如何將此概念推廣到 JavaScript 架構生態系統。

什麼是「一致性」?

Google 的合規性是一項革命。團隊只仰賴少數經驗豐富的維護人員,他們進行大量程式碼審查,找出影響應用程式品質和維護能力的問題,而非修正正確性問題。為擴大這個規模,讓應用程式開發人員團隊能夠繼續合作,我們開發了一致性系統,以自動化且可強制執行的方式編纂最佳做法。無論程式碼貢獻者的數量為何,這個做法可確保應用程式品質和程式碼集可維護性維持高標準。

一致性是一種系統,可確保開發人員走在光線充足的道路上;這個系統有助於建立信心,確保結果可預測。這不僅有助團隊提升工作效率,也為資源調度技術至關重要,因為團隊會同時開發更多功能,並開發更多功能。這讓開發人員能專注於建構產品功能,使其不受效能、無障礙功能、安全性等各種領域持續變化的環境影響。任何人都能隨時選擇停止採用一致性功能,此外,團隊也能依據自身決定採用的任何設定來自訂彈性。

一致性是以強式預設值為基礎,提供可在授權時間強制執行的可採取行動規則。此舉可分為以下 3 項原則。

1. 強而有力的預設設定

確保開發人員使用的工具具備強大的預設值,是法規遵循的基礎方面。這意味著解決方案不僅可內建於架構中,架構設計模式也能使您能輕鬆執行正確的作業,而且難以遵循反模式。這個架構支援開發人員應用程式設計和程式碼結構。

為載入效能,每項資源 (字型、CSS、JavaScript、圖片等) 都經過最佳化處理。這是一項複雜的挑戰,包含修剪位元組、減少來回行程,以及區分首次轉譯、視覺化完備性和使用者互動所需的內容。例如擷取重要的 CSS,以及為重要圖片設定優先順序。

2. 可採取行動的規則

即使已完成基礎最佳化設定,開發人員仍須做出選擇。如果需要開發人員輸入內容,可以採用以下幾種最佳化做法:

  • 這種預設設定不需開發人員輸入內容,例如內嵌重要的 CSS。
  • 開發人員必須選擇加入。例如,使用架構提供的圖片元件來尺寸及縮放圖片。
  • 開發人員必須選擇加入和自訂設定。例如標記要及早載入的重要圖片。
  • 並非是特定功能,但功能仍須開發人員決定。舉例來說,請避免使用會延遲早期轉譯的字型或同步指令碼。

這張圖表顯示開發人員自動和手動的最佳化調整

這些最佳化作業都是由開發人員決定,會對應用程式效能造成風險。隨著功能不斷新增,您的團隊也會擴大規模,即使是經驗最豐富的開發人員也無法跟上日新月異的最佳做法,也無法掌握使用者的時間最佳運用方式。為了維持一致性,適當的可行規則就跟強預設值一樣重要,可確保應用程式即使在開發人員持續進行變更的情況下,仍會符合特定標準。

3. 編寫時間

請務必在開發生命週期的早期發現並排除效能問題。在所有程式碼提交前的編寫時間非常適合掌握及解決問題。較新的問題會在開發生命週期中抓到問題,解決的就是最難解決的問題。雖然這適用於正確性問題,但對於效能問題也是如此,因為多數問題在提交程式碼集後,無法回溯解決。

目前,大多數效能意見回饋都是透過說明文件或一次性稽核提供,或是延遲到實際工作環境後,才透過指標迴歸呈現。我們想把這個做法帶到編寫時間

架構中的一致性

為了維持高使用者體驗的載入效能,您需要回答下列問題:

  1. 構成最佳載入的因素為何?哪些常見問題可能對此造成負面影響?
  2. 哪些解決方案不需開發人員輸入內容即可製作?
  3. 我們如何確保開發人員能夠妥善運用這些解決方案,並以最佳方式運用?
  4. 開發人員還可以採用哪些其他做法,影響載入效能?
  5. 可以透過哪些程式碼模式,在授權前提早告知這些選項 (上述 #3 和 #4)?
  6. 我們能製定哪些規則來評估這些程式碼模式?要如何在編寫期間向開發人員顯示這些套件,同時完美整合至工作流程?

為了讓 Google 內部人員採用開放原始碼架構,我們的團隊已在 Next.js 中大量實驗,並分享我們的修正願景和計畫。我們已瞭解到,最適合評估程式碼模式的規則必須結合靜態程式碼分析動態檢查。這些規則可橫跨多個介面,包括:

  • ESLint
  • TypeScript
  • 使用者開發伺服器中的動態檢查 (在 DOM 建立後)
  • 模組套件工具 (webpack)
  • CSS 工具 (仍為探索性)

透過透過不同工具提供規則,我們可以確保規則相互連貫,但也包含任何直接影響載入效能的使用者體驗問題。此外,這些規則也可能會在不同的時間點向開發人員顯示:

  • 在開發伺服器執行本機開發作業期間,瀏覽器和使用者 IDE 會顯示警告,提示開發人員稍微變更程式碼。
  • 建構期間,未解決的問題會重新顯示在使用者的終端機中

簡單來說,團隊會選擇自己重視的結果 (例如網站體驗核心指標或載入效能),並為所有程式碼貢獻者啟用相關規則集。

雖然新專案非常適合使用這個方法,但要配合完整規則集升級大型程式碼集並不容易。Google 有大量的停用系統,可在不同層級選擇停用,例如個別的原始碼、整個目錄、舊版程式碼集或不在開發中的部分應用程式。我們正積極探索有效的策略,讓採用開放原始碼架構的團隊能使用這項功能。

Next.js 中的符合性

ESLint 廣受 JavaScript 開發人員廣泛使用,且超過 50% 的 Next.js 應用程式都使用 ESLint 在建構工作流程的某些部分。Next.js v11 推出了現成的 ESLint 支援功能,包含自訂外掛程式可共用的設定,方便您在開發和建構期間找出常見的架構特定問題。這可協助開發人員在授權時修正重大問題。例如,使用或未使用特定元件時,可能造成效能下降,如「沒有網頁的 HTML 連結」所述。或者,特定字型、樣式表或指令碼可能會對網頁的資源載入造成負面影響。例如「沒有同步指令碼」

除了 ESLint,自 v9 與 TypeScript 支援起,Next.js 也支援在開發和實際工作環境中使用整合類型檢查功能。架構提供的多個元件 (圖片、指令碼、連結) 已建構為 HTML 元素 (<img><script><a>) 的擴充功能,讓開發人員能夠有效將內容加入網頁。類型檢查可確保指派的屬性和選項在支援的值和類型的接受範圍內,支援這些功能的適當使用方式。如需相關範例,請參閱「所需的圖片寬度和高度」一節。

使用浮動式訊息和疊加層時出現的錯誤

如前所述,合規性規則可以出現在多個領域。我們正在探索浮動式訊息和疊加層,目標是直接在使用者的本機開發環境中,在瀏覽器中顯示錯誤。

浮動式訊息顯示的錯誤

開發人員依賴的錯誤檢查和稽核工具 (Lighthouse、Chrome 開發人員工具問題分頁) 都是被動執行的,需要透過某種形式的使用者互動才能擷取資訊。如果現有工具直接顯示錯誤,開發人員就更可能採取行動,提供具體且應採取的修正問題行動。

其他架構中的一致性

我們先在 Next.js 中探討符合性,目標為擴展至其他架構 (Nuxt、Angular 等)。許多架構都已採用 ESLint 和 TypeScript,但目前仍在積極探索一個結合瀏覽器層級執行階段系統的概念。

結論

一致性將最佳做法編入規則集,這些規則集可做為簡單的程式碼模式,方便開發人員採取行動。Aurora 團隊專注於載入效能,但對於無障礙和安全性等其他最佳做法也同樣適用。

遵循一致性規則應能夠產生可預測的結果,而實現使用者體驗的高標準可能是在技術堆疊上建構的副作用。只要一致,即使團隊和程式碼集會隨時間成長,團隊也能提高效率,並確保應用程式擁有優質標準。