80％を超える変更を行う場合、クラスファイルの著者名を変更する必要がありますか？

自動化されたUIテストのために、既存のJavaテストクラスのセットをリファクタリングしています。クラスファイルを大幅に変更するか、完全に変更することがあります。これにより、クラス全体を書き換えるとき、コメントセクションの著者名を自分のものに変更する必要があると思いますか？

私は貪欲ですか？それとも、私の名前を見て疑問がある場合に私に尋ねることは有用でしょうか？

それは本当に依存しています...

他の誰かが後で元の作者に尋ねることに興味があるかもしれないというわずかな可能性があると思うなら、コードに彼の名前を入れてください。誰かがあなたに直接尋ねることに興味があるかもしれないと思うなら、あなたの名前を入れてください。そして、あなたが考えるなら、両方が可能かもしれません、両方の名前を入れてください（または「…の仕事に基づいて」のようなコメント）。

もちろん、職場でソース管理の使用が必須であり、それがソースへのアクセスを取得する唯一の方法である場合は、面倒を省き、すべての著者のコメントをソースから削除します。たとえば、私の職場では、ソース管理に多くのソースファイルがあり、ソースに名前を書き込む必要はありません。ファイルの責任者、過去、または特定の変更の責任者を知りたい場合、TortoiseSVNはそのログを簡単に生成します。

一方で、一部の人が書いたVBAマクロがたくさんあり、他の人に渡され（一部は長年にわたって会社を去りました）、多くのソース管理を使用せずに修正されました。幸いなことに、これらのファイルのコメントには、多くの場合、著者名と何らかの種類の履歴ログが含まれています。

私はちょうどOPが著者の名前をファイルヘッダーに含める必要があるかどうかを尋ねている別の投稿に出会いましたファイルの変更者を追跡するだけです。その投稿に何が起こったのか分かりませんが、今では見つけることができません。<-（したがって匿名の「OP」）

個人的には、ファイルヘッダーにリストされている作成者が有用であることがわかりますが、その理由は少し異なります（これは環境内の他のユーザーとは関係ない場合があります）。コミュニティの所有権を実践しようと試み、プロジェクトのさまざまな部分で作業することもありますが、コードの特定の領域を他の領域よりも詳しく知っているチームメンバーはほとんどいません。したがって、誰か（特に出入りする多数の請負業者）が今まで見たことのないファイルを開くと、著者が頼りになる人になります。彼は唯一の貢献者ではなく、多数派の貢献者でさえないかもしれませんが、彼の名前を先頭にして、コードに関する知識/情報をチームの他のメンバーに配布することに一定の責任があることを認めています。ヘッダーには複数の人が実際に貢献しており、責任を感じていることを示すことができます。

ファイルに関する質問があり、バージョン管理に頼って主要な、または最も知識のある人を特定しなければならないとき、私はイライラします。そして、コードが何をしているのかを本当に否定しているので、ある人から次の人に行くことになります。

ハンドオフがないため、このプラクティスはチームで機能します。人が辞めるか、別のチームに移動しない限り、そのコード/プロジェクトはその人と私たちのチームにとどまります。明らかに、コードを保守している人がコードを書いている人と同じでない場合、誰もヘッダーにリストされていることを気にしません。

したがって、ファイルヘッダーに関する私の見解に照らして、ファイルの80％を変更した場合、あなたは今、あなたが質問の頼りになる人であると感じます（そして、おそらくあなたはそのように感じるはずです）、はい、行きます先にファイルヘッダーを更新して名前を付けます。前の人を削除するのが気に入らない場合は、少なくとも当面はその人の名前をそこに残すことができます。あなたはいつでも元の作者に尋ねることができ、あなたは名前を変更したことを少し気にしないと確信しています。ファイル自体の80％を変更するのは難しいと思っているからです。

更新：その投稿を見つけました。8月からどうやって何かを取り戻したかわからない。The Pragmatic Programmerを読み終えたばかりで、最後の章で著者は署名作業と説明責任について話します（他の投稿がそれについて言及したので、調べました）。この本は完全に理にかなっており、今考えてみると、著者としてリストされている人は誰でも、問題のファイルのすべてのコードレビューに含めるべきであるというチームポリシーを導入する必要があります。SVNでファイルを最後に変更したか、ほとんど変更したかは関係ありません。作成者は所有者であり、キーパーです。

著者の名前がひどく便利だとは思いません。この質問が示すように、多くの場合、単一の著者は存在しないため、「著者」と命名することはできません。

もちろん、主要な貢献をしたすべての人々のリストを含めることもできますが、それはすでにリビジョン管理ログから取得できます-それで、ポイントは何ですか？

私のプロジェクトでは、ほとんどのファイルに著者情報がありません。質問がある場合は、ログを調べるだけです。通常、1〜2人がほとんどの作業を行ったことは明らかなので、尋ねます。

編集

答えは、バージョン管理を使用するプロジェクトを想定しています。VCを（一貫して）使用しない場合は、作成者（リスト）を入れて、おそらく変更履歴をファイルに入れることは実行可能な回避策かもしれません。それでも、おそらくできるだけ早くVCの使用を開始する必要があります。その場合は上記を参照してください:-)。

ファイルが大幅に変更されている場合は、そのファイルについて何かを知っている人として自分の名前をファイルに追加してもかまいません。

ソースファイルの作成者は、ソースファイルで常に言及する必要があります。これは、適切なヘッダーコメント付きで、著者がソースを開発した理由と、コードを書くことに対する彼/彼女の考えを示しているはずです。コードのメンテナーに関しては、ソース管理の追跡にはメンテナーの名前を追加することが重要です。

著者、IMHOの命名には、バージョン管理システムの外部のコードのソースバージョン、変更が発生した最初の日付、および変更要求番号を含める必要があります。その理由は、VCSを変更する決定が発生した場合、コードのバージョン、作成者、開発者が参照できる変更要求番号の履歴があります（メンテナーが彼/彼女がやった）。したがって、私たちの組織では、フォーマットは次のとおりです。

/**
 * $comment
 * <p />
 * $cr_number, $date, $author, $description 
 **/

コードについての答えを探している人を見つけるためだけに、元の作者の名前を見るのが好きです。（作者は一般に思い出しませんが、少なくとも一撃です！）

元の著者の下に自分の名前を追加することをお勧めします。

他の人の名前を置き換える必要はありません。彼らはあなたが知らない元のビジネスの必要性のある側面を知っているかもしれません。

@authorコメントに関する私のポリシーは次のとおりです。

1. それが真新しいファイルである場合、私は自分を@authorとして置きます。
2. 既存のファイルの場合、ファイルに対して何をするかに関係なく、@ authorをそのままにします。

何か質問がある場合、ファイルの@authorが誰であるかは関係ありません。編集中のファイルのどの部分の@authorが誰であるかが重要です。それ[git/svn/whatever] blameが目的です。

IMO、@ authorは立ち去る必要があります。