ソースコード確認

バグの回避やパフォーマンスの改善のため、コーディングの品質を高めることはとても重要です。
コードの品質向上に近道はありませんが、一般的に多くのケースで適切とされるコーディングの方針を整理しています。
当社ではこの方針に沿ってコーディング・レビューを行うことで、コード品質の向上・標準化を図っています。

コーディング方針#

コーディング・レビューの際に最低限確認する観点リストをまとめています。
実装担当・レビュアーはリストを確認しながら実装・レビューを行います。
リストは完成形ではなく、品質向上のために何を重視するかによって内容を議論し、絶えずブラッシュアップしています。

No	品質特性	内容	例（Flutter）
1	機能性	入力値の考慮：入力されうる値（正常値、異常値、境界値など）を考慮して処理されているか。	リンク（作成中）
2	効率性	定数と変数の使い分け：定数、変数の使い分けができているか。変更されない値を変数として扱っていないか。	リンク（作成中）
3	効率性	ループの最適化：ループさせる必要のない処理（ループ内で不変の値の計算など）はループ外にあるか。	リンク（作成中）
4	効率性	DBアクセスの最小化：不要なDBアクセスが行われていないか。	リンク（作成中）
5	効率性	DBアクセスの最小化：データのキャッシュが適切に行われているか。	リンク（作成中）
6	信頼性	アクセス修飾子の活用：パラメータ、メソッドのアクセス修飾子（public、private）が適切に付けられているか。	リンク（作成中）
7	信頼性	オプショナル型の活用：不必要にオプショナル型を用いていないか。	リンク（作成中）
8	信頼性	オプショナル型の活用：オプショナル型を強制アンラップしていないか。適切なタイミングでnullチェックされているか。	リンク（作成中）
9	信頼性	異常系の処理：例外処理を適切に行い、アプリが意図せず停止しないよう実装されているか。	リンク（作成中）
10	保守性	単一責任の徹底：クラスの責務が1つに絞られているか。（UI実装のやむを得ない場合を除き、）目安としてクラスが300行以内で書かれているか。	リンク（作成中）
11	保守性	重複の排除：同じ責務を複数のクラスに実装していないか。	リンク（作成中）
12	保守性	単一責任の徹底：メソッドの責務が1つに絞られているか。（UI実装のやむを得ない場合を除き、）目安としてメソッドが50行以内で書かれているか。	リンク（作成中）
13	保守性	重複の排除：同じ責務を複数のメソッドに実装していないか。	リンク（作成中）
14	保守性	ネストの最適化：（UI実装のやむを得ない場合を除き、）3階層以上のネスト（条件式を3階層に連ねて記載など）がないか。	リンク（作成中）
15	保守性	横断処理の共通化：横断的な処理（ログ出力、エラー・例外処理など）が共通のクラスやメソッドにまとまっているか。	リンク（作成中）
16	保守性	異常系の処理：エラー・例外の際にログを出力しているか。	リンク（作成中）
17	保守性	パラメータ数の最適化：4つ以上の引数を持つメソッドがないか。ある場合、パラメタをまとめたクラス化ができないか。	リンク（作成中）
18	保守性	名前の一意性：クラスやグローバルスコープのメソッド、パラメタの名前が一意に特定できるものになっているか。	リンク（作成中）

参考: 品質特性

レビュー指摘リスト#

プルリクエストでの指摘事項のうち、横展開すべき内容をリストにまとめ、エンジニア間で共有しています。
コーディング方針と併せて指摘リストを確認し、適宜項目を追加・更新することで、品質改善のための知見を積み上げています。

リンク: レビュー指摘リスト