  |
この業務の処理手順は、数年ごとに多少の変更が入り、今回も、その対応が彼の仕事だった。
彼が、前任者が作ったソースを開いてみると、それはごく単純に業務手順書をプログラムに置き換えたようなもので、
固定値がそのまま文中に記述(マジックナンバー)されていたり、お世辞にも格好いいとは言えないものだった。
彼は考えた。「数年ごとに変更があるのがわかってるんだから、もっと変更に柔軟に対応できるようにしておくべきだ！」
そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。
プログラムは完成し、彼は運用者と次の後任者に自信満々で言った。
「今後は、業務手順に変更があっても、プログラムをビルドし直す必要はありませんよ！設定ファイルで設定を変えるだけでOKです！」
さて、その数年後、実際に業務手順に変更があった。
運用者は設定ファイルを変更したが、うまく正しい結果が出ない。
バグが出てしまったか？と、後任者はソースを開いてみて愕然とした。
そこにあったのは、様々な設定項目に対応するための、膨大なif文ブロックの塊だった。
ソースの大半は、「将来的にこの設定が変更されたら」に対応するための、使われていない行。
設定の組み合わせパターンは膨大になり、全ての分岐カバーテストはされてはいなかったのだ。
再び、現在の業務手順だけを、そのまんまプログラムに落とし込んでいった。
確かにこの方法では、業務手順変更がある度に、プログラムを直してビルドする必要があるが、
そもそもプログラム言語というものは、「手順を明快に記述できる」ように発達してきたものなので、
手順書そのもののようなその新しいプログラムは、誰でも簡単に理解して修正できるものになっていた。
【教訓】将来の変更に対応するための「汎用性」「柔軟性」を上げようとするのは間違っていないが、
実際に来るかもわからない将来に備えてプログラムを複雑化するのは間違い。
たぶんそうなんだろうけど、もうちょっと具体的に書いてくれたら、もっと共感しやすい気がする (でも詳しく書きすぎるわけにもいかないだろうとも思う)
そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。 新規外部ファイル作成するための作業内容 外部ファイル名...
6
