{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 減肥

  1. 功能規劃階段把規格、相關文件理清

  2. 把需求拆成半天可以完成的小任務

  3. 任務相關性拉出來

  4. 依據相關性實作,一個任務一個 PR

  5. 關鍵字: Stacked PR

  6. 目標: 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 (網頁開發雜記)