投稿日
最終更新
カテゴリー
タグ
開発メンバーが増え、PRレビューを行うメンバーも増えてきました。
メンバー間でレビューの品質を向上したり、新しくレビューする人がしっかりレビューできるようにするために、ガイドラインを示します。
記述中メモ
- オレンジ：説明に含めたいもの。文章を改善する必要あり
レビューの観点
コードの設計
- コードが記載されている場所、分割が正しく、ルールに従っていること
機能性
- コードが意図した動作をしていること
- 必ず動作確認を行っていること
- エンドユーザー目線で使いにくくないか
- 例えコードが正しくても、エンドユーザーが使えなければ、意味がない
- パフォーマンスが悪くなっていないこと
- 解決したい課題に対して、解決方法が適切であること
複雑さ
- コードが複雑ではなく、開発者が読みやすいこと
- コードが複雑な場合、開発者が理解しにくくなり、修正するときにバグが入り込みやすくなります。
- 特に注意：if文、三項演算子、SQL文
- 「将来解決する必要があるかもしれない」といったコードを含めないこと
- 良くない例
- マジックナンバーの記載
- 関数、メソッドが長すぎる
テスト
- 適切なテストが用意されていること
- テストは、単体テスト、インテグレーションテスト、E2Eテストなどが適切に用意されていること
- テストの設計が正しいこと
- テストは、正しく、意味があり、役に立つものであること
- シンプルで役に立つアサーションを行っていること
- テストは適切に分割されていること
命名
コメント
スタイル
Gitの使い方
- mainブランチとの距離
参考
- https://google.github.io/eng-practices/review/
- https://shuuji3.xyz/eng-practices/review/
- https://cloudsmith.co.jp/blog/efficient/2021/08/1866630.html
- https://qiita.com/rana_kualu/items/379eefb3a40c6b44cb92
