在熟悉開發知識庫所撰寫的文件範例後，總算可以來聊聊每期衝刺活動(sprint)的code review都在做些什麼事情了。
有別於疊代追蹤報告(iteration review)在10分鐘內結束，code review以個人經驗，最久可能耗時到半天的時間。不過時間花得很值得 ! 因為團隊的成長，都仰賴code review中，成員們對於技術上的爭論以及腦力激盪所激發出來的火花。

code review討論以下事項 :

• 解說每張卡片對應的技術文件報告，並指派最資淺的成員依照文件實作(複雜的話可另外安排時間實作)。
• 對於每期開發出來的程式碼執行撰寫好的單元測試(Unit test)並暢所欲言的討論。
• 每個成員簡述(3分鐘內)一下本期開發的心得感想。
• 對於下期程式碼的開發建議。

在進入code review前的「Task 卡片」如下圖 :

與之前的差異就是補上Day 20的程式開發文件連結。說明完文件並指派最資淺成員日後或當下實作後，就能將卡片設為已完成。
在測試三角形中，單元測試Unit test為了保護業務邏輯以及未來重構的依據，多多益善。

而且每期建議指派不同的成員來撰寫測試，真的會有令人意想不到的結果。
心得感想因人而異，這邊就不特別說明了。
最後，來分享一個印象深刻的開發建議實況討論吧 !

(code review 實況)
(資深)成員1 : 成員2，你所開發的那段api功能，怎麼把controller、service、dao、entity又另外建了一份出來 ?
(資淺)成員2 : 因為我上一份工作的架構都是這樣的，我不清楚這種架構有什麼問題。
(資深)成員1 : 這種做法跟我們現有的專案作法完全不一樣啊 ! 要習慣公司的做法。
(互相爭論中...ooxx)

如果妳/你是 Scrum 導師(SM)，上面的爭論會採納誰的 ?
成員1嗎? 因為明顯跟之前的架構不同。
這裡沒有正確答案，我只分享當初在code review中的論點。

(code review 實況，SM 介入中。)
SM : 大家先聽我說說我的想法。成員2開發api的做法明顯是微服務的架構。當介接的客戶越來越多時，未來勢必需要切出來做個k8s deploy，達到auto scale的效果。我覺得可以先維持成員2的這個架構，之後要切離的話，就不需要進入controller、service、dao、entity這幾個資料夾一個一個挑出來。那成員2，之後如果需要切離時就讓你處理了。我記得docker compose好像有針對這種架構打包image的方式，我等下google到文章後轉給成員2你研究看看。

再次強調，我也不知道正確答案是什麼 ? 只是當下大家都心平氣和了。