こんにちは！ぺんしるです。
今日はこんな悩みに答えていきたいと思います。
ソースコードレビューの観点を教えて
エンジニアとして成長してくると、後輩のソースコードレビューを実施することがあります。その時に、正しくソースコードレビューをしないと後輩が成長しないだけでなく、プロジェクトに負の遺産とも呼べるソースコードが含まれることになります。
また、プロジェクトが小規模なら良いですが、大規模になると色々な開発者がプロジェクトに参画することになります。エンジニアに対して特に指示をしなければ、エンジニアは好き勝手な実装をおこないます。ある程度の経験があるエンジニアであれば、それなりのコードを書いてくれるけど、経験が浅いエンジニアは酷い書き方をする人もいて、唖然とすることがあります。
このような事態を防ぐために、今日はソースコードレビューをする際の観点まとめを記載しますね。
コードレビューの観点一覧
それでは、コードレビューの観点を一覧で記載します。
- コーディング規約に沿って記載しているか。JavaScriptのコーディング規約については、以下の記事にしているので参考にしてくださいね。
- 日本語として「てにおは等」は適切であるか
- 正常処理の仕様が網羅されているか
- 排他制御・デッドロック・トランザクション制御は適切であるか
- 1メソッドが長くないか
- メソッドの戻り値は適切に処理しているか
- 重複処理をメソッド化できないか
- 異常系処理のふるまいは適切であるか
- 例外処理は適切であるか
- コメントは適切に記載されているか
- セキュリティ面（SQLインジェクション等）が発生しないか
- ログの出力は適切であるか
対応可否
ソースコードレビューが終わったら、対応可否を決めましょう。
ぺんしるの場合は、以下のような基準で実施可否を決めることが多いです。
| 判断内容 | 備考 |
| 実施必須 | そのソースコードのままでは明らかに不具合を生む可能性があるようなコード、または著しく保守性を下げるようなソースコードは必ず修正しましょう。 |
| 可能であれば実施 | 時間に余裕があれば実施したほうがよい指摘は修正しましょう。 時間や修正により影響範囲との兼ね合いで実施可否を決めましょう。 |
| 実施不要 | 修正したほうがよいけど、実害がない指摘は修正不要です。 「変数名がいけてない」とか「無駄な処理がある」などがこれに該当します。 |
その他・コツ
ソースコードレビューを実施すると、レビューワーとレビューイーの間で多くの場合コンフリクトが発生します。それを避けるために、チームリーダ等の第三者にもソースコードレビューを同席してもらうことが効果的です。
最後に
いかがでしたか？
もう１つ大事なことがあります。それは、ソースコードレビュー結果で不適切な構文があった場合に、「なぜそのソースコードではダメなのか」をレビューイーにきちんと説明することです。
これをしないと、レビューワーとレビューイーの間で衝突が生まれる可能性があるので、指摘するときはちゃんと理由を説明してあげましょう。
もう１つ大事なことは、レビュー時に「自分のことは棚上げ」することです。レビューイーからすると「あんたはちゃんとしたソースコード書けるの？」と思われることがあると思います。それをふせぐため、事前に、「自分のことは棚上げします」と宣言しておけば、そのような事態を回避することができます。
ソースコードレビューをするとレビューイーの開発者としてレベルアップが早くなるので、後輩育成の観点でも是非とも実施してください。
より良いプログラムを書くには、以下の本が参考になりますよ。
不明点があれば、遠慮なくこちら、またはこちら（匿名での質問ができます）からご質問くださいね。
ではでは。
