5

既存のコードを変更するときに使用する特別なテクニックは何ですか？

例：メソッド内のビジネスルールを変更するとします。変更されたセクションに特別なコメントを付けますか？

コードを変更するときに使用するコーディング/コメント標準はありますか？

4

10 に答える 10

14

次のような意味です。

foo();  // changed by SecretWiz, 20090131

これはお勧めしません。コードファイルが乱雑になるため、バージョン管理システムがそれを処理する必要があります。誰が何を変更したかを追跡します。使用する

svn blame
于 2009-02-01T04:16:07.630 に答える
4

比較的目立たないバグを修正するようなことを行う場合、基本的には、なぜ自分が行った方法でコードを記述したのかが明確でない場合は、通常、それを説明するコメントを追加します。他の誰かが私のコードを変更したことがある ;-) 後で誤って削除することはありません。

于 2009-02-01T07:27:53.047 に答える
3

私がいつも心がけていることの 1 つは、バグ追跡システムのバグ ID (または機能要求 ID) を、その変更に対して行うコード チェックイン コメントに入れることです。「詳細については、bugzilla のこのバグ/機能のコメントを参照してください」のようなものを追加します。そこで、そのコード変更の理論的根拠を説明することができます。これは、すべての変更、または少なくともすべての重要な変更を機能リクエスト/バグ ID で追跡する必要があることを意味します。関連するビジネス上の理由を詳細に説明するためだけに、何度もバグを作成しました。

于 2009-02-01T07:34:55.763 に答える
2

いいえ、それは本当に悪い考えです。ソース管理には、すべての編集の履歴が保持されます。他の何かが必要な場合は、バグ追跡ツールにエントリを作成してください。コードの古いセクションをコメントアウトしたり、次のようなものを散らかしたりする必要はありません。

// modified by A.B. on 11/23/99 to fix issue #123456

コードベースでこのようなコメントを見たことがありますが、何年も経つと意味がありません。AB とは何者で、issue #123456 は何だったのでしょうか? コードがまだここにある場合、誰かがこれらの変更を将来ロールバックする予定があるということですか?

これらのコメントには価値がなく、コードを混乱させるだけです。

于 2009-02-01T04:16:23.370 に答える
1

メソッドを作成し、変更されているコードからそれを呼び出すことをお勧めします。
また、メソッドに名前を付けて、メソッドの目的/意図を示唆します。

例えば GiveRebateIfValidCoupon();

于 2009-02-01T04:18:35.113 に答える
0

「コードを変更するときに使用するコーディング/コメント標準はありますか？」

はい。新しいサブクラスを作成します。正しくテストせず、実際に間違っていたというまれなケースを除いて、古いコードはそのままにしておきます。

要件の変更は、新しいビジネスルールを処理するためのサブクラスと新しいテストを追加することを意味します。

于 2009-02-01T04:21:48.260 に答える
0

特別なコメントを追加するのは、変更が一時的なものである場合のみです。そのような状況では、後で見つけられるように、標準のキーワード（TEMPFIXなど）でフラグを立てます。もちろん、戻ってコードを削除するか、永続的な変更を加えることを忘れないでください。ただし、一部のプロジェクトでは、コードのコンパイルが停止するまでの有効期限を指定できるマクロを使用するように強制しています。

それ以外は、ソース管理に依存しています。

于 2009-02-01T04:35:21.867 に答える
0

コードは、あなたが持っている、またはあなたの組織が持っているコーディング標準に準拠している必要があります。

したがって、いいえ、コードが変更されたという特別なコメントはありません。すべてまたは少なくともほとんどの場合、コードは遅かれ早かれ変更されます。

コメント標準に対応しない継承したコードがある場合は、コードをリファクタリングするときに必ずコメントを追加してください。コードが本当に古くてドキュメント化されていない場合、当然それはドキュメントを追加することを意味します。

コードを変更する前に（ちなみに）コードを理解しておくことをお勧めします。

于 2009-02-01T04:48:43.603 に答える
0

通常、コードを変更し、ソース管理チェックインでコメントを作成します。選択したタスク追跡ツールで、タスクが実装されたリビジョンを参照できます。

ユーザーの要件がどのように議論されているかに応じて、特定の機能が前後に変更されたり、移動したり、名前が変更されたりすることを時々知っています。この特別なケースでは、古いバージョンをそのままにして、コメントアウトします。そうすれば、ソース管理を介して古いバージョンを探すのではなく、後でコメントを外すのは簡単になります。これにより、後でコードを維持する必要がある場合に、誰かのお尻を節約することもできます。ユーザーがもう一度考えを変えると、要件はすでにコードに含まれていて、コメントが解除されるのを待っているからです。

于 2009-02-01T05:04:00.670 に答える
0

SOについては、他の多くの人々に同意する必要があります。「コードに不要なものがある場合は、削除してください」。特に製品コードでは、散らかってしまうことは望ましくありません。誰かがメンテナンス コメントを読んで混乱するよりも、変更がどのように機能するかを理解する方がはるかに簡単です。

以前は非推奨の古いコードをプロジェクトに残していましたが、時間の経過とともに数千行のはずだったプロジェクトが 10,000 行を超え、管理が困難になりました。

于 2009-02-01T07:10:21.490 に答える