Critique：Google 的程式碼審查工具#

如同第 9 章所述，程式碼審查（code review）是軟體開發的關鍵環節，尤其在大規模環境下更是如此。程式碼審查的核心目標是提升程式碼庫的可讀性與可維護性，而擁有定義完善的程式碼審查流程只是故事的一部分——支撐該流程的工具同樣在其成功中扮演重要角色。

本章介紹 Google 內部廣受歡迎的程式碼審查系統 Critique。Critique 明確支援程式碼審查的主要動機：

• 為審查者與作者提供檢視變更和評論的介面
• 作為程式碼提交至程式碼庫的把關機制（透過「評分」變更的機制）
• 在「程式碼考古」（code archaeology）中提供有價值的技術決策追蹤資訊——例如當行內註解不足時，可回溯審查互動中的技術討論

雖然 Critique 並非 Google 唯一使用的程式碼審查工具，但它是最廣泛使用的。

程式碼審查工具的設計原則#

Critique 的成功源於 Google 的開發文化——程式碼審查是工作流的核心部分。這些文化影響轉化為 Critique 設計時著重的一組指導原則：

• 簡潔性（Simplicity）：Critique 的使用者介面設計以輕鬆完成程式碼審查為目標，避免不必要的選項。UI 載入快速、導航簡便並支援快捷鍵，且有清楚的視覺標記顯示變更是否已被審查。在所有原則中，簡潔性對工具的影響最為深遠——許多有趣的功能最終因僅服務少數使用者而被捨棄。

• 信任基礎（Foundation of Trust）：程式碼審查的目的不是拖慢他人的進度，而是賦能他人。盡可能信任同事是讓流程運作的關鍵。例如，信任作者會確實進行修改，不要求額外的覆審階段來再次檢查細微評論是否被處理。信任也體現在讓所有變更在 Google 內部公開可見（可供檢視與審查）。

• 通用溝通（Generic Communication）：溝通問題很少能透過工具解決。Critique 優先提供通用的評論方式，而非複雜的協議。Critique 鼓勵使用者在評論中清楚表達他們想要的東西，甚至建議修改，而非讓資料模型和流程更加複雜。即使有最好的程式碼審查工具，溝通仍可能出錯，因為使用者是人。

• 工作流整合（Workflow Integration）：Critique 與其他核心軟體開發工具有多個整合點。開發者可輕鬆跳轉到程式碼搜尋與瀏覽工具檢視正在審查的程式碼、在網頁版程式碼編輯工具中編輯程式碼，或查看與變更相關的測試結果。

簡潔性與工作流整合之間存在有趣的張力。Critique 團隊曾考慮建立一個「Code Central」工具，將程式碼編輯、審查和搜尋整合於一體，但最終決定讓程式碼審查保持為主要焦點。功能從 Critique 連結出去，但在不同子系統中實作。

程式碼審查流程#

程式碼審查可在軟體開發的多個階段進行。Critique 的審查通常發生在變更提交到程式碼庫之前，即所謂的 precommit review（提交前審查）。以下是完整的審查流程圖：

典型的審查步驟如下：

1. 建立變更（Create a Change）：使用者在工作區撰寫對程式碼庫的變更，然後上傳一個快照（snapshot，代表某個時間點的 patch）到 Critique，觸發自動化程式碼分析器執行（參見第 20 章）。

2. 請求審查（Request Review）：作者對 Critique 中顯示的變更差異（diff）和分析器結果滿意後，將變更寄送（mail）給一或多位審查者。

3. 評論（Comment）：審查者在 Critique 中開啟變更並在 diff 上草擬評論。評論預設標記為 unresolved（未解決），代表作者必須處理。審查者也可以添加 resolved（已解決）的選擇性或資訊性評論。自動程式碼分析器的結果（如有）也會顯示給審查者。審查者草擬完一組評論後，需要「發佈」（publish）才能讓作者看到——這讓審查者能在檢閱完整個變更後，一次性地提供完整的想法。任何人都可以對變更發表評論，進行所謂的「路過審查」（drive-by review）。

4. 修改變更並回覆評論（Modify Change and Reply）：作者根據回饋修改變更、上傳基於回饋的新快照，並回覆審查者。作者（至少）處理所有未解決的評論——透過修改程式碼或回覆評論並將其類型改為已解決。作者和審查者可以查看任意兩個快照之間的差異，了解變化。步驟 3 和 4 可能反覆進行多次。

5. 變更核准（Change Approval）：當審查者對變更的最新狀態感到滿意時，他們核准變更並標記為「LGTM」（Looks Good To Me）。審查者可選擇性地附帶需要處理的評論。變更被認為適合提交後，在 UI 中會以綠色清楚標示這個狀態。

6. 提交變更（Commit a Change）：在變更獲得核准後，作者可觸發提交流程。若自動分析器和其他 precommit hook（稱為「presubmit」）未發現問題，變更即提交至程式碼庫。

即使審查流程已開始，整個系統仍提供相當大的彈性來偏離常規流程。審查者可取消指派自己或明確轉交給他人，作者可完全延後審查。在緊急情況下，作者可強制提交變更，事後再進行審查。

通知機制#

隨著變更推進各階段，Critique 發佈事件通知供其他支援工具使用。這種通知模型讓 Critique 能專注於作為主要的程式碼審查工具，而非通用工具，同時仍整合在開發者的工作流中。通知實現了關注點分離——Critique 只負責發出事件，其他系統基於這些事件構建。

具體的通知管道包括：

• Chrome 擴充功能：使用者可安裝一個 Chrome 擴充功能來消費事件通知。當變更需要使用者關注時（例如輪到他們審查或某個 presubmit 失敗），擴充功能顯示瀏覽器通知，附帶直接前往變更或靜音通知的按鈕。部分開發者偏好即時通知，但有些人選擇不使用，因為覺得太過干擾工作節奏。

• 電子郵件通知：Critique 管理與變更相關的 email——重要事件觸發 email 通知。除了在 Critique UI 中顯示外，部分分析器的發現也透過 email 發送。Critique 也能處理 email 回覆並轉為評論，支援偏好 email 流程的使用者。

• 儀表板（Dashboard）：對許多使用者而言，email 並非程式碼審查的關鍵功能——他們主要使用 Critique 的儀表板檢視（稍後討論）來管理審查。

階段 1：建立變更#

程式碼審查工具應在審查流程的各階段提供支援，且不應成為提交變更的瓶頸。在審查前的步驟中，讓變更作者更容易在送審前打磨變更，有助於減少審查者檢視變更所需的時間。

Critique 顯示變更差異，並提供忽略空白字元變更和突顯「僅搬移」變更的選項。Critique 也呈現建置、測試和靜態分析器的結果，包括風格檢查（如第 9 章所述）。

向作者顯示變更的 diff 讓他們有機會換一頂帽子——程式碼審查者的帽子。Critique 讓變更作者以審查者的視角看到自己的變更 diff，同時也看到自動分析結果。Critique 也支援在審查工具內對變更進行輕量修改，並建議適當的審查者。送出請求時，作者還可以附上初步的評論，直接向審查者提出開放性問題。讓作者看到審查者所見的內容，可避免誤解。

作者也可以將變更連結到特定的 bug，以提供更多脈絡給審查者。Critique 使用自動完成服務顯示相關的 bug，優先顯示指派給作者的 bug。

差異檢視（Diffing）#

理解程式碼變更本身是審查流程的核心。較大的變更通常比較小的更難理解，因此最佳化變更的 diff 是好的程式碼審查工具的核心需求。

在 Critique 中，這項原則體現在多個層次。差異元件基於最佳化的最長公共子序列（Longest Common Subsequence）演算法，並增強了以下功能：

• 語法高亮（Syntax highlighting）
• 交叉引用（Cross-references），由 Kythe 驅動（參見第 17 章）
• 行內差異（Intraline diffing），以字元級別顯示差異並考慮字詞邊界
• 空白字元忽略選項，可設定不同程度
• 搬移偵測（Move detection），標示從一處搬到另一處的程式碼區塊，而非天真地顯示為「此處刪除、彼處新增」

使用者可選擇不同的 diff 模式，如疊加（overlay）和並排（side-by-side）。在開發 Critique 時，團隊認為並排 diff 對審查流程至關重要。並排 diff 需要大量空間：為了實現它，團隊必須簡化 diff 檢視結構——無邊框、無內距，只有 diff 和行號。團隊也嘗試了多種字型和大小，直到找到一個在 Critique 推出時的典型螢幕寬度解析度（1,440 像素）下，即使是 Java 100 字元行限制也能容納的 diff 檢視。

Critique 也支援各種自訂工具來提供變更產出物的 diff，例如變更所修改的 UI 的截圖比對，或變更所產生的設定檔差異。

為了讓瀏覽 diff 的過程順暢，團隊注意不浪費空間，並投入大量心力確保 diff 快速載入——即使是圖片、大型檔案或大型變更也是如此。團隊也提供快捷鍵在檔案間快速導航，且僅訪問修改過的區段。

當使用者深入到檔案層級，Critique 提供一個精簡的 UI 小工具來顯示檔案的快照版本鏈；使用者可拖放選取要比較的版本。此小工具會自動收合相似的快照，聚焦重要版本。它幫助使用者理解檔案在變更中的演化過程——例如哪些快照有測試覆蓋率、已被審查，或有評論。為了應對規模問題，Critique 會預先載入所有內容，因此切換不同快照非常快速。

分析結果#

上傳變更快照會觸發程式碼分析器（參見第 20 章）。Critique 在變更頁面上顯示分析結果，以分析器狀態標籤（chip）的形式摘要在變更描述下方，並在 Analysis 分頁中顯示詳細資訊。

分析結果的顯示邏輯如下：

• 分析器可將特定發現標記為 紅色 以提高可見度
• 仍在執行中的分析器以 黃色 標籤表示，其他則為 灰色
• 為了簡潔性，Critique 不提供其他標記或突顯發現的選項——可處理性是一個二元選項
• 如果分析器產出結果（「findings」），點擊標籤可展開發現內容
• 發現可像評論一樣顯示在 diff 中，但以不同樣式呈現以便區分
• 部分發現包含修正建議，作者可從 Critique 中預覽並選擇套用

以 linter 發現行尾多餘空格為例：變更頁面會顯示該 linter 的標籤。作者可從標籤快速導航到顯示違規程式碼的 diff（只需兩次點擊）。大多數 linter 違規還附帶修正建議。再一次點擊，作者可預覽修正建議（例如移除多餘空格），再一次點擊即可在變更上套用修正。

緊密的工具整合#

Google 在其單體原始碼倉庫 Piper（參見第 16 章）之上建構了多種工具：

• Cider：用於編輯儲存在雲端的原始碼的線上 IDE
• Code Search：用於在程式碼庫中搜尋程式碼的工具
• Tricorder：用於顯示靜態分析結果的工具（前面提到過）
• Rapid：打包和部署包含一系列變更的二進位檔的發布工具
• Zapfhahn：測試覆蓋率計算工具

此外，還有提供變更元資料脈絡的服務（例如關於變更中涉及的使用者或關聯的 bug）。Critique 是這些系統的自然匯流點，提供快速的一鍵/懸停存取或甚至嵌入式 UI 支援，但團隊需要謹慎避免犧牲簡潔性。

例如，從 Critique 的變更頁面只需一次點擊即可在 Cider 中繼續編輯變更。使用者可透過 Kythe 在交叉引用之間導航，或在 Code Search 中檢視程式碼的主線狀態（參見第 17 章）。Critique 也連結到發布工具，讓使用者可以查看已提交的變更是否在特定版本中。

對於這些工具，Critique 偏好連結而非嵌入，以避免分散核心審查體驗的注意力。唯一的例外是測試覆蓋率：某行程式碼是否被測試覆蓋的資訊，會以不同背景色顯示在檔案 diff 檢視的行號區域（並非所有專案都使用此覆蓋率工具）。

Critique 與開發者工作區之間的緊密整合之所以可能，是因為工作區儲存在基於 FUSE 的檔案系統中，可在個別開發者的電腦之外存取。真實來源（Source of Truth）託管在雲端，所有工具都可存取。

階段 2：請求審查#

當作者對變更狀態滿意後，即可發送審查請求。這需要作者選擇審查者。

在小型團隊中，找到審查者看似簡單，但即使如此，將審查均勻分配給團隊成員並考慮誰在休假等情境仍很重要。為此，團隊可提供一個 email 別名用於接收程式碼審查。這個別名由 GwsQ 工具使用（得名於最初使用此技術的團隊：Google Web Server），根據連結到別名的設定指派特定的審查者。例如，變更作者可將審查指派給 some-team-list-alias，而 GwsQ 會從該別名中挑選一位特定成員來執行審查。

鑒於 Google 程式碼庫的規模和修改它的人數，要找出在自己專案之外最有資格審查某個變更的人可能相當困難。在達到一定規模時，尋找審查者是需要考慮的問題。Critique 提供建議一組足以核准變更的審查者的功能，其審查者選擇工具考量以下因素：

• 誰擁有被修改的程式碼（code ownership，參見下一節）
• 誰最熟悉該程式碼（即近期修改者）
• 誰可以審查（未休假，且最好在相同時區）
• GwsQ 團隊別名設定

Presubmit Hook#

指派審查者會觸發審查請求，同時執行適用於該變更的 presubmit（預提交）hook。團隊可以多種方式設定與其專案相關的 presubmit。最常見的 hook 包括：

• 自動將 email 列表加入變更以提高意識和透明度
• 執行專案的自動化測試套件
• 對程式碼和變更描述強制執行專案特定的不變條件——對程式碼強制執行本地風格限制，對變更描述則允許生成版本說明或其他形式的追蹤

由於執行測試耗費資源，在 Google 測試被安排在 presubmit 階段（請求審查和提交變更時）執行，而非像 Tricorder 檢查那樣在每次快照上傳時執行。Critique 以類似分析器結果的方式呈現 hook 執行結果，但額外加以區分，突顯失敗的結果會阻擋變更被送審或提交。如果 presubmit 失敗，Critique 會透過 email 通知作者。

階段 3 與 4：理解與評論變更#

審查流程開始後，作者和審查者協同合作，以提交高品質的變更為目標。

評論#

評論是 Critique 中僅次於檢視變更的第二常見操作。Critique 的評論對所有人開放——不僅限於變更作者和指派的審查者——任何人都可以評論。

Critique 也提供透過個人狀態追蹤審查進度的能力。審查者可使用核取方塊將個別檔案在最新快照標記為「已審查」，幫助審查者追蹤已檢視的內容。當作者修改檔案時，所有審查者對該檔案的「已審查」核取方塊會被清除，因為最新快照已更新。

Critique 提供以下評論相關功能：

• 「請修正」（Please Fix）按鈕：當審查者看到相關的分析器發現時，可點擊此按鈕建立一個未解決的評論，要求作者處理該發現。

• 內嵌建議修改：審查者可透過內嵌編輯最新版本的檔案來建議修改。Critique 將此建議轉為附帶修正的評論，作者可直接套用。

• 快捷回覆：Critique 不規定使用者應建立什麼評論，但對於一些常見評論提供快捷方式。作者可點擊評論面板上的「Done」按鈕表示審查者的評論已被處理，或點擊「Ack」按鈕表示已閱讀（通常用於資訊性或選擇性評論）。兩者都有在評論串未解決時將其解決的效果。這些快捷方式簡化了工作流程，減少回覆審查評論所需的時間。

• 批次發佈（Atomic Publishing）：如前所述，評論在過程中逐步草擬，然後一次性「發佈」。這讓作者和審查者能在寄出前確認對評論內容感到滿意。

理解變更狀態#

Critique 提供多種機制來明確指出變更在「評論—迭代」階段的目前位置。這包括判斷下一步該由誰行動的功能，以及顯示特定開發者所涉及之所有變更的審查/作者狀態的儀表板檢視。

「輪到誰」功能（Whose Turn）#

加速審查流程的一個重要因素是理解何時輪到你行動，尤其在多位審查者被指派到一個變更的情況下。這可能發生在作者希望讓軟體工程師和負責該功能的使用者體驗人員都審查變更的情況，或是服務的 SRE on-call 人員。Critique 透過為每個變更管理一個 attention set（關注集合）來幫助定義誰被期望下一步查看變更。

Attention set 由目前阻塞變更進展的一群人組成。當審查者或作者在 attention set 中時，他們被期望及時回應。Critique 會在使用者發佈評論時智慧地更新 attention set，但使用者也可以自行管理。Attention set 在多位審查者的情況下尤其有用。在 Critique 中，attention set 中的相關使用者名稱會以粗體呈現。

實作此功能後，使用者很難想像之前沒有它的狀態。普遍的反應是：我們以前怎麼過的？在實作此功能之前的替代方案是審查者和作者之間透過聊天來了解誰在處理變更。此功能也強調了程式碼審查的回合制本質——永遠至少有一個人輪到採取行動。

儀表板與搜尋系統#

Critique 的首頁是使用者的 儀表板（Dashboard），分為使用者可自訂的區段，每個區段包含變更摘要列表。

儀表板由名為 Changelist Search 的搜尋系統驅動。Changelist Search 索引了 Google 所有使用者的所有可用變更的最新狀態（包含提交前與提交後），允許使用者透過正規表示式查詢來搜尋相關變更。每個儀表板區段由一個 Changelist Search 查詢定義。團隊投入了大量心力確保 Changelist Search 足夠快以供互動使用——所有內容都被快速索引，即使 Google 有極大量的同時進行的變更，作者和審查者也不會被拖慢。

為了最佳化使用者體驗，Critique 的預設儀表板設定是將第一個區段顯示需要使用者關注的變更（可自訂）。還有一個搜尋列用於對所有變更進行自訂查詢並瀏覽結果。

• 身為審查者，主要只需要 attention set
• 身為作者，主要需要查看仍在等待審查的變更，看是否需要催促

雖然團隊在 Critique UI 的其他部分避免了可自訂性，但團隊發現使用者喜歡以不同方式設定儀表板，而不會損害基本體驗——類似每個人整理 email 的方式不同。

負責大規模變更（LSC）的集中式「全域」審查者特別容易自訂此儀表板，以避免在 LSC 期間被淹沒（參見第 22 章）。

階段 5：變更核准（評分機制）#

判斷審查者是否認為變更良好，歸結為透過評論提供疑慮和建議。但也需要某種機制來提供對變更的高層「OK」。在 Google，變更的評分分為三個部分：

• LGTM（Looks Good To Me）：審查者的 LGTM 表示「我已審查此變更，認為它符合我們的標準，我認為在處理未解決評論後可以提交。」

• Approval（核准）：審查者的 Approval 表示「作為把關者，我允許此變更提交至程式碼庫。」

• 未解決評論數量：審查者可將評論標記為未解決，代表作者需要對其採取行動。

當變更至少有一個 LGTM、足夠的 Approval 且無未解決評論時，作者即可提交變更。每個變更都需要 LGTM（不論核准狀態），確保至少有兩雙眼睛檢視過變更。這個簡單的評分規則讓 Critique 能明確告知作者何時可以提交（以綠色頁面標頭醒目顯示）。

在建構 Critique 的過程中，團隊有意識地簡化了評等方案。最初 Critique 有「Needs More Work」評等和「LGTM++」。後來改為讓 LGTM/Approval 始終為正面評價。如果變更確實需要第二次審查，主要審查者可以加入評論但不給予 LGTM/Approval。當變更進入大致良好的狀態後，審查者通常會信任作者處理小的編輯——工具不要求不論變更大小都重複給予 LGTM。

這個評等方案也對程式碼審查文化產生了正面影響。審查者不能僅對變更「按下反對」而不提供有用的回饋——所有負面回饋必須與需要修正的具體事項關聯（例如未解決評論）。「unresolved comment」這個措辭也是刻意選擇的，聽起來相對溫和。

Critique 在分析標籤旁顯示評分面板，包含以下資訊：

• 誰已給予 LGTM
• 仍需哪些核准及原因
• 還有多少未解決評論

以這種方式呈現評分資訊，幫助作者快速理解還需要做什麼才能讓變更被提交。

LGTM 和 Approval 是硬性要求（hard requirements），只有審查者可授予，且在變更提交前隨時可撤回。未解決評論是軟性要求（soft requirements），作者可在回覆時將其標為已解決。這種區別促進並依賴作者與審查者之間的信任與溝通。

例如，審查者可在附帶未解決評論的情況下給予 LGTM，而不必事後精確檢查評論是否被確實處理——這突顯了審查者對作者的信任。這種信任在作者和審查者之間有顯著時區差異時特別重要，也是建立信任和強化團隊的好方式。

階段 6：提交變更#

最後但同樣重要的是，Critique 提供一個按鈕用於在審查完成後提交變更，避免在審查完成後需要切換到命令列介面的情境切換（context-switching）。這是整個流程中最後一個簡化步驟——讓作者在同一個工具中完成從建立到提交的完整生命週期。

提交後：追蹤歷史#

除了作為提交前審查工具的核心用途外，Critique 也被用作變更考古（change archaeology）的工具：

• 對於大多數檔案，開發者可在 Code Search 系統中查看過去修改特定檔案的變更歷史列表（參見第 17 章），或直接導航至某次變更
• Google 的任何人都可以瀏覽一般可見檔案的變更歷史，包括評論和變更的演化過程
• 這支援未來的稽核，幫助理解變更原因或 bug 的引入方式
• 開發者可學習變更的工程方法，彙總的程式碼審查資料也用於產出培訓內容
• Critique 支援在變更提交後繼續評論——例如事後發現問題或對日後調查該變更的人可能有用的額外脈絡
• Critique 也支援回滾（rollback）變更的功能，以及查看特定變更是否已被回滾

案例研究：Gerrit#

雖然 Critique 是 Google 最常用的審查工具，但並非唯一。Critique 由於與大型單體倉庫和其他內部工具的緊密相依性，無法對外提供。因此，在 Google 中從事開源專案（包括 Chrome 和 Android）或無法/不想在單體倉庫中託管的內部專案的團隊，使用不同的程式碼審查工具：Gerrit。

Gerrit 是一個獨立的、開源的程式碼審查工具，與 Git 版本控制系統緊密整合。主要特點包括：

• 提供程式碼瀏覽、分支合併、cherry-pick commit 和程式碼審查等多項 Git 功能的 Web UI
• 具有細粒度的權限模型，可限制對倉庫和分支的存取
• 與 Critique 相同，每個 commit 獨立審查；支援堆疊 commit 上傳並個別審查，也允許審查後將整個鏈原子性提交
• 作為開源工具，容納更多變體和更廣泛的使用情境；豐富的外掛系統支援與自訂環境的緊密整合
• 支援更複雜的評分系統——審查者可透過 -2 分否決變更，且評分系統高度可配置

更多關於 Gerrit 的資訊及實際運作方式，可參見 gerritcodereview.com ^↗。

結論#

使用程式碼審查工具時存在許多隱性的權衡取捨。Critique 內建了多項功能並與其他工具整合，使審查流程對使用者更加順暢。花在程式碼審查上的時間就是沒花在寫程式的時間，因此審查流程的任何最佳化都是公司生產力的提升。在大多數情況下只需兩個人（作者和審查者）對變更達成共識即可提交，這維持了高開發速度。Google 高度重視程式碼審查的教育面向，即使這些更難量化。

為了最小化變更被審查所需的時間，審查流程應無縫流動——簡潔地通知使用者需要關注的變更，並在人工審查者介入前識別潛在問題（透過分析器和持續整合）。在可能的情況下，快速的分析結果會在較長時間的分析完成前先行呈現。

Critique 在規模方面需要多方面的支援。工具必須能擴展到大量審查請求而不降低效能。由於 Critique 處於變更提交的關鍵路徑上，它必須高效載入，且能處理特殊情境如異常大型的變更。

雖然大多數變更規模不大（少於 100 行），但 Critique 有時需要審查大型重構變更，這類變更可能觸及數百甚至數千個檔案，特別是必須原子性執行的大規模變更（LSC，參見第 22 章）。

介面必須支援管理大型程式碼庫上的使用者活動（如找到相關變更），並幫助審查者和作者在程式碼庫中導航——例如幫助尋找適當的審查者，而無需自行摸清 ownership/maintainer 格局（這對大規模變更如 API 遷移特別重要，因為這類變更可能影響許多檔案）。

Critique 偏好明確的流程（opinionated process）和簡潔的介面來改善一般審查工作流。然而，Critique 也允許一定程度的自訂性：自訂分析器和 presubmit 提供變更的特定脈絡，部分團隊特定政策（如要求多位審查者的 LGTM）也可被強制執行。

信任與溝通是程式碼審查流程的核心。工具可以增強體驗，但無法取代它們。與其他工具的緊密整合也是 Critique 成功的關鍵因素。

TL;DRs#

• 信任與溝通是程式碼審查流程的核心。工具可以增強體驗，但無法取代它們。
• 緊密的工具整合是優秀程式碼審查體驗的關鍵。
• 小型工作流最佳化（如明確的「attention set」的添加）可以大幅提升清晰度並減少摩擦。