{code review}
來一場兼顧程式碼品質以及開發效率的
關於我
Fin
網頁開發雜記
Yourator CTO
前端工程師
# INTRO
- 那個誰今天請假沒有辦法處理
聽說他啊罵又過世了 - 程式碼越來越難維護
自己寫的自己都看不懂 - QA & PM:bug 怎麼這麼多
- 不知道自己寫的東西是否完整
這些都是軟體開發時會遇到的問題
# INTRO
- 促進團隊合作與知識分享
- 提升程式碼品質、可維護性
- 確認有照規格完成,減少 bug
- 提高佈署信心
我期望 Code Review 可以...
# INTRO
Code Review 的本質
透過知識與視角的交流
提升產出品質與團隊技術水準
# INTRO
- 非常耗時,平均 6hr / wk
-
平均耗時數日,大範圍變更需要更久
-
找出問題的比例僅佔 14%
現狀與挑戰
# INTRO
Code Review 很好
但實在太耗費
時間與精力了
# INTRO
{code review}
兼顧程式碼品質以及開發效率的
三種角度度來看 Code Review
技術執行面
Code Review 本身的進行
1.
2.
知識交流面
Reviewer 跟開發者交流、相關知識的傳遞
3.
整體開發面
從整個開發流程的其他地方來幫助 Code Review 更順暢進行
# CODE REVIEW
{技術執行面}
同步
- Pair Programming
- Live Review
- Code Review Meeting
- Code Walkthrough
非同步
- PR Review
Code Review 的形式
Pair Programming
# 技術執行面
Live Review
# 技術執行面
Code Review Meeting
# 技術執行面
Code Walkthrough
# 技術執行面
PR Review
# 技術執行面
形式 | 特點 | 適用場景 | 優點 | 缺點 |
---|---|---|---|---|
Pair Programming | 兩名開發者同步合作,一人寫扣、一人審查和提供建議 | - 複雜功能開發 - 高風險代碼的實作 - 新人培訓 |
- 即時反饋,快速解決問題 - 減少缺陷 - 促進知識共享 |
- 需要雙人同步時間- 對時間和人力要求高 |
Live Review | 同步進行的審查,Reviewer 和開發者即時交流並討論細節 | - 緊急變更需要快速確認 - 複雜,需要深入討論 - 新人指導 |
- 即時互動,減少溝通成本 - 適合高複雜度的問題 - 提高團隊信任 |
- 可能導致討論發散- 占用多人同步時間 |
Code Review Meeting | 團隊集體參與,針對關鍵程式碼進行深入討論 | - 重大架構或設計變更 - 高風險功能 - 團隊知識共享 |
- 多方視角,檢查更全面 - 促進團隊學習 - 提高設計透明度 |
- 時間成本高- 不適合日常小型變更 |
PR Review | 非同步的審查,通過工具(如 GitHub/GitLab)查看變更並留下評論 | - 日常開發的變更審查 - 遠端或跨時區團隊 |
- 時間靈活 - 有審查記錄可供日後查閱 - 可結合自動化 / AI 工具提升效率 |
- 缺乏即時互動,易造成溝通不暢 - 複雜變更需要花更多時間理解 |
Code Walkthrough | 同步進行,開發者逐步解說邏輯和設計,Reviewer 提出問題和建議 | - 新人指導 - 複雜程式碼的學習 - 熟悉系統未知區塊 - 團隊知識共享 |
- 有助於新人成長 - 幫助團隊理解系統的複雜邏輯 - 促進開發者反思自己的程式 |
- 偏重於知識傳遞,審查效率不如其他形式 |
# 技術執行面
緊急
不緊急
複雜
簡單
Pair
Programming
Live Review
Code Review
Meeting
PR Review
Code
Walkthrough
對自己有信心一點
直接佈署
- 選擇正確的 Code Review 形式
- 自動化:靜態程式碼分析 + 測試 + CI 確保程式碼基本品質
- AI 化:幫助找出一些基本錯誤
- 主要精力放在實作跟介面的審查
提升執行面效率
AI Code Review
# 技術執行面
AI Code Review
- 定義清楚的規格書對於 AI 產出的品質有正面的影響
- 合理變更範圍內,對 coding style,
api 參數、錯誤處理方式等的建議都很實用 - 不要期望 AI 可以有架構性的建議
- 檔案數量太多 AI 一樣可能會有品質下降的問題
# 技術執行面
{知識交流面}
Code Review 最大的挑戰是
『理解內容以及理解變更的理由』
# 知識交流面
in a successful code review submission the author is sure that his peers understand and approve the change.
一個成功的程式碼審查,開發者確信他的同儕理解並認可這些修改。
正確的理解後
才能正確的給予回饋
- 先閱讀 PR 的描述和提交記錄,確認自己是否理解這次變更的目標
- 參考相關測試與文件、規格說明
- 若有疑問,主動提問,要求補充背景資訊
-
用最有效率的方式來獲取資訊
-
討論過程中的重要資訊記得整理與記錄
# 知識交流面
交流要點1: 更有效率的理解
-
同步 > 非同步
-
面對面 > 線上
-
正面語氣 > 負面
-
在 code 上可以連結到的文件紀錄
# 知識交流面
媒介不僅只有文字,依據需求要直接找開發者線上作個 code walkthrough
或如果有更深入的內容想討論的話面對面用白板討論都是方法
# 知識交流面
Assume Positive Intent
預設大家都想把事情做好
數據
負面語氣的審查:57% 被認為有效
正面或中立語氣:80% 被認為有效
交流要點2: API 原則
# 知識交流面
交流要點3: 明確、可行動的
vs
# 知識交流面
來個經典案例...
# 知識交流面
這是 Linus 的
Code Review
-
對系統的理解力不容置疑
-
攻擊力 SSS
-
明確提出更好作法
A: 你覺得最終對品質的影響是正面還是負面?
# 知識交流面
{開發流程面}
在功能規劃階段把規格定義與紀錄清楚
# 開發流程面
1.
Planning
2.
Designing
3.
Implement
4.
Testing
5.
Deploy
6.
Mainenance
Code Review
clear spec
PR 大小 vs 審查效用
# 開發流程面
PR 大小 vs 審查時間
# 開發流程面
Ask a programmer to review 10 lines of code, he'll find 10 issues.
Ask him to do 500 lines and he'll say it looks good.
PR 減肥
-
功能規劃階段把規格、相關文件理清
-
把需求拆成半天可以完成的小任務
-
任務相關性拉出來
-
依據相關性實作,一個任務一個 PR
-
關鍵字: Stacked PR
-
目標: LOC < 500
# 開發流程面
Self Review
# 開發流程面
-
交付 Code Review 之前
先自行 Review 一次 -
可以透過 AI Coding Tool 幫忙 Review
Review Prompt: Implementation
I want you to performing a code review, ensure the following checklist is satisfied:
1. **Meets functional requirements**: Verify that the code implements all required features and satisfies the intended use cases.
2. **Correct implementation logic and simplicity**: Ensure the logic is correct, concise, and free of unnecessary complexity.
3. **Proper synchronization and error handling**: Confirm that the code correctly handles concurrency and errors, avoiding potential deadlocks or unhandled exceptions.
4. **Security**: Check for common vulnerabilities, such as SQL injection, XSS, or insecure handling of sensitive data.
5. **Observability**: Ensure the code includes proper metrics, logging, and tracing mechanisms to facilitate monitoring and debugging.
# 開發流程面
Review Prompt: Interface
I want you to performing a code review, ensure the following checklist is satisfied:
1. **Simplified interface that meets requirements**: Verify that the interface is as minimal and straightforward as possible while still fulfilling all functional requirements.
2. **Consistency and adherence to the Principle of Least Surprise**: Ensure the interface behaves predictably and aligns with established conventions or patterns within the codebase.
3. **Encapsulation of internal state**: Confirm that internal states are properly hidden, exposing only the necessary information or methods to the external world.
4. **Compatibility with dependent components**: Verify that all components or modules interacting with the interface function correctly without unexpected issues.
# 開發流程面
AI Code Review
- 定義清楚的規格書對於 AI 產出的品質有正面的影響
- 合理變更範圍內,對 coding style,
api 參數、錯誤處理方式等的建議都很實用 - 不要期望 AI 可以有架構性的建議
- 檔案數量太多 AI 一樣可能會有品質下降的問題
# 技術執行面
其他 GenAI 可以幫忙的
# 開發流程面
-
產規格文件
-
產 PR Description
{最後}
你不一定需要 Code Review
# 開發流程面
-
對改動的信心足夠
-
測試足夠 或 QA 足夠
-
實驗性質的內容
挑戰的處理
# 開發流程面
-
使用合適的形式
-
針對容易 Review 的引入自動化工具
-
把心力放在需要 Review 的複雜內容上
-
規格明確,bug 自然會比較容易處理
-
縮減任務範圍 / PR 大小,縮減 Review 所需耗費的心力與時程
-
先 Self Review,自己能接受的品質才送出
{code review}
來一場持續進行才能
兼顧程式碼品質以及開發效率的
Get in touch
https://www.thingsaboutweb.dev
或搜尋『網頁開發雜記』
Code
By fin (網頁開發雜記)
Code
- 693