二重管理は悪である

同じ性質のデータを無計画に複数個所で管理することは、ほぼ間違いなく悪である。

まれにJavadocをリポジトリに突っ込む奴がいる。ソースファイルに書き込まれているJavadocコメントから自動生成されるファイルをバージョン管理して何がうれしいのか。これでは、ソース中のJavadocコメントを修正するたびに、Javadoc側もcommitしなおさなければならない。

プロパティファイルを、native2ascii前後両方の形式で管理するなど愚の骨頂。これも同じで、片方を変更したらもう片方も直してcommitしなければならない。無駄であるばかりか、どちらを最新のデータとして信頼してよいか判断がつかなくなるので有害ですらある。

あちこちで使われる機能を適切に関数・メソッド化せずに、ソースコードをコピー＆ペーストして増殖させるのも邪悪な行為である。その部分でバグが発生した場合、同じ修正を何箇所も行わねばならず、そしてこういう場合は必ず修正漏れがでる。

バージョン管理された環境で、使わなくなったコードをソースファイル中にコメントアウトしておくのも二重化である。リポジトリ上に修正履歴が残っている以上そんなことをする必要は無い。むしろ、可読性を落とす分、害悪である。

へたくそなコメントも二重化を引き起こす。

// /etc/ap/conf/ap.confを読み込む。
file.load(AP_CONF);

なんのために固定値使ってファイルパスを変更できるようにしているのかわからない。パスが変更になったらコメントも書き直せというのだろうか。

微妙に変名したファイル・ディレクトリを大量に生成する行為はもはや犯罪的と言ってよい。「設計書」「設計書_最新」「設計書_20050823最新」「設計書idesaku修正版」のどれを正式版として扱ってよいのかどうやって判断するのだ？

やってよい二重化もある。例えば、システムの可用性を向上させるためにHDDやルータといったハードウェアを複数稼動させておく、というのは良い手である。要求仕様書、外部設計書、内部設計書・・・といった各種設計書は同じアプリケーションを説明したもの、という意味で二重・三重管理になっているわけだが、視点が異なるので全て同時に存在して管理しても良い。UMLの各種ダイアグラムもこれと同様。また、まれではあるが、状況によっては二重化したほうが飛躍的に作業効率が上がることもあるので、あえてリスクを負うこともある。

つまり、ちゃんと目的を持って、リスクを把握した上で二重化するという判断を下すのはかまわない。しかし、考え無しになんとなく二重化してはいけない。二重化しそうになったら、まずその判断が本当に正しいのかよくよく検討しなければならない。大抵の場合、その判断は間違っている。

なんでこんなことを書いているのかというと、当然そういうことをやっている環境に出くわしたからである。上記した二重化のなかの３つが該当する。いかに開発環境を理解できていないか、考え無しに開発しているか感じ取れる。CVSの管理下にある以上、なにをやってもいつでも変更前の状態に戻せるので、容赦なく修正をかけている真っ最中である。知恵ある人間は、こんな人に迷惑をかけるような開発を行ってはいけない。