Code Review 代碼復審指南
一開始這篇指南是為團隊而寫的，后來發現包含的內容比較有一般性，所以刪掉了一些和團隊強相關的內容，發到這里。
「Code Review」直譯過來便是「代碼復審」，也就是讓代碼作者之外的人來復審代碼，提出修改意見，接受代碼變更。
益處
- 發現錯誤：一個人的思考總是會不可避免地出現一些紕漏，而這些紕漏在另一個人眼中也許顯而易見。
- 保持代碼風格統一：對于整個團隊來說，代碼風格的統一顯得至關重要。風格一致的代碼能提供更好的可讀性，也能避免犯一些「低級錯誤」。
- 保證設計的合理性：代碼直接反映出你的系統設計，在寫一個新的系統時，確保你的設計不會出現大問題。
- 保證提交的變更符合團隊的其他要求：例如對測試用例的要求和對文檔的要求；
- 互相學習：Code Review 的過程也是思想交流的過程，可以取人之長，補己之短。 </ul>
- 新人上手：Mentor 是第一選擇；
- 日常工作：同組的其他工程師；
- 向其他系統或模塊提交 Patch 或 Bugfix：相應系統或模塊的 Maintainer；
- 專業度很高的代碼：團隊中相應的領域專家。 </ul>
- 代碼風格：確保變更代碼風格符合規范。
- 明顯的錯誤：確保變更代碼不出現低級錯誤，例如訪問不存在的屬性或訪問空指針。
- 不合理的設計：確保變更代碼不出現明顯的不合理的系統設計，例如單個 Redis 實例存儲過多的數據、濫用 OOD 或動態語言特性。
- 明顯的性能問題：確保變更不會引發明顯的性能問題，例如連續、大量、串行地調用 RPC 接口或者不合理的存儲訪問模式。
- 測試用例：確保相應的變更有相應的單元測試。
- 注釋和文檔：確保有必要的注釋和接口說明文檔。
- 其他團隊約定：確保變更的內容符合團隊的其他約定，例如服務的接口的訪問需要接入監控系統和日志系統等。 </ul>
- 理解這個功能的細節。
- 理解這個系統的工程設計細節； </ul>
- Python 代碼規范
- MySQL 使用規范
- Redis 使用規范
- … </ul>
- 盡可能小：一個 Commit 的變更應該盡量少，一個 commit 只做一件事情，如果一件事情可以被拆分成多件事情，那么它們應該對應不同的 commit。例如，不要將「修復一個 Bug」和「重構一個函數」放到同一個 commit 里。
- 自成單元：一個 Commit 應該自成一個單元，例如，不要將一個新增的函數放到多個 commit 里。 </ul>
- Commit 的變更總結：變更內容本身就已經說明了詳細變更，所以在 message 里面只需要一個變更總結。
- 為什么要進行這次變更：這是更重要的一部分，因為在大多數情況下，變更內容并不能說明為什么需要做這次變更，知道變更原因才能更好地理解變更內容。只有當變更原因特別顯而易見時才能省略此部分內容，例如修復一個不存在的 API 調用。 </ul>
怎樣進行 Code Review
Review 時機
基本的語法檢查和自動化測試通過之后，代碼被合并到主分支之前。
Reviewer
Reviewer 可以是一個，也可以更多。在代碼變更越大、變更內容牽扯到更多的人和外部系統，或者自信度越低的情況下，你就可能需要更多的 Reviewer。另外在不同的場景下，你也需要不同角色的 Reviewer 參與。
內容
Reviewer 需要針對變更作以下復審：
如果被 Review 的內容對應一個新的系統或功能，Reviewer 還需要確保：
合并時機
通常來說，需要所有的 Reviewer 都接受變更才能合并代碼。
Review 文檔
編寫 Review 友好的代碼
高效地進行 Code Review 不僅僅只是 Reviewer 的工作，代碼的作者也起著至關重要的作用。
Commit 粒度
總的來說，Commit 的粒度應該遵循以下原則：
Commit Message
Commit Message 應該包含兩部分內容：
Commit Message 的推薦格式為：
變更內容總結變更原因詳細說明...</pre>
例如：Refactor foo module with gevent.We met performance issue with foo module recently, foo handles client requests one by one so we just use gevent for concurrency.</pre>
壞的例子，如：
</tr> </tbody> </table> </div> Fix a bug.這個也好不到哪兒去：
Update config.Update the 'host' config to
b_serverfroma_server.</pre>
Review 單元粒度
一個 Review 單元包含一個或多個 commit。
Review 單元的粒度應該遵循以下原則：
- 盡可能小：一個人連續高度集中精力的時間通常不會太長，所以更小的 Review 單元能夠得到 Reviewer 更細致的復審，Code Review 的質量就會更高。
- 能夠安全地并入主分支：Review 單元在被 Reviewer 接受之后應該盡快并入主分支，這樣才能更好地實現持續集成和持續交付。因此，一個 Review 單元應該要能安全地并入主分支。
</ul>參考來源
- Writing Reviewable Code
</ul> 來自：http://blog.psjay.com/posts/code-review-guide/本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！相關資訊
sesese色