ソースコード確認

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

コーディング方針

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

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保守性名前の一意性:クラスやグローバルスコープのメソッド、パラメタの名前が一意に特定できるものになっているか。リンク(作成中)

参考: 品質特性

レビュー指摘リスト

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

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