ソースコード確認
バグの回避やパフォーマンスの改善のため、コーディングの品質を高めることはとても重要です。
コードの品質向上に近道はありませんが、一般的に多くのケースで適切とされるコーディングの方針を整理しています。
当社ではこの方針に沿ってコーディング・レビューを行うことで、コード品質の向上・標準化を図っています。
コーディング方針
コーディング・レビューの際に最低限確認する観点リストをまとめています。
実装担当・レビュアーはリストを確認しながら実装・レビューを行います。
リストは完成形ではなく、品質向上のために何を重視するかによって内容を議論し、絶えずブラッシュアップしています。
| 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 | 保守性 | 名前の一意性：クラスやグローバルスコープのメソッド、パラメタの名前が一意に特定できるものになっているか。 | リンク（作成中） |
参考: 品質特性
レビュー指摘リスト
プルリクエストでの指摘事項のうち、横展開すべき内容をリストにまとめ、エンジニア間で共有しています。
コーディング方針と併せて指摘リストを確認し、適宜項目を追加・更新することで、品質改善のための知見を積み上げています。
リンク: レビュー指摘リスト