通常、初回リリースの時点では、ソースコードは現実のビジネスルールを反映したものになっています。
（なっているべきです）
そして、障害対応や保守開発でソースコードを修正する際は、将来の保守性を犠牲にしないために、ビジネスルールに沿った修正を行うべきです。
ビジネスルールに沿わない修正を行ってしまうと、ソースコードの解読が困難になったり、後々新たなバグが生まれやすくなったりします。
例えば、麺・スープが入った器に具材を入れて料理を完成させるシステムを開発しているとします。
取り扱う料理は以下の通りとします。
|
1 2 3 4 |
・商品名：しょうゆラーメン 分類：ラーメン ・商品名：みそラーメン 分類：ラーメン ・商品名：きつねうどん 分類：うどん ・商品名：とろろうどん 分類：うどん |
また、
|
1 2 |
・分類がラーメンの場合はこしょうを入れる ・分類がうどんの場合は七味を入れる |
という処理が存在するとします。
ある日、「みそラーメンにはこしょうではなく七味を入れたい」という要望が入り、システムを改修するとします。
ここで、「みそラーメンの分類をうどんにする」という修正を行うべきではありません。
この修正でも要望に応えることはできますが、ビジネスルール上はみそラーメンはうどんに分類するべきではないので、このような修正を行うと保守性が低下します。
システムの実装を良く知らない人がソースコードを読んだ場合、「みそラーメンはラーメンである」という予想を立ててソースコードを読むことになるので、「実装上はみそラーメンはうどんである」となっていると、ソースコードの読解を誤るリスクが高まります。
また、将来、「うどんには揚げ玉を入れたい（ラーメンには入れたくない）」という要望が入り、「分類がうどんの場合は揚げ玉を入れる」という処理を追加してしまうと、みそラーメンにも揚げ玉が入るというバグを埋め込んでしまいます。
ここは、処理を以下のように修正し、ビジネスルールを崩さないようにすることが望ましいです。
|
1 2 |
・商品名がしょうゆラーメンの場合はこしょうを入れる ・商品名がみそラーメンorきつねうどんorとろろうどんの場合は七味を入れる |
いかがでしたでしょうか。
プログラムの改修は直せば良いというものではなく、その後の保守のしやすさも考えて直す必要があります。
今回は、実務で目にしたケースを元に、記事を書いてみました。