有別於 灣區實習篇｜開始 Google 實習旅程 以 week-by-week 的方式記錄實習過程，這篇我想換個角度來寫。文章會先介紹 Google 的 code review 流程，再透過我親身收到 feedback 的案例，延伸到對文化層面（culture aspect）的體會，最後再談談這段過程帶給我的個人反思，以及它如何與 Google 的文化相互呼應。
讀完這篇文章後，也很歡迎你分享你所在公司的文化或自己的觀察。以我的工作經驗來看，除了職涯成長，探索不同公司的文化真的是一個很有趣的主題。
另外也想幫自己打個小廣告 😆 —— Lena in Seattle 最近推出了線上「讀者 Coffee Chat – 與作者一對一交流時間」。如果你有興趣，歡迎點擊 商品連結 參考。那我們就開始吧！
在 Google 的 Code Review 流程
在大部分團隊協作環境裡，大家習慣使用 Git 進行版本控制。工程師會先在自己的 branch 開發新功能，完成後再透過 Pull Request（PR）提交，讓其他人檢視修改內容。當 Reviewer 核准後，這些更動就能合併到 main 或 develop branch。
在 Google，流程則稍有不同。工程師會將修改提交成一個 CL（Change List）。每個 CL 的改動範圍可以由開發者決定，但通常建議 改動越小越好，因為小型 CL 比較容易被 reviewer 理解，也方便後續併入 project code base。以實習生的 project 來說，CL 一般會先和 host 或協作的工程師討論改動範圍，他們通常也是這份 CL 的 reviewer。當 CL 準備好後，reviewer 會針對修改留下 comment，而提交 CL 的工程師就需要根據這些 feedback 進行討論與改進。
等到 reviewer 認可修改後，就會給予 approval。但這還不夠，CL 還需要獲得 project owner 的批准。這些 project owners 可能是 host、team manager，或其他跨組的工程師。以我第一個專案為例，project owners 其實是別組的工程師，這就意味著 review 過程會更長，因為需要跨組溝通與確認。相較之下，取得 host 的批准容易得多；但若涉及 cross-team project，可能會改動到別組維護的 code，就更考驗工程師的合作與溝通能力。
能跑的程式 ≠ 好的程式
在 Google，軟體工程師除了負責自己被分配的功能開發，code review 其他工程師的程式碼也是每個人共同的責任。這不只是找錯，而是確保設計正確、程式碼可維護，並且能長期被團隊使用。
我印象最深的一次 code review，就是在我第一個 project 開發對話窗 component 的時候。當時我寫出的 implementation 可以正常運作，但 reviewer 在 CL 提出：
我一開始的設計沒有做到良好的解耦，反而依賴了錯誤的 dependency injection 來偵測 state change，這樣的做法雖然能 work，卻限制了元件的可重用性。
老實說，當下我很掙扎。我其實很希望 host 能不同意這個意見，因為 timeline 上我即將要開始第二個 project（預計一到兩週內要交 design doc），如果要大改，至少得再花上一週才能完成修改。結果負責 data model 的工程師也認同 reviewer 的看法 → 跟 host 討論後 → host 也同意 → 最後只好接受，並大幅度調整原本的設計。
現在回頭看，這其實是一次很寶貴的學習。它讓我體會到，寫程式並不是「能跑就好」。真正好的程式碼，需要考慮到未來是否容易擴展、能否被復用、是否方便維護。這次經驗教會我，把「workable solution」提升到「maintainable solution」，才能確保程式碼能被長久使用，並在未來持續迭代。
Google collective improvement 文化
在 Google，我很深刻地感受到，給與收 feedback 本身就是 Software Engineer 工作的重要一環。在實習過程中，我逐漸體會到這種 feedback 文化有幾個特色：
- Concrete & Actionable：
Feedback 通常都非常具體，不會只是「這樣不好」，而是清楚指出問題原因，例如「耦合度太高，未來不好維護」，並帶有可行的改善方向 - Hierarchy 不是阻力：
就算是實習生，工程師們也會認真審視我的 code - Collaboration 背後的價值觀：
相較於「快點做完」，Google 更重視「正確性、可擴展性，以及能被團隊長期共用的程式碼」
透過 feedback 建立共識，對我來說是職涯進步的重要養分。這樣的文化鼓勵 engineer 開放討論，就像在學校時，和學霸同學一起討論題目最佳解法一樣—不是比誰厲害，而是一起推導更好的 solution。
Pause a little bit...
最近我讀了一本關於軟體工程師職涯發展的書，其中在談到科技公司的類型時，提及了 Big Tech Companies 和 Consulting Agency 的特性。我之所以對「從 workable solution 提升到 maintainable solution」這件事特別有感，是因為我大學畢業後轉職成軟體工程師的第一份工作，就是在一家 Consulting Agency（俗稱「外包公司」）擔任前端工程師。
Consulting Agency 常見的特性是：開發強調速度，而不是品質。因為客戶往往基於壓低成本的考量來決定開發週期與最終交付成果，工程師就傾向「能跑就好」，至於長期的可維護性或複用性，通常不是首要關注。這和 Big Tech Companies 的思維截然不同，後者更強調產品能否長期維護、持續迭代與複用。
這當然只是我結合個人經驗的觀察，也歡迎讀者分享不同的見解 😆
