JavaScript 架構生態系統的一致性
在簡介網誌文章中，我們探討了我們如何學到了許多寶貴的經驗，同時說明如何建構及使用架構和工具，來開發及維護 Google 搜尋、Google 地圖和 Google 相簿等大規模網頁應用程式。事實證明，防止開發人員編寫可能對使用者體驗造成負面影響的程式碼，證明架構在效能與應用程式品質的轉變結果中扮演了關鍵角色。
Google 內部使用「一致性」一詞來描述這種方法，本文則介紹我們計劃如何將此概念推廣到 JavaScript 架構生態系統。
什麼是「一致性」？
Google 的合規性是一項革命。團隊只仰賴少數經驗豐富的維護人員，他們進行大量程式碼審查，找出影響應用程式品質和維護能力的問題，而非修正正確性問題。為擴大這個規模，讓應用程式開發人員團隊能夠繼續合作，我們開發了一致性系統，以自動化且可強制執行的方式編纂最佳做法。無論程式碼貢獻者的數量為何，這個做法可確保應用程式品質和程式碼集可維護性維持高標準。
一致性是一種系統，可確保開發人員走在光線充足的道路上；這個系統有助於建立信心，確保結果可預測。這不僅有助團隊提升工作效率，也為資源調度技術至關重要，因為團隊會同時開發更多功能，並開發更多功能。這讓開發人員能專注於建構產品功能，使其不受效能、無障礙功能、安全性等各種領域持續變化的環境影響。任何人都能隨時選擇停止採用一致性功能，此外，團隊也能依據自身決定採用的任何設定來自訂彈性。
一致性是以強式預設值為基礎，提供可在授權時間強制執行的可採取行動規則。此舉可分為以下 3 項原則。
1. 強而有力的預設設定
確保開發人員使用的工具具備強大的預設值，是法規遵循的基礎方面。這意味著解決方案不僅可內建於架構中，架構設計模式也能使您能輕鬆執行正確的作業，而且難以遵循反模式。這個架構支援開發人員應用程式設計和程式碼結構。
為載入效能，每項資源 (字型、CSS、JavaScript、圖片等) 都經過最佳化處理。這是一項複雜的挑戰，包含修剪位元組、減少來回行程，以及區分首次轉譯、視覺化完備性和使用者互動所需的內容。例如擷取重要的 CSS，以及為重要圖片設定優先順序。
2. 可採取行動的規則
即使已完成基礎最佳化設定，開發人員仍須做出選擇。如果需要開發人員輸入內容，可以採用以下幾種最佳化做法：
- 這種預設設定不需開發人員輸入內容，例如內嵌重要的 CSS。
- 開發人員必須選擇加入。例如，使用架構提供的圖片元件來尺寸及縮放圖片。
- 開發人員必須選擇加入和自訂設定。例如標記要及早載入的重要圖片。
- 並非是特定功能，但功能仍須開發人員決定。舉例來說，請避免使用會延遲早期轉譯的字型或同步指令碼。
這些最佳化作業都是由開發人員決定，會對應用程式效能造成風險。隨著功能不斷新增，您的團隊也會擴大規模，即使是經驗最豐富的開發人員也無法跟上日新月異的最佳做法，也無法掌握使用者的時間最佳運用方式。為了維持一致性，適當的可行規則就跟強預設值一樣重要，可確保應用程式即使在開發人員持續進行變更的情況下，仍會符合特定標準。
3. 編寫時間
請務必在開發生命週期的早期發現並排除效能問題。在所有程式碼提交前的編寫時間非常適合掌握及解決問題。較新的問題會在開發生命週期中抓到問題，解決的就是最難解決的問題。雖然這適用於正確性問題，但對於效能問題也是如此，因為多數問題在提交程式碼集後，無法回溯解決。
目前，大多數效能意見回饋都是透過說明文件或一次性稽核提供，或是延遲到實際工作環境後，才透過指標迴歸呈現。我們想把這個做法帶到編寫時間
架構中的一致性
為了維持高使用者體驗的載入效能，您需要回答下列問題：
- 構成最佳載入的因素為何？哪些常見問題可能對此造成負面影響？
- 哪些解決方案不需開發人員輸入內容即可製作？
- 我們如何確保開發人員能夠妥善運用這些解決方案，並以最佳方式運用？
- 開發人員還可以採用哪些其他做法，影響載入效能？
- 可以透過哪些程式碼模式，在授權前提早告知這些選項 (上述 #3 和 #4)？
- 我們能製定哪些規則來評估這些程式碼模式？要如何在編寫期間向開發人員顯示這些套件，同時完美整合至工作流程？
為了讓 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 團隊專注於載入效能，但對於無障礙和安全性等其他最佳做法也同樣適用。
遵循一致性規則應能夠產生可預測的結果，而實現使用者體驗的高標準可能是在技術堆疊上建構的副作用。只要一致，即使團隊和程式碼集會隨時間成長，團隊也能提高效率，並確保應用程式擁有優質標準。