簡單說，就是儘可能把工作都拆分成最小單位的功能，儘可能的送最小的提交內容，才可以比較快透過 Code Review 檢視對應的開發品質和問題
Problem: My team likes to have big bulky commits. Solution: Start dividing your work into smaller commits. When your team sees the clear benefits of reviewing your code, they will most likely follow.
儘量安排在一天內分配一些時間去執行 Code Review，如果無法做到，至少也要嘗試用 60/70/80 分鐘來執行 Code Review，儘量不要把自己搞到還要另外加班做這件事
Problem: My team ships code into production at crazy hours. Solution: Prioritize your reviews by checking the essential when a complete review is not possible (see the review checklist below). When you see yourself not being able to properly review code, try to change the timing, deploy hours.
執行 Code Review 這項工作儘量不要都落在同一個人身上，只會讓人更辛勞的工作，更慢的部署，降低注意力造成更糟的 Review 結果
Problem: But my CTO is micromanaging the code reviews to make sure everything is alright Problem 2: But I don’t trust my team to deploy code without my eyes on it. Solution: Teach a man to fish. Also, make for your (or your boss's) review as an additional safeguard but not an essential blocking one.
在開發之前，最好先確保每個人都先暸解相應的 Code Guideline，花一些時間來暸解這些規範是必要的，優秀的人總是會不斷的精進自己的技藝，優秀的開發人員也始終希望自己持續保持在最新的狀態下。
建立一份檢查清單可以加快 Review 效率
如果只透過 Git 檢查(查看 log，差異和 commit)，是非常秏時的，可以利用 Github、Bitbucket、GitLab，可以快速查看變化，快速與人溝通，決定是否核準提交等，你可以更有效率的執行 Code Review，
如果你當前沒有太多時間可以執行 Code Review 時，可以優先檢查 issue，僅檢查主要的問題，稍後檢查代碼樣式，也可以稍後透過 linting 自動檢查代碼樣式。最重要的部分是所有權和知識的共享
如果時間很緊迫，沒有辦法複查內容，請採用漸進的方法。在 Code Review 過程中，如果提交有足夠大的問題需要修正時，可以先利用 "短路(Short-Circuitin)元素，即 [AND &&，OR ||，NOT !]" 先忽略比較小、不重要的問題，以便將來再更正其代碼時再對其進行檢查。
利用註解，簡單明暸的方式描述代碼實現的功能及背後的設計決策，可以減少 Code Review 的工作。[Linux kernel guides(https://www.kernel.org/doc/Documentation/process/submitting-patches.rst)
增加自動代碼審查工具，可以使 Code Review 的某些方面自動化，例如代碼樣式，最佳實踐和常見問題。我們可以只檢查重要內容，透過自動化節省時間，結合最重要的方面，可以確保自己不用花更多的時間在 Code Review