パッケージのカスタマイズを重ねていくと、 設計が当初の予想から外れていくことが多々ある。 その間に実装手法の慣習が足かせになって製造効率を落とす例を紹介したい。
たとえば以下のようなものを想定して欲しい。
システムの根幹を統括するファイルを読み書きする部分の処理を共通化している。 特殊な用途に用いるファイルを読み書きする必要が出てきたので、 それも根幹ファイルと同様な操作で読み書きできるようにした。 当初、特殊ファイルであると認識していたが、現在ではほぼ常用している。 そのような特殊ファイルから常用ファイルに変貌したファイルが結構ある。
今では多機能化に伴いかなりの種類のファイルを扱うようになっている。 また、常用化したファイルの中には、 他の常用ファイルと連携して機能するものも出てきている。
あるファイルは常用化されているが、ある条件下でしか使わないので、 以下のように実装されている。また、ほぼこの処理は変わらない。 処理を要する頻度は低い。
[プログラム開始]
[あるファイルを含むファイル群を開く]
[...関係ないもろもろの処理...]
if (こういうことをする場合なら) {
if (さらにこういうことをする場合なら) {
[あるファイルの読み込みあるいは書き込み(共通化されている)]
}
}
[...関係ないもろもろの処理...]
[あるファイルを含むファイル群を閉じる]
[プログラム終了]
[プログラム開始] [あるファイルの読み書き(条件 A の判断材料, 同 B)] [プログラム終了]
if (A) {
if (B) {
[ファイルを開く]
[読み書き処理]
[ファイルを閉じる]
}
}
当初使用するファイルが少なかったときには、 プログラムの始めで全て開いておいて列挙しておくというのはよい方法であったろう。 このプログラムがいじるファイルを一望できるからである。
しかし、今ではいじるファイルの数が多い。 また、共通化して隠しておけば把握する必要のないファイルもある。 こういう状態になった場合には列挙という方法はよろしくない。 ただでさえ多いファイルハンドルを開きっぱなしで引き回す上、 同じ処理を毎回各プログラムに組み込む必要がある。 各プログラムの処理の大半がこれらで埋まっている。
なぜ、こういった問題があるにもかかわらず実装を変えないか。
当初の実装になれた人が多いからである。 つまり、経験と記憶に頼った実装しかしないということである。 実例に沿って見た目が同じような実装になることも期待している。 そうすると、 見た目が違う部分がおかしいという判断材料ができると考えるわけである。 「共通化」 = 「見た目の統一」が考えの根底に流れている。
ここまで読み解いた上で再度問題を挙げよう。 先ほどの例でいうと、ファイルアクセスに関する処理部分は、 これまでに共通化したファイルアクセス処理と同じような実装にしなければならない。 同じようにすることで発生するそのファイル独自の例外判断は、 毎回ファイルアクセスを呼び出す親プログラムがしなければならない。 これでは、「共通化」した部分はきれいにまとまるが、 それを呼び出す側はそのきれいな部分を読み出すために、 どろどろした処理を呼び出すたびにする羽目になる。 これでは、省力化にならないし、どろどろした部分を共通部分から追い出すことで、 一番危ない処理を毎回実装させることになり、安全性に欠ける。
実はどうしようもない。あえて善処しようとするのであれば、 地道に慣習を変えていくべく影響力を養うしかない。あるいは、 大体の場合、そのような慣習の生き字引が存在して教育しているはずなので、 その方に引退していただくのも手であろう。 効率のよい実装を実践すること自体は別にたいした手間ではない。 問題はそれを阻む慣習、つまりは経験と記憶に頼った実装手法、 ひいてはその実践者の影響力なのである。