Google 的軟體工程之道 (18) — 大規模變更

Published in

JohnLiu 的軟體工程思維

Nov 26, 2023

此系列為【 Google 的軟體工程之道】一書的書摘與點評，期待用最精要的文字，帶來豐富的內容分享。預計 2~3 周左右會有一篇更新，歡迎追蹤支持!

大規模變更的定義與負責對象

一組邏輯上相關，但實際上無法做為單一原子化的變更。可能是修改的部分太多，或是變化太大會有很多 conflict 存在
常見的發生原因: 靜態分析工具的錯誤修正、廢棄函式替換、基礎架構改進、舊系統轉移
通常由基礎架構團隊處理大規模變更，由於團隊通常擁有大規模變更所需的背景知識。而這些變更的使用團隊通常具備的是領域知識，而非這些基礎面向的經驗。且在成本面上，更能集中計算並審視獲益
良好的大規模變更，可以幫助這些檔案的使用者不會被這些變更影響工作，並且能夠從完成的變更增加生產力。例如將兩個命名規則不同的檔案給一致化: stl_util.h 和 map-util.h

技術限制，包括數千上萬檔案處理的記憶體和運算能力限制，尤其在版本控制系統做檢查時
合併衝突的可能性和規模性巨大
對於一些古老、複雜且緩慢的系統，這些異動都可能造成商業損失
不同的專案或模塊，為了整合 CI，通常都有特化且複雜的程式碼檢查行為，而大規模變更可能會因為這些行爲，增加不必要且無關聯的複雜性。可以適時和負責團隊討論是否關閉。
原則上，每個變更都應該測試，而大型變更非常難以測試。不只是需測試的範圍更廣泛，而且更可能增加與修改本身原意無關的錯誤的發生可能性。且在失敗 root cause 的尋找上，具有更多的成本。
Code Review 很乏味且繁重，尤其在這些變更大部分是靠手動修改方式產生時。
程式語言的設計本身也有影響，通則來說，靜態語言比動態語言更容易執行大規模修改。由於動態語言針對提升開發者生產力為核心的設計，可能會較難做維護。

組織需具備高度開放性的工程文化，讓所有工程師能編輯所有檔案，並且領域團隊能信任基礎設施團隊做出的大規模變更 ; 基礎設施團隊也能提供足夠 FAQ 或歷史紀錄供檢視。
透過如 Kythe 的工具來建構對程式碼的洞察力，包括對於程式碼抽象語義樹的分析，或是找出函式的 caller 或繼承特定 class 的其他子 classes。這個工具的支援也應是全面性能涵蓋所有的程式碼庫。

kythe.io

3. 透過如 Rosie 的變更管理工具，能夠把大型變更切割成較小的子集，並做獨立測試、review 和 commit。

4. 自動格式化工具，讓大規模變更不需要關注在格式化的部分，可以預設所有的程式碼已是格式化的版本。

5. 透過 TAP ( Test Automation Platform) ，降低大規模變更所需的測試成本，尤其在自動化單元測試覆蓋率不足的情況下，建構相關測試平台或策略具有很重要的效益。

授權，通常變更的作者必須說明變更的原因、對程式碼的影響並回答審查員提出的問題。審查員的本質通常不是阻擋變更的發生，主要是對於工作給出回饋，並進行適量的監督
建立變更，盡量利用自動化的方式，產生變更，並且能基於團隊的 coding style guides 或其他自動格式化工具
透過 Roise 來做出切割，並自動化執行相關工作。針對這些工作，應是以牛而不是寵物的態度對待。部分工作被拒絕或是出現問題是很正常的
透過 TAP 進行大量測試，脆弱的測試在此等規模的情況下，對大規模變更的團隊會是要解決的問題
要求 review，將自動化檢核通過的變更，讓相關的 code owner 做 review。如果沒有即時回覆，則即時尋找下一位 reviewer 來避免阻礙整體推送過程
review 時，設計一些工具讓 reviewer 可以全域做出 approval，而不是按照不同區域做 approval。且針對部分失敗之處，仍能手動提出回饋
提交，並確保能通過 precommit 的檢查
清理，確保一開始大規模遷移所定義的完成標準，能被確實執行完畢

如果喜歡這個系列的話，歡迎將此連結加入你的最愛: