システム開発アンチパターン～旧バージョンのロジックを残すな！

『旧バージョンのロジックを残す』とはどういう事か、まあ大体想像つくと思いますが、一応説明させて頂きますと『新ロジックの側にコメント化して残す』という事です。
僕の会社の例では、以下に示すような定数CONST_Aの値を変更する場合（言語はJava）、

従来のロジックはコメント化し、その上に修正ID・修正者・修正日付等の情報をこれまたコメントで追加し、旧ロジックの下に新ロジックを追加します。


修正前後の差分がソースコードだけで確認できるので一見良さ気です。そのソースコードの修正が絶対に1回までしか発生しないのであれば、これでも良いでしょう。でも現実はそんな訳ありません。長い間メンテして何回も修正されていくと、以下のようにカオス化し、ソースコードが見にくく（醜く）なっていきます。

例ではただの定数宣言部でしたが、計算等を行っているような業務ロジック部分が例のような状態になっていたらもう最悪です。現バージョンのコードが旧ロジックの中に埋もれてしまい、ロジックの流れを追ったりするのに非常に邪魔になります。今年夏に担当した、当エントリを書くきっかけとなったシステムでは、ソースの総行数7000行中旧ロジック3000行という超大作がありましたよ。そのままだと現バージョンのロジック追うのが大変だったので、コメント行の色を深紅のバラ色に変更して追いましたよ。そしたら目がチカチカして堪りませんでしたよ。

今時、Subversion等のバージョン管理ツールという非常に便利な無償ツール使えば、ソースの修正履歴・差分の確認行えるので、旧ロジックは残さず排除すべきです。さらにRedmine等のプロジェクト管理ツール（厳密にはBTS）とバージョン管理ツール連携させれば、修正要件との紐付けもバッチリです。

ちなみに、そのシステムはバージョン管理ツール導入してたんですけどね。2007年にCVSを（遅っ！しかもSVNじゃないのかよ！）。弊害しか生み出さないこんな運用を、何で未だに行っているのか分からない（実際、担当したプログラマは全員が「間違ってる！」と言ってたし）。恐らく『修正IDでgrepして修正箇所を一括確認したい』要するに『楽して確認したい』というのが理由ではないかと僕は予想してました。

4年以上もこんな運用してきて誰も改善してこなかったのが非常に悲しい。いや、改善提案してきたけど通らなかっただけか？とにかく、僕は上司に改善を申し入れました。すると以下のの答えが返ってきました。
「ピンポイントでそのロジックの修正者、修正日付、修正理由を調べたい」
つまり『ソースコードからの修正要件の逆引きがしたい』という事のようです。うーん、結局『楽して確認したい』って事ですよね。ソースコード見るだけで修正要件確認したいと。一々修正台帳やCVSのコミットログからトレースしたくねえよと。そりゃそちら側としては楽で良いかもしれませんが、その為だけにソースコードを醜くし、修正難易度を上げ、それにより修正工数・デグレ発生度アップし、品質低下させるなんて、馬鹿げている。そもそも『ソースコードからの逆引き』なんて、多分バグった時の責任追及時に行うのでしょうけど、そんな機会しょっちゅうあるもんなんですかね？

やっぱり結局は『修正IDでgrepして一括確認』したいのが本音のような気がする。でもこのやり方では修正コメントに修正ID含めるの忘れた場合、確認漏れが発生してしまいます。ていうか実際にありました。しかもその修正が原因でデグレ発生してやがんの･･･。結局、修正箇所の確認は一つ一つバージョン比較して行うしかないと思います。そして確認の際は、前述の様にデグレが発生していないかも確認するため、修正した部分だけでなくメソッド単位で確認すべきだと僕は思います。

ただ、このシステムの場合メソッドの行数が数百～千行だという･･･