今回のテーマは「サボリ」です。プログラミングにおいては、延々とプログラムを書くことはと んでもない悪行です。毎日残業して、延々とプログラムを書き、その書いてしまったプログラムを、 またまたえんえんとデバッグしているのは、はた目にはまじめに仕事をしているように見えます。 ソフトウェアについてよく知らない人には、会社にもっとも献身的な技術者に見えます。こういう 努力をしていると給与が上がったりする会社も結構あるようです。

でも、このような努力は、普通はソフトウェアを泥沼に引きずり込んでいる作業です。ソースリ ストが長くなるほど、全体が見えにくくなり、取扱いの困難なソフトになっていきます。内容の理 解度は、長さの２乗、３乗あるいはそれ以上のペースで悪くなります。短くできるものは短く書き ましょう。キーボードを押すのも面倒だなと思いながらプログラミングしていても長くなって困る のですから、「がんがん書くぞ！」なんて頑張られたら困ってしまうのです。消す手間がかかるで はありませんか。

今回のプログラマは、とくに力まかせにプログラムを書いていますが、ずいぶん短く書き直せた り、何も書かなくてもよかったことが分かりました。いや、それ以上に、書かない方が標準で提供 されている機能が生かせて、よりプログラム品質が向上します。ウィンドシステムの機能をそのま ま使っていると、自分で努力しなくても、ウィンドシステムの機能が向上すると、作ったプログラ ムの機能が勝手に向上してしまうということがあります。

ウィンドがバージョンアップし機能強化されたとしましょう。さあ、プログラムの方も手を入れ て、バージョンアップに合わせなくてはなりません。仕事を発注する側には多額の費用が発生しま す。受注する側は仕事がやってくるのでうれしいともいえるのですが、いっぱいコーディングして いると、いっぱい変更する羽目になるので本当に作業がいっぱいあり、変更してはデバッグ、テス トと過酷な労働が続きます。

もしコーディングしていなかったら、どういうことになるでしょうか。バージョンアップしても、 コーディングせず、本来の機能の組み合わせのままにしていると、プログラムの変更がまったく不 用なことが多いものです。何の作業も発生しないのですから、デバッグ、テストもありません。ま あ、コンパイル、リンクし、動作確認する程度で済んでしまいます。

では、バージョンアップ費用を考えてみましょう。ソフトが時代遅れにならないようにするため プログラムの書換を発注してくるでしょう。でも、ちゃんとサボっていれば受注側の実費はわずか ですみます。「今回のバージョンアップは特別に勉強させていただきます」といって発注側を喜ば せておいて、実はいっぱい儲けてしまうことができるのです。両者満足できる結果になり、めでた し、めでたしといえますね。もちろん、期間的にも短期にできて両者満足でしょう。あまりにも早 くできてしまうので、バレないように注意しなければなりません。バレると値切られてしまいます からね。