InSnap如何在程式碼審查與 Pull Request 中使用截圖
只看 diff 很難審查介面變更。準備一組精簡的截圖——前後對照、加上標註、聚焦關鍵狀態——就能讓 Pull Request 變得容易審查。
一個只改按鈕行為、表單驗證或載入狀態的 Pull Request，很難單從 diff 判斷。審查者最後只能切到分支、重新建置，再自己去找你說的畫面。準備一組精簡、做得到位的截圖，就能省下這些工。
擷取修改前與修改後
只要是可見的變更，就把同一個畫面截兩次：
- 在 base 分支上，擷取受影響的區域。
- 在你的分支上，用相同視窗大小與縮放比例，擷取完全相同的區域。
- 兩張都留著；不要其中一張裁得比另一張緊。
對齊視埠、瀏覽器縮放與視窗大小，比較才有意義。如果版面是響應式的，就截真正重要的寬度（例如 1280 與 390），並標上名稱。
只標註差異
審查者需要知道該看哪裡，不是要你帶他逛一圈：
- 一張截圖有多處變更時用序號：1 是新的空白狀態，2 是錯誤訊息。
- 用形狀圈出變更的區域。
- 用文字寫出預期行為，保持簡短。
- 任何私密內容都用馬賽克或模糊：客戶姓名、電子郵件、權杖、內部網址。
不要把整個畫面都標滿。如果變更只是一個控制項，一個箭頭加一句話就夠了。
靜態圖不夠時，錄下互動
有些變更只有在動態中才說得清楚：一個原本太早關閉的下拉選單、一個現在會正常結束的載入動畫、一段拖曳互動。用快速錄製錄個 10–20 秒，然後附上 MP4；如果希望直接在討論串裡播放，就附 GIF（Pro）。
- 盡量在同一段影片裡先示範出錯行為，再示範修正後的行為。
- 除非旁白真能補充什麼，否則關掉麥克風；無聲影片自動播放不會嚇到人。
- 影片要短到能看兩遍。
把證據放進 Pull Request
可預期的結構能替審查者省時間：
- 用一句話說明改了什麼。
- 修改前 / 修改後圖片，並排或上下排列，每次都維持相同順序。
- 如果截圖不是預設畫面，說明如何重現該狀態。
- 該檢查什麼——最可能回歸的一兩件事。
- 若有必要，寫上環境：作業系統、瀏覽器、顯示縮放。
圖片直接附在 Pull Request 上，不要連到個人雲端硬碟。若使用分享連結，記得它可能到期或需要密碼；程式碼審查通常還是附件更合適。
讓整組保持精簡
審查者是用掃的。三張聚焦的截圖會被看完，十五張只會被滑過去。
- 每個可見變更一組前後對照。
- 裁掉瀏覽器外框與不相關的面板。
- 只為提供脈絡的圖片可以壓縮或縮小；像素層級的變更則保留完整解析度。
- 刪掉那些只是換個角度重複同一狀態的截圖。
送出前檢查清單
| 檢查 | 原因 |
|---|---|
| 前後對照的視埠與縮放相同 | 否則比較不成立 |
| 一張圖只放一個變更 | 比較容易討論與結案 |
| 標註直接指向變更處 | 不必再找 |
| 私密資料已隱藏 | Pull Request 的可見範圍常比想像中大 |
| 只在需要動態時才附影片 | 短才好看完 |
| 用附件，不用個人連結 | 審查者不該需要額外帳號 |
常見問題
該附截圖還是螢幕錄影？
狀態用靜態圖，互動用短片。10–20 秒的錄影就足以呈現一次轉場；再長通常會被跳過。
審查截圖裡要怎麼隱藏客戶資料？
姓名與 ID 用設定較強的馬賽克，機密內容用實心遮蓋，或直接把該區域裁掉。模糊比馬賽克弱，不該用在任何敏感內容上。
做審查截圖需要 Pro 嗎？
擷取、標註、序號、馬賽克與基本 MP4 錄影都不需要。GIF 匯出、智慧擦除與影片編輯器的效果屬於 Pro，但一組靜態圖加上 MP4，免費就能涵蓋大多數審查需求。
