サブルーチン禁止！？

あるプロジェクトで、似たような動作をする複数のプログラムを作らなければならなかったとします。そういうときは、似ている部分や同じ部分をサブルーチンにして、ライブラリか何かにしますよね。ところが、サブルーチン化が禁止されているプロジェクトがあるという話をときどき耳にします。そういうプロジェクトでは次のように作業を進めます。

1. まず、似ているプログラムの中から１つを選んで作る。
2. これを丸ごとコピーする
3. コピーを雛形として別のプログラムに書き換える（違う部分だけ修正する）

• メリット１
  １つのプログラムに対して行った修正がほかのプログラムに波及しない
• メリット２
  １つのプログラムに対して行った修正をほかのプログラムにも同様に適用するのが楽（形が似ているから）

私には、まったく意味が分かりません・・・。

そもそもサブルーチン化するのは、同じ部分を１つにまとめておくためです。そうすることによって、全部のプログラムで必要になった修正を１度で済ませることができるわけです。あったり前ですよねぇ。

では、先ほどのメリット１はどういう意味でしょう？たぶんプログラムを修正するときにこれまでの機能を保証するかどうかという点が問題なのでしょう。いままでと互換性のない修正を行うときに、その修正がほかのプログラムに波及するのはまずいというわけです。うーん、何か変ですよね。

サブルーチンにしておけば、自動的に全部のプログラムに修正結果が反映されるのが良い点だったはずです。ですから、リリース後のサブルーチンに何かバグが見つかった場合の修正が簡単になります。そのかわり、一度リリースされたサブルーチンの機能を変更することはできません（拡張は可能ですが）。機能変更が必要な場合は、既存のものを残しつつ、新しいルーチンを用意することになります。このように、今までの機能を保証しつつ修正する場合と、機能自体を変える場合の違いを明確にする必要があります。この違いを理解していないと、上記のメリット１のようなおかしなことになりだすのでしょう。

メリット２についてはもう言いようがないですね。サブルーチンにしておいたほうが「もっと楽」ですから。

上記の誤った作業方針の変わりに、訂正版を作ってみました。

1. 同じ部分はサブルーチン化する。
2. 似ている部分もサブルーチン化する。このとき、プログラムごとに異なる値はパラメータとする。プログラムごとに異なるアルゴリズムは関数ポインタ型のパラメータとする。
3. 似ている部分をコピー＆ペーストするような作り方は禁止する

• メリット１：
  １つのプログラムに対して行った修正が、自動的にほかのプログラムにも適用される
• メリット２：
  １つのプログラムに対して行った修正をほかのプログラムに波及させたくないなら、単純に新しいサブルーチンを作れば良い

さてと、上で述べたようなことは、わかっている人にとってはアクビが出るほど当たり前のことですね。それがどうしてサブルーチン化禁止などというばかげた方針になってしまうのでしょう？何か事情というか、そうならざるを得なかった理由があるのかもしれません。

推測ですが、たぶん品質管理上の問題ではないかと思います。たとえばプログラムＡが呼び出しているサブルーチンにバグがあって、これを修正したとします。そのとき同じサブルーチンをプログラムＢも使っていたとします。サブルーチンの修正を正しく行えば問題ありません。しかしもし修正を間違ったらその影響が関係ないはずのプログラムＢにも及ぶわけです。あるいは、これは本当にばかげた話ですが、プログラムＢの機能がサブルーチンのバグに依存していたかもしれません（その場合は、プログラムＡにとってのバグ修正がプログラムＢにとっては機能変更ということになってしまいます。うあぁぁっ！！！）。

だとすると、サブルーチンを使うなと言いたくなる管理者の気持ちも理解できるような気がします。コストをかけて質の高い人材を育成するよりも、一人一人の質が低いことを前提として人材の量を活かした方が楽だったのでしょう。