滾動式程式碼安全審查：以更多審查投入換取較短等待

值得記下的 5 件事

1. [0:40]
   凍結版本的瓶頸在於流程依序推進 傳統方式先審查指定版本，再由客戶修補，最後複測

   講者指出，若開發團隊持續累積新程式碼，受審版本便可能落後，增加複測工作，進一步拉長審查流程。

2. [2:20]
   逐項審查不能取代最後的整體檢查 滾動式流程從基準版本開始，接著審查持續送來的程式碼合併請求，最後檢查整合版本

   講者強調，過程中要追蹤變更之間的衝突，所有變更合併後仍須整體審查；這些措施有助減輕負擔，但不代表能消除審查者的心智負荷。

3. [3:00]
   並行作業縮短的是流程經過的時間 講者展示的範例讓開發與安全審查同時進行，將流程由四至六週縮至約三週

   他表示，採用此方式的客戶希望每兩週進行一次硬分叉；上述時程是特定範例，不是所有專案都能達成的保證。

4. [3:40]
   縮短等待需要增加審查端的投入 不同合併請求若修改同一函式，審查者就得重複檢查，還要追蹤多個變更之間的交互影響

   講者估計，相較凍結版本方式，額外管理與重複工作約增加一至兩成審查投入；這是他的估計，不是經量測驗證的固定比例。

5. [4:40]
   選擇方式須考量開發節奏與預算 講者認為，能暫停程式碼變更、審查範圍明確且重視預算效率的專案，較適合凍結版本審查

   他仍推薦多數智慧合約沿用此方式；程式碼快速增加、開發者不停下來整理發布的鏈下協議，則較適合考慮滾動審查。