コードレビューで使えるチェック項目まとめ

この「コードレビューで使えるチェック項目まとめ」は優れた先人の知恵の寄せ集めて若干の編集を加えたものです。
記事作成時に参考にした記事を下部にまとめて掲載しています。

心構え

ポジティブなコードレビュー文化を育てよう

"ピアレビューはチームの対人関係に影響することがある。コードの全ての批評をチームメイトが行い、管理者がコードの欠陥密度を測定・評価するのは難しい。そのため、ピアコードレビューがうまくいくには、ピアレビューによる協働と学習の文化を作ることがとても大事。
欠陥＝「悪いもの」として見ることは簡単。ただし、バグはチームがコードの品質を改善する機会でもある。また、ピアレビューは、経験の浅いチームメイトがリーダーから学ぶ良い機会になるし、経験豊富なプログラマの悪癖を直すきっかけにもなる。
ピアレビューで見つかった欠陥をチームメンバーの評価に使うたぐいのものではない。ピアコードレビューの結果を、パフォーマンスの評価として使わないこと。個人の指標が報酬や昇進の基準になると、開発者はプロセスに敵意を抱くようになる。そして、全体が良くなるコードではなく、個人的なメトリクスを改善するためのコードを書くようになってしまう。"

https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
[和訳]https://qiita.com/terra_yucco/items/d101a57566a5e9b3a076

常にポジティブで始める

"ポジティブな雰囲気を出せるように、私はいつも感謝とうまくいった点からレビューを始めることにしました。
対処する必要があるコードに多くの問題点があったとしても、彼らの貢献に対して感謝の気持ちを表現することは大事です。
間違いのあるコードは、何もないコードよりは優れているので、問題を解決するための最初の段階を乗り越えたことに感謝するのです。"

https://dev.to/jnschrag/10-lessons-learned-conducting-code-reviews-5di6
[和訳]https://qiita.com/rana_kualu/items/7d8d7891d15ad03d82c6

目的

コードの品質を向上させる
経験の浅いチームメイトがリーダーから学ぶ
経験豊富なプログラマの悪癖を直すきっかけ

チェック項目

原則にしたがっているか

KISS
YAGNI
SOLID
- 単一責務の原則が守られているか
- 開放閉鎖の原則が守られているか
- リスコフの置換原則が守られているか
- インターフェース分離の原則が守られているか
- 依存性逆転の原則が守られているか
PIE
DRY

実装・スタイルの観点

コーディングガイドラインに反していないか
メソッド名が適切か
変数名が適切か
関数の行数が長すぎないか
関数の引数が多くないか
論理演算子の数を減らせないか
ネストの数を減らせないか
変数のスコープが狭くできないか
型は適切か
厳密等価演算子が使われているか(A === B)
例外処理がロジックとして使われていないか
例外が握りつぶされていないか
言語・フレームワークに用意されているメソッドを使用しているか

非機能の観点

セキュリティの問題はないか(パスワード・API KEYなどが直接埋め込まれていないか)
処理効率が悪くないか
コメントがわかりやすいか
コメントアウトされたコードが残っていないか

テストの観点

テストコードが書かれているか
要件が満たされるテストになっているか
テストコードのカバレッジは問題ないか

レビューにラベルをつける

レビューの意図を伝える共通言語

[must]

必ず修正する要件を満たしていない明らかな間違いなど

[nits]

「nitpick」の略スペルミスなどの細かい指摘

[imo]

「in my opinion」の略こんな記述はどうでしょうかと提案をする

[ask]

質問だということ明記

レビューで活用できる文言集

"コメントをやわらかくするため、You-Message(非難、命令)ではなくI-Message(感想、提案、質問)を使いましょう。"
コードレビュー虎の巻〜指摘の数だけ強くなれるよ〜 (https://qiita.com/akira_/items/ad2fe44ec342ef7fce84)

変数名が不適切です
○○してください
変数名がわかりにくいと感じました
○○はどうでしょうか？
この処理を入れているのはなぜでしょうか？
私なら○○にするかもしれません

参考にした情報

【和訳】コードレビューのベストプラクティス (https://qiita.com/terra_yucco/items/d101a57566a5e9b3a076)
コードレビュー10の鉄則 (https://qiita.com/rana_kualu/items/7d8d7891d15ad03d82c6)
PIEでKISSな仕事でDRYにしよう。『最速の仕事術はプログラマーが知っている』清水亮著。(https://katri755.com/programersworkskill/)
Wiki - SOLID(https://ja.wikipedia.org/wiki/SOLID)
Wiki - KISS(https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87)
Wiki - YAGNI(https://ja.wikipedia.org/wiki/YAGNI)
コードレビューの大切さを普及する活動(https://qiita.com/nanaki11/items/6c865040fd4b258a1aa3)
コードレビューのベストプラクティス(https://postd.cc/code-review-best-practices/)
コーディングの指針(https://foo-x.github.io/coding-guidelines/)
コードレビュー虎の巻〜指摘の数だけ強くなれるよ〜(https://qiita.com/akira_/items/ad2fe44ec342ef7fce84)
レビューにラベルをつける(https://qiita.com/ryuken/items/e0214ed97f46183fa3bc)
やめた方が良いコーディング・設計、アンチパターン (https://qiita.com/peutes/items/ad046baa2428b522a133)