很多工程師，會希望自己的程式有人看過，有人可以提供Feedback。但相反的，很多人懶得幫別人看Code，覺得開發以外還要做額外的事情，真的是很麻煩。
我個人覺得Code Review是值得的，畢竟人再怎麼精明總是會有盲點，多一個人幫忙看一下會比較心安。
不過Code Reivew不只是看看Code而已，要懂得怎麼看才有意義。
Code Review的目標
做一件事情之前，要先確認這件事的目的，才不會迷失方向，我認為Code Reivew的目標有這些：
- 確保程式碼的品質及正確性
- 維持團隊開發默契，並達到知識共享
- 了解彼此正在做什麼
- 作為資深工程師教導新進工程師的手段之一
可以發現這些目標其實都是為了：提高團隊效率。
Code Review 心態
除了確立目標，心態也要建立。
- Code Reivew不是互相攻擊，而是互助。
- 重點是程式，而不是人
- 穩定前進
- Review是對團隊負責
建立這樣的心態，是為了降低施行Code Reivew時，可能遭遇的成員衝突。
要Review什麼？
目標跟心態都建立好了，那到底要Review什麼？
- 商業流程是否正確，是否有遺漏案例未處理？
- 函式庫用法是否正確，是否有危險用法？
- 類似的功能，是否有已知的更好的做法？
- 是否有符合軟體設計原則，可讀性、可維護性等？
- 是否有修改不應該修改的部分，可能進而影響其他人？
- 是否有符合團隊所規範的Coding Style？
我覺得，對於Junior或新進員工，可以做到比較仔細的Review，如果是資深或Senior的同事，可以只抓重點看。
如何給予修改建議？
- 使用適當的工具如Gitlab GUI
- 提出具體建議，可提供事證或參考資源
- 若有修改建議可以提供範例Code，Best Practice作法
好的工具可以減少Code Reivew的負擔，團隊成員可以溝通好一套彼此都方便使用的工具。
提供建議的時候，盡量避免主觀想法，「我覺得...」，而是客觀的給予建議，若能提出具體的證據、經驗可以證明的話更好。
不要這樣給建議
- 不要用個人喜好去評斷程式、做法的好壞
- 不要用情緒性的字眼提供feedback
- 不要提出超過此次提交(Commit)範圍的修改需求
第1、2點其實是呼應前面提到的心態建立，Review是為了大家好，而不是讓大家互相傷害的行為。
第3點，有時候Reviewer在檢視程式碼的時候，可能會有其他想法，例如重構或大規模修改，這些想法很好，但需要考量到團隊時程的安排，不可以任意向Developer提出這類的要求，可以轉為其他專案進行。
Code Review的難題與可能解法
不知道要找誰Review
請專案負責人指派，或是由開發團隊制定一套規則，隨機或輪流指派。
Code Review意見衝突
可由第三人定奪，可為技術主管、專案負責人、或是更資深的同事。
沒有資深同仁可以帶領
新進同仁彼此互相Review也是一個好的開始。
每次要Review的Code太多
需要控制提交範圍，大型專案不應該等到最後一口氣Commit。
Review時間不夠
剛開始進行Code Review可能會比較慢、比較辛苦，但會漸入佳境。若主管希望可以在團隊中推動Code Review，應該要在專案估時中，將此流程也考慮進去。或是先從小專案開始讓大家熟悉，最後才將Code Review排入正式開發流程。
推很久推不動
可以檢視一下團隊成員的組成是否適合...。
Code Review可能不適合某些人
我認為推行Code Review最困難的點是心態的建立，如果團隊成員沒辦法對於這個流程，有同樣的共識，推動起來非常容易造成團隊衝突也達不到預期效果。
所以我認為如果團隊中有這樣的人，可能要想辦法先處理，否則難以進行：
- 上班是來養老的人，工作態度散漫不積極，不求進取
- 容易敵視別人的人，將別人的建議視為攻擊
- 無法心平氣和地給予別人建議的人，對於程度較差者沒耐心