基本的エラー

先日、仕事で十六進数のメモリダンプをトレースしながら、テストプログラムを作成し、プログラム検証作業を行った。プログラムを改変した場合、予期しない動作があっては困るので、（というか工場を１時間でも止めたら大問題になるし）、けっこう慎重に作業を行う。トイプログラム（オモチャ）なら、スクラッチ＆ビルドでいいのだが、何せ相手は20年前の似非Unixなので、実行環境は遅いわシェルはへぼいわで作業が大変だった。LinuxについてるBashならTabキーとかで前回入力した文字列が出てくるのだが、そういうのもない。ちょっと環境が悪くなると作業効率ががた落ちになる。やっぱり人間工学は大事だな、と思った瞬間でもあった。

さて、ちゃんとプログラムをテストするぞ、というときになって、期待した十六進数が出てこないということになってきた。メモリマップだから、グローバル変数の先頭アドレスを基点として、+x分だけアドレスを進めたらちゃんとそこにaの値が入っている、といった確認作業をするのだが、ケースによってはちゃんと値が出てこないことがあって、困ってしまった。いくら不慣れなFortranだからといって、さすがにプログラム自体は間違ってないはずであった。

どうやら予期せぬ値が出てきてしまうのは、テストケースの仕様書（これはほかの人が書いた）がそもそも間違っている、といった具合だった。Fortranの場合（Cでも似たようなものなんだが）サブルーチンの引数はスタックに詰まっている。ようするに引数の名前はどうでもよくても、順番が大事である。関数の呼び出し元の実引数と、サブルーチン側の仮引数の名前は一致しなくてもよいが、型（整数型と浮動小数点型の違いとか）の一致と引数の順番は絶対に間違ってはいけない。もし間違うとデータを壊しながら、プログラムが動いてしまう。ようするに暴走状態になる。その間違って書かれた仕様書に基づいてプログラムの検証作業を行っていたもんだから、間違って出てくるのは当然である。

人間の書いたものだから間違っているのは当然として、今回のこの引数の個数が間違っていた、というのはもう致命的なエラーである。たとえて言うなら大学一年生（高校でも習うけど）2x2の行列の乗算が間違っていました、ぐらいのミスである。もう基本的すぎて、お話しにならなくなってしまった。いちいち他人の書いた（それも数十ページの）文章を検証しながら、次の作業を進めていくというのは、無駄な作業以外の何者でもない。複雑なものは間違えそうだな、と思って用心するが、簡単すぎなものは間違えようが無い、という先入観があった。

今回の一件は、ダーティリード（正しくないデータの読み取り）によって、けっこうな時間のロスを生み出してしまったということになる。仕事って、単発的なものだけのは当然ほとんどなくて、自分が行った仕事は当然次の人に行くし、また逆も同じである。時には、多少間違ってもいい文章というのはあるけれども、今回のは絶対に間違っちゃいけない文章で、基本的過ぎる間違いが起こってしまったということという結論になってしまった。今回の件で、仕事というのは、連続的なデータの流れであるといのが身にしみた。私が作業するときは他人に迷惑をかけないようにしようと思った。