プログラムの静的検証の各種方法

プログラミングをしていて、実際書いたプログラムを動かしてみて確認する動的な検証は当然皆さん行っていると思います。と同時に、プログラムを走らせるのではなく、ソースコード自体を何らかの方法で検証する静的検証も、皆さん行っていると思います。

というのは、動的検証で全てを網羅するのは大変すぎるからですね。テスト駆動開発で100%のパターンを網羅するようにコードを書けばもちろん全てを網羅したと言えるかもしれませんが、現実的に考えると、あらゆる例外処理を含めてテスト駆動開発にするのは時間的にも労力的にもキツイです。ということで、当たり前のことを確認したようですが静的検証も大事なので、色々静的検証の方法を述べてみます。（あ、ちなみに動的検証とか静的検証って呼び方は僕が勝手にそう呼んでるだけです。）

最も基礎的で単純な静的検証は、単にソースコードを直接自分の目で読むことです。これは作業中に当たり前のように行っていると思いますが、例えば改めて１つのコードを上から下まで目を通すことも静的検証の１つですよね。

あるいは、何らかの変更を行った際、その変更に関連する文字列でソースコードを検索してみるのもいいでしょう。変数名、クラス名、メソッド名、値としての文字列などなど、パターンとしては色いろあると思いますが、やることは同じで、単に検索してヒット箇所の前後を読み、修正の矛盾や抜け漏れがないか確認するってことです。単一のファイル内だけでなく、場合によってはソースコード全体を検索することも必要です。

GitやSubversionなどの何らかのバージョン管理システムは当然お使いだと思います。直前のバージョンと現在の比較が最もよくやりますね。コミット直前には必ず直前のバージョンとの全ての差分に目を通すようにしています。ここでミスを発見することも多いですね。

差分といえば、例えば別の似たコードを元にして新しいコードを書いた場合には、書き終えた段階で改めて元にしたコードとの差分を取ることも有効な検証手段です。あるいは元にしたわけでなくても、用途がよく似たコードと比較してみてもいいですね。その場合には差分を取るというよりは、ざっと眺めてみてロジックの流れを比較してみるといいと思います。

ちなみに複数人で行うソースコードのレビューについてですが、僕自身がレビューを行う職場の経験が一度もなく、僕個人としてもレビューにそこまで有用性を感じていないこともあって、ここで何かを語ることは出来ません。率直に言うと、人命に関わるようなクリティカルなプログラムの作成でもなければ、レビューにこだわる必要はないと思ってます。

こんな感じですかね。プログラムの静的検証はソフトウェアエンジニアの腕の見せどころって気もするので、色々工夫のしがいがありますね。もし良い方法をご存知ならぜひ教えてください。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。