コードレビューまとめ

ざっと見てコードボリューム見る。 +400 くらいが妥当

https://gyazo.com/3afc1c119f16e7c32bb0207f3ea545fa

コミット粒度とコメントを見てみる

ざっくり全体感を見る、splitで見る

https://gyazo.com/6d9b026c3a625a3e253c672b23c2b91b

Reviewをするときに、なぜそうするべきなのか、cons, prosを示し、参考リンクもはる。

https://gyazo.com/898fcc6f08cf00b87ae3737a41dd7c3d

hogeしたほうがいい。
fugaということが考えられるから。
具体的に示すとこんな感じ

` bar foo puts hoge`

ref: http://tenshotanaka.hatenablog.com/

レビューコメントにラベルをつける

[MUST] 問題があり、必ず治す
[IMO] 意見、緩やかな指摘。自分ならこう書くけどどう?
[nits] ほんの小さな指摘。インデントやタイポ
  • 問題の内容や、どうしてこのプルリクエストが発生したのか把握する
  • 全く同意できない場合は、反応する前に数分自分の意見を検討する
  • 命令するのではなく、質問する（「…しないでください」よりも「…についてどう思いますか？」）
  • 誰かの作成した仕事を参照する際に、「バカな」などのような軽蔑的な言葉は避ける
  • 謙虚にやる。（「あまり分からないけど、試してみましょう…」）
  • 誇張を避ける。（「絶対に…しない」）
  • オンラインのコミュニケーションでは、ネガティブなバイアスがかかることに注意する。（内容が中立であれば、我々はネガティブな発言だと仮定しがちです）。→肯定的な書き方をする
  • 雰囲気を明確にするために絵文字を使う「いいじゃん」と「 :sparkles: :sparkles: いいじゃん :thumbsup: :sparkles: :sparkles: 」を比べてみてください。

Reference from