(圖片引用來源)
在團隊中，Review 的機制非常重要，不管是不是寫 code，都需要有夥伴幫你確認寫的內容是否正確
也能在 Review 階段中發現自己的不足、給予其他人改善的建議
無論如何，它的存在非常重要，良好的 Review 機制會能讓團隊彼此成長的、也能建立更好的團隊文化。
先分成三大類
Review 顧名思義就是 審查/回顧。
但看名詞的話，不用把它想得太可怕XD，審查不過，頂多就是修改一下即可。
這個審查最大目標就是【希望我們所撰寫出來的東西(Test Case/自動化)別人是看得懂的】
如果連第一關審查的人都看不懂，那其他人一定更加看不懂。
既然是審查，就表示它需要有所規範，有明確定義哪些是可行的、哪些是不可行的
這時就需要定義團隊的 write/code style
建議規則的目標為
的方式為前提進行定義 style 規則。
名言分享:
Good code is code that can be understood by a junior engineer.
Great code can be understood by a first year CS freshman.
The best code is no code at all.
在工作的過程中，難免會有出差錯、卡住有問題的情況。
這類的回顧，可以更好檢視我們的工作狀態是否有問題、是否需要改善。
(圖片引用來源)
前面文章有提到，QA 寫 Test Case 也是常態。
但 Test Case 最大的目的除了是條列出產品的測試項目，最重要的也是要讓其他人看得動才行
如果寫了半天的 Test Case，結果所有人都看不懂，那完全沒有意義XD
正確流程可以是
(上方可能會視團隊情況，會在多一層主管 Reviewer)
透過上方一來一往，我們就能盡量確保撰寫 Test Case 的語意、方式、風格，是否都正確
正確的 Test Case 再日後撰寫自動化會極為重要
若是再撰寫自動化階段，完全看不懂 Test Case，那這樣又要再多耗一層功去改 Test Case，導致自動化進度會被 delay
(圖片引用來源)
其實這就是我們常說的 Code Review，畢竟寫自動化也是在寫 code。
code 的撰寫方式需要更為嚴謹，因為牽扯到邏輯。
自動化的前提往往都是依照 Test Case 去進行撰寫
只要 Test Case 足夠完善，清楚明瞭，在撰寫 自動化 時就只剩下撰寫 code
正確流程可以是
(上方可能會視團隊情況，會在多一層主管 Reviewer)
這就是屬於 回顧 的部分
主要目的是檢視團隊 上一周 的工作狀態，將已知問題回報給團隊其他成員們知道(及主管)，近一步探討如何改善。
e.g.
同時 Review 完後
主管則是將 Review 結果做個總結 並 依照團隊量能分配 下一周 的工作事項
e.g.
就會一直周而復始的進行 Review，不斷的跌代工作流程、進行優化、追蹤進度。
iThome鐵人賽
看影片追技術