「 DON'TDOIT」、「BAD PRACTICE！」で私に忠告し始める前に、および「適切なソースコード管理の使用方法を学ぶ」、最初に私に聞いてください。古いコードをコメントアウトして永久にそこに残すという慣習は非常に悪いことを十分に認識しており、私はそのような慣習を自分で嫌っています。
しかし、これが私が置かれている状況です。数か月前、私はソフトウェア開発者として会社に加わりました。私は最近入社する約1年前に、インターンとして数ヶ月間会社で働いていました。当社はソースコードバージョン管理（CVS）を使用していますが、適切ではありません。
これが私のインターンシップと現在の常勤の両方で起こったことです。私がプロジェクトに取り組むように割り当てられるたびに（レガシー、約8〜10歳）。CVSアカウントを作成してコードをチェックアウトし、変更をチェックインさせる代わりに、先輩の同僚がCVSからコードをエクスポートし、圧縮して私に渡しました。
この同僚は数週間ごとにすべての変更を一括でチェックインしますが、通常の方法では、実際のソースコード自体できめ細かいバージョン管理を行います（各ファイルは他のファイルから独立したバージョンで増分します）。ファイルに変更が加えられるたびに、古いコードがコメントアウトされ、その下に新しいコードが入力され、このセクション全体にバージョン番号が付けられます。変更に関するメモは、ファイルの上部の「変更履歴」というセクションに配置されます。最後に、変更されたファイルは共有フォルダーに配置され、一括チェックインの準備が整います。
/*
* Copyright notice blah blah
* Some details about file (project name, file name etc)
* Modification History:
* Date Version Modified By Description
* 2012-10-15 1.0 Joey Initial creation
* 2012-10-22 1.1 Chandler Replaced old code with new code
*/
code ....
//v1.1 start
//old code
new code
//v1.1 end
code ....
今問題はこれです。私が取り組んでいるプロジェクトでは、別のプロジェクトからいくつかの新しいソースコードファイルをコピーする必要がありました（以前は宛先プロジェクトに存在していなかったという意味で新しい）。これらのファイルには、通常は長いまたは非常に長い変更履歴セクションを含む、多くの履歴コメントアウトコードとコメントベースのバージョン管理が含まれています。
ファイルはこのプロジェクトにとって新しいものなので、ファイルをクリーンアップして履歴コードを含む不要なコードを削除し、バージョン1.0からやり直すことにしました。（コメントベースのバージョン管理は嫌いですが、それでも継続する必要があります。バージョン0.1から始めない理由は聞かないでください...）インターンシップ中に同様のことをしましたが、誰も何も言いませんでした。私の上司はその仕事を数回見たことがあり、そのようなクリーンアップを行うべきではないとは言いませんでした（気づいたとしても）。
しかし、同じレベルの同僚がこれを見て、将来ダウンタイムを引き起こし、保守コストを増加させる可能性があるため、推奨されないと述べました。例として、元のファイルに対して別のプロジェクトで変更が加えられ、これらの変更をこのプロジェクトに伝播する必要がある場合があります。コードファイルが大幅に異なると、伝播を行う別の開発者に混乱を引き起こす可能性があります。それは私には理にかなっており、有効なポイントです。ばかばかしいほど厄介なコードの不便さ以外に、クリーンアップを行う理由を見つけることができませんでした。
つまり、簡単に言えば、私たちの会社での慣習を考えると、プロジェクトからプロジェクトに新しいファイルをコピーするときに、そのようなクリーンアップを行うべきではありませんか？コメントに完全な履歴がある元のコード（のコピー）に変更を加える方が良いですか？または、クリーンアップを行うためにどのような正当化を与えることができますか？
PSからMODへ：何らかの理由でSOに適さないと判断した場合でも、この質問をしばらく許可してください。タグなど不適切な点がございましたら、あらかじめお詫び申し上げます。