code review 中 developer 以及 reviewer 意見不和是常常發生的事情，有時 developer 會不同意 reviewer 的觀點，有時候 developer 會覺得 reviewer 太過嚴格，這時候應該要如何解決呢? 這篇筆記會記錄 google code review 中給出的一些建議 (´◉‿◉｀)

正如封面的照片一樣，code reviewer 的氛圍應該是要開心愉悅的，而不是針鋒相對，接續上篇 Google Code Review - Reviewer 篇 (4)，本篇住要講述 reviewer 的 comments 應該如何撰寫，以及一些應該注意的事項 ლ(╹◡╹ლ)

這篇主要整理如何加速 code review 的速度, 以及 code review 速度對於整體開發流程的影響，為針對 reviewer 系列的第四篇文章，為 google code review 筆記系列的的六篇文章。

接續上篇 Google Code Review - Reviewer 篇 (2)本篇為 reviewer 相關的第三篇，上篇為 reviewer 在 code review 中應該要注意的細節，而本篇主要會筆記一下 Reviewer 的 review 順序建議 ( • ̀ω•́ )

本篇接續上篇 Google Code Review - Reviewer 篇 (1)為 reviewer 相關的第二篇，主要會敘述 code review 中應該要被 review 的事項以及詳細的細節，特殊情況下的應對等等，若有寫錯或是表達不清楚的地方，也請大大們鞭小力一點 (✪ω✪)

如同上篇 Google Code Review - Author 篇 所述，此篇將整理 Reviewer 相關的筆記，因為 Reviewer 相關的內容較多，預計將分為三篇文章來記錄，一樣主要整理自 Google Code Review Guideline 的內容 ლ(・´ｪ`・ლ)

多人軟體開發流程中除了開發及測試外，另一相對重要卻常常被忽略掉的應該就是 code review process, 專案的開發過程中為了讓 code 品質可以更好，通常在功能開發完成要合併到 master branch 前都會需要至少一位相關的同事給予授權 (approval) 才能將修改的 code 合併進 master branch 中而在審核的過程就稱為 code review，然而事否有一套統一的準則能加速 code review 的過程並且提高 code review 的品質呢? 在網路上看了一些文章後有幸找到 Google 提出的 code reivew guideline，而當中分為 Reviewer 以及 Author 兩個部分，打算用兩篇文章分別筆記一下 XD(若有寫錯的部分也請大大們鞭小力一點)，本篇文章為 Author (提出修改者) 相關的筆記~

此篇為 Google Code Review Overview 的介紹, 主要擷取自 Google Code Review Guideline 的內容, 後續會陸續分為 Reviewer 以及 Author 兩部分文章紀錄，若內容有誤歡迎大大們指正，感激不盡 d(`･∀･)b