すこし古いけどこちらを読んだ。 pull request を利用した開発ワークフロー // Speaker Deck 非常にわかりやすく読ませてもらったが、本筋とはちょっとずれるレビューの勘所の話がとても面白く参考になった。 レビューコメントにラベルをつける [MUST] 問題があり、必ず治す [IMO] 意見、緩やかな指摘。自分ならこう書くけどどう? [nits] ほんの小さな指摘。インデントやタイポ たしかに普段のコードレビューでも、特に意識せずこれらは使い分けていた。こうしてラベルとして明示することでレビュイーに意図が伝わりやすい。レビュアーもこうした観点からレビューを行える。なによりレビュアー・レビュイー双方にとって明確に、指摘事項に優先順位がつけられる。こうすることでレビューとその後のアクションをよりスムーズにすすめる手助けになっている。 いいレビューとだめなレビューというものは
![コードレビューのポイント](https://cdn-ak-scissors.b.st-hatena.com/image/square/87bb59df23f4ab97a94294d3a89d9daa76699003/height=288;version=1;width=512/https%3A%2F%2Fplease-sleep.cou929.nu%2Fimages%2Fkosei-pic.png)