ソースコードを見るより動かしたほうが手っ取り早いとき

本記事はわたしの過去のしょうもない失敗談を題材に、ソフトウェアの挙動を確かめたいときに、初手を何をするかを考えるきっかけとなれば嬉しいなと思って書きました。話を簡単にするために調査方法を「ソースコード調査」「動作確認」の2つだけ書いていますが、実際にはもっと多くの手段を使える場合があります。

むかしむかし、仕事で先輩から「LinuxカーネルのAという機能が、Bという起動オプションを付けたときに失敗するという報告がupstreamであったらしいんだけど、うちのサーバでも起きうるかどうか確認しておいて」と言われました。わたしはLinuxカーネルのソースコードを見て、そういうケースがあるかどうか確認していました。ハードウェア依存のコードが多かったため、確認が大変でした。

わたしが苦戦しているのを見て、先輩が声をかけて状況を聞いてくれました。状況を説明をし終えたわたしへの先輩の「それ、コード読む前にとりあえず動かしたほうが早くない…？」という言葉を今でもよく覚えています。「うちのサーバ」は実機がありましたし、A機能を動かすのも、LinuxをBという起動オプションを付けてLinuxを起動するのも別に難しいことではないのでやってみたところ、あっさりと問題が再現して、タスクは完了しました。

当たり前のように聞こえるかもしれませんが、当時のわたしはまったく思いつきませんでした。おそらくは「ソフトウェアの挙動を確かめるためにはソースを読むべきである」という思いに囚われていたのだと思います。当時コードを読んだことは今でもわたしの血肉となっていますが、それはまた別の話です。業務として与えられたタスクを迅速に終わらせるという観点では、最初からソースコード読解という手段に飛びついたのは、まずい判断でした。少なくとも「こういう場合はどういう方法でタスクを進めればよいか」と考えるべきだったでしょう。

話を戻すと、以下の条件を両方満たす場合は初手で動作確認するのは非常に効率がよい進め方だと考えます。

• a. ある事象が起こりうるかどうかの確認
• b. 動作確認が容易

なぜなら、事象が起きたらそれで確認は終わりだからです。起きなければ起きないで、その後にソースコードを読むなど、別の手段をとればいいのです。

(a)を満たさない場合は、たとえば確認すべきことが「必ず起きるか」「必ず起きないか」だった場合は、動作確認によって事象が起きた or 起きなかったというだけでは証拠としては弱いです。なぜなら、実機で動かしたときとは異なる状況で事象が起きる or 起きないケースがありうるからです。この場合は初手で動作確認しようとしまいと、結局ソースコード調査(とその後のさらなる実機確認)が必要でしょう。(b)を満たさない場合は、たとえば実機が手元にないという事態が考えられます。このような場合は機材の手配を進めながらソースコード調査をするという手段が考えられます。

結局のところはケースバイケースとなってしまうのですが、みなさんが似たようなケースに遭遇したときに「そういえばあんな記事あったな」と思い出して、効率的な選択をする助けになることを願って、終わります。