毎日舞い込んでくるニュース、どうでも良いもの多数ですが、時々ブログネタになるようなものもあります。今日も一つ見つかりました。静的解析という初耳語でした。漢字の意味するところから、今迄机上デバッグと称していたものではないか？という察しがつきましたが、コードを実行せずにコードの品質、信頼性、および、セキュリティの検証を行う作業とのことなので、当たり！
デバッグには、仕様通りに動いているかを確認する工程がありますが、コンピュータ（当時はメインフレーム）を使って実際にプログラムを動かしてみるマシンデバッグと、プログラム（ソースコード）を目で追いながら頭で動かしてみる机上デバッグの2通りの方法があります。このうち、後者を静的解析と呼ぶようになったようですが、この記事には『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』と書いてありました。この記事を書いた記者は、本当にそう思っているのでしょうか？多分、実際にプログラミング、デバッグをしたことがなく、歴史も知らない方ではないかと思います。今日は、これを取り上げます。
OSの開発をしている時、デバッグ作業に明け暮れたことを思い出しますが、当時はマシンデバッグしないと検査に回すことができませんでした。要するに、基本的に机上デバックでは検査に送ることができないということです。時代はメインフレームからサーバ、パソコンに代わっても、これは同じはずで、ましてや『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できる』などと思う技術者はいないと思います。それはともかく、机上デバッグはいつやるのでしょう？
作った処理が機能するかをマシンデバッグする前に、プログラムコードを眺め、仕様通りの処理をしていることを何度も確認するという作業が机上デバッグです。入念な机上デバッグをしてからコンピュータ上で動かして機能通り動いているかを確認するマシンデバッグをするわけですが、一台数億、十数億する高価なメインフレームコンピュータを無駄に使わないということも、マシンデバッグ前に机上デバッグを入念にやりなさいというルールになっていた理由の一つになっていたと思います。決して 『静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』ということではありません。
この記事を書いた記者は、静的解析をすると早い段階でアプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を発見できるという根拠を検証したのでしょうか？コードを実行せずに机上でのデバッグ作業の方が精度高いチェックができるはずがありません。
机上デバッグを静的解析と言い換えても、コードを実行せずに机上での動きをチェックすることに違いはありません。以下は、OS開発時に行っていた仕様が決まった以降の開発プロセスです。
①仕様に基づいてコーディングする（プログラミングする）
②書いたコードを見直し、正確に仕様を反映しているかを机上で確認する
③標準コーディングなど、過去の経験を反映したコード規則に従っているかもチェックする
④関係者でレビューを実施する
⑤レビュー結果を反映する
⑥再度机上デバックを行う
⑦上長の承認を得る
⑧マシンデバッグを行う
⑨デバッグ結果を反映する
⑩上長の承認を得る
⑪検査に回す
これを見れば、『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』という主張に根本的な認識の違いがあることが分かるはずです。現場を知らない実務経験のない記者の書いた記事を専門誌の記事だからといって、鵜呑みにしては危険だということを理解されたと思います。あくまでも実機検証（マシンデバッグ）が必要で、机上デバッグを静的解析と言葉を変えても、その位置づけは変わらないことを理解しておくべきです。
今回は静的解析でしたが、この様な新しい言い方が出て来る昨今です。新語に出くわした場合、慌てることなくこの言葉は昔なんと言っていたのかを調べることを勧めます。正に温故知新です。
※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、本ブログ内容の無断流用を禁じます。