ソースコードレビューの観点

企業でソフトウェア開発者として働くと、他のメンバーが書いたソースコードをレビューする機会が多々ある。
あなたがレビュアーとして漏れなく指摘をするためには、網羅的に観点を設けて臨むことが重要だ。
そこで、以下ではソースコードレビューにおける7つの観点について説明する。

1. 処理の流れが自然であるか
まず、処理の大筋の流れが自然であるかどうかを確認しよう。
例えば、3つ数える処理の流れとして「カウンターをインクリメント。これを3回繰り返して3」これは自然だろう。
しかし「初めに2足した後、インクリメントを2回繰り返し、最後に1引いて3」このような処理になっていたら注意が必要だ。
結果が同じ値になるとしても、過程の処理が不自然である場合、思わぬバグの温床となる。
将来的な保守性を考えても、処理の流れはできるだけ自然にしておく必要がある。

2. エラー処理は正しく行われているか
エラー処理はバグの温床だ。特に、以下について注意する必要がある。
・全てのエラーを想定および対処できているか
使用した関数やシステムコールが返しうる全てのエラー種別について仕様書を確認し、また対処しているか。
OSの異常、外部割込み、またはハードウェア的な突発的故障などで予期せぬエラーが発生した場合にどうなるか。
・エラーが発生した場合にリソースの回収漏れがないか
処理の途中でエラーが発生した場合に、リソースの回収処理をスキップしてしまうようなことがないか。
状態遷移が不完全なまま放置されるようなことがないか。

3. データの生成と消滅は正しいか
データについては生成と消滅が行われる場所を把握することが重要だ。
生成から消滅までの期間、すなわちデータの保持期間が最適か（長すぎないか、短すぎないか）を確認しよう。
このことは、プログラムの性能やメモリ使用量にも影響するし、メモリリークがないことの確認にもつながる。

4. モジュール化されているか
処理が適切な単位でモジュール化されているかどうかも、保守性や可読性の面で大切だ。
基本的には小さな単位でモジュール化し、将来的に再利用しやすい形で実装しておくことが望ましい。
もし複数個所へのコードコピーがあると、将来修正する際にそれら全ての箇所を修正する必要が生じてしまうし、
モジュール化されていない処理は再利用が難しいため、将来的に同じ処理が重複して生産される無駄を生じる可能性がある。

5. 既存の処理に影響はないか
新規作成した処理自体が正しくても、その処理を間接的に参照する既存処理に悪影響を及ぼしてしまう可能性がある。
例えば、新規作成した処理を呼んでいる上の階層の処理を、さらに呼んでいる上の処理。
階層をさかのぼって、全ての間接呼び出し箇所に対する影響を調べる必要がある。
また、大域変数や状態遷移などプログラム全体に影響を与える処理を新たに作りこんだ場合、それらの影響も調べる必要がある。

6. 関数や変数の名前
使用した英語の意味や綴りが合っているか。保守しやすいか。
NewFunction()という名前を付けるのなら、将来的にその処理は古くなるのだということを理解しておく必要がある。

7. コードの書き方がプロジェクトの規約に沿っているか
関数や変数の名前の一文字目を大文字にする、動詞→目的語の順で名付ける、などの命名規約。
変数の定義の仕方。インデントやカッコの付け方。for文やif文における改行の仕方。

ソースコードレビューは、プログラマが書いたコードの不具合を見つける最初のチャンスであるし、
保守性に影響のある観点、例えばモジュール化や関数の命名規約については、テストでは発見できない。
その重要性を認識し、きっちり観点を網羅したレビューを行ってほしい。