(8)面白いことは気のせいではなかった

 吾輩はシステムエンジニアーである。プログラムは人間の手によって書かれるものである。

 しかし、朝から感傷に浸っている場合ではない。このプロジェクトは火を噴いているのだったと自分に言い聞かせ、焦る気持ちを抑えながら、駆け足気味にデスクに戻った。とはいえ、吾輩の担当はバカデカい七画面から、「大きめの四画面」に減ったわけなのだから、いくばくかの安堵のようなものもあったが、それはすぐに間違いだったと思い知る。「3Aの大きめの四画面」というのは、3Aの3から6のことであるが、これらは、3A本体と、3Aの1と2から呼び出されるが、渡されるパラメーターが多く、それらは複雑な条件で結びついている。つまり、「小さめの三画面」自体のテストをしなくてもよくなったのは事実だが、それらから決別できたわけではなく、書きかけのコードを追って、仕様の把握をしなければならないというのは変わらないのだと認識した。同時に、ババをつかまされたというやるせない気持ちが吾輩を襲う。念のためと、昨晩のプロパーさんの成果を期待したが、リポジトリーのソースファイルの日付は一秒たりとも変わっていない。たぶん、この画面、みんな触りたがらないんだろう。吾輩も「話と違う」とか言ってみたい。

 さて「小さめの三画面」について、最初のソースファイルをクリックし、ホイールを転がす。そして、次のファイルをクリックし、またホイールを転がす。たまには戻したりもする。そうやって前後関係を読んでいく。少し面白いことに気がついて、次のファイルをクリックし、今度は、ホイールを下に転がすだけになる。ほとんどのファイルを下向きにホイールを転がし終わったあとに、面白いことが気のせいではないとわかった。

 里見さんのコードは変数の局所宣言がほとんどないのと、ループ処理がすべて後判断になっている。ループ処理というのは、繰り返しの処理である。たとえば、ある変数aに1を最初に格納しておき、aを1づつ足しながら処理を行い、aが一定回数になったら、繰り返しの部分を抜けるというものだが、里見さんのコードは、そのaが一定回数になったかどうかの判断が、繰り返し部分の後ろにある。べつに前判断でもいいところを、後判断にこだわって、処理の見通しが悪くなっているところも散見される。
 変数の局所宣言というのは、さっきの変数aについては、aという箱を使いますよ、と「宣言」しなければaは使えない。大昔のコンパイラーは、変数の宣言は、すべての処理よりも前に書かなければならなかったが、最近の言語は、処理の最中に変数宣言があってもよい。これを変数の局所化というのだが、彼女のコードにはそれがなくて、すべての変数宣言が、すべての処理の前にあって、見通しが悪くて仕方がない。この現場で使っているMという言語は局所変数はサポートしていないのか。というか、コーディング規約はあるのか、そして、このコードは誰かレビューしたのか。

 吉沢さんにコーディング規約の場所を教えてもらい確認してみたが、ループ処理を前判断、後判断にするかの指針について触れられていないのはともかくとして、変数の局所化については触れられていなかった。なるほど、規約違反ではないのか。

「吉沢さん、この現場ってコードレビューってしてます?」
「前はやってましたが、フレームワークが変わってからはものづくり優先ですね。」そうか、では。
「M言語って、変数の局所化ってサポートしてますよね?」
吾輩はM言語は初めてである。
「ループのときに、変数宣言するやつですよね。ほとんどのサンプルコードがそうなってますから、普通に書いてますよ。」
拍子抜けである。

 さて、里見さんは昼から出社すると、レインボーさんの島からもれ聞こえてきた。ここぞと、彼女が守られていたと言っていた山中さんの反応を見てみる。
「里見さん、昼から来るみたいですね。あっちで言ってます。」
「あ、そうですか。集中していて聞こえませんでした。」
「心配じゃないですか?」
「いや、別に。」
「守ってあげていたのに?」
「それは彼女が勝手にそう思っているだけです。」
 やれやれ、そうかい。

「ところで、里見さんのコード、ちょっとアレですね。」
「いや、だいぶアレだと思いますよ。」
 知ってるのか!