一時的な回避策として、メソッド名にバグ番号を含めるのは悪い習慣だと考えられていますか？

シニアの同僚である同僚が、コードのレビューで私をブロックしているのは、欠陥###の回避策であるため、メソッドに 'PerformSqlClient216147Workaround'という名前を付けてほしいからです。今、私のメソッド名の提案は、PerformRightExpressionCastのようなもので、メソッドが実際に行うことを説明する傾向があります。彼の議論は「この方法はこの場合の回避策としてのみ使用され、他のどこにも使用されない」という線に沿っています。

一時的な回避策としてメソッド名にバグ番号を含めることは悪い習慣と見なされますか？

あなたの同僚が提案したように、メソッドに名前を付けません。メソッド名は、メソッドの動作を示す必要があります。のような名前PerformSqlClient216147Workaroundは、それが何をするかを示していません。どちらかといえば、その方法を説明するコメントを使用して、それが回避策であることを示します。これは次のようになります。

/**
 * Cast given right-hand SQL expression.
 *
 * Note: This is a workaround for an SQL client defect (#216147).
 */
public void CastRightExpression(SqlExpression rightExpression)
{
    ...
}

私はMainMaに同意します。バグ/欠陥番号はソースコード自体ではなく、ソース管理コメントに表示されるべきです。これはメタデータであるためです。バグ/欠陥番号をメソッドの名前に使用しないでください。

動作する一時的な修正ほど永続的なものはありません。

彼の提案は10年後には見栄えがするでしょうか？以前は、各変更を修正した欠陥でコメントするのが一般的でした。最近（過去30年間）、このスタイルのコメントは、コードの保守性を低下させるものとして広く受け入れられています。これは、メソッド名ではなく単なるコメントです。

彼が提案しているのは、QCおよびQAシステムが著しく不足している説得力のある証拠です。欠陥および欠陥修正の追跡は、ソースコードではなく欠陥追跡システムに属します。ソースコードの変更のトレースは、ソース管理システムに属します。これらのシステム間の相互参照により、欠陥をソースコードまで追跡できます。

ソースコードは、昨日ではなく、明日でもあります（たとえば、来年の予定をソースに入力しません）。

それは一時的な解決策ですか？次に、レビュー担当者によって提案された名前を使用しますが、メソッドを廃止としてマークし、誰かがコードをコンパイルするたびに警告が生成されるようにします。

そうでない場合216147は、コードがバグ追跡システムにリンクされていないため（ソース管理にリンクされているのはバグ追跡システムであるため）、コードで意味をなさないことが常にわかります。ソースコードは、バグチケットとバージョンへの参照に適した場所ではありません。これらの参照を本当に配置する必要がある場合は、コメントで行ってください。

コメントでさえ、バグ番号だけではあまり価値がないことに注意してください。次のコメントを想像してください：

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The following method replaces FindReportByDate, because of the bug 8247 in the
    // reporting system.
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

コードが10年前に書かれ、あなたがプロジェクトに参加したばかりで、バグ8247に関する情報をどこで見つけられるか尋ねたときに、同僚がWebサイトにバグのリストがあると言ったとします。システムソフトウェアを報告しますが、ウェブサイトは5年前にやり直され、バグの新しいリストには異なる番号が付けられています。

結論：このバグが何であるかわかりません。

同じコードをわずかに異なる方法で作成することもできます。

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The reporting system we actually use is buggy when it comes to searching for a report
    // when the DateTime contains not only a date, but also a time.
    // For example, if looking for reports from `new DateTime(2011, 6, 9)` (June 9th, 2011)
    // gives three reports, searching for reports from `new DateTime(2011, 6, 9, 8, 32, 0)`
    // (June 9th, 2011, 8:32 AM) would always return an empty set (instead of isolating the
    // date part, or at least be kind and throw an exception).
    // See also: http://example.com/support/reporting-software/bug/8247
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportsByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

これで、問題を明確に把握できます。コメントの最後のハイパーテキストリンクが5年前に無効になっているように見えても、それが問題にならないのは、なぜFindReportsByDateに置き換えられたのかを理解できるからですFindReportsByDateOnly。

PerformSqlClient216147Workaroundそれから私はもっと有益だと思うPerformRightExpressionCast。機能の名前、機能の理由、機能の詳細、または機能に関する詳細情報の入手方法については、疑いの余地はありません。これは明示的な関数であり、ソースコードでの検索が非常に簡単になります。

バグ追跡システムを使用すると、その番号が問題を一意に識別し、そのバグをシステムにプルアップすると、必要なすべての詳細が提供されます。これは、ソースコードで行う非常に賢明なことであり、変更が行われた理由を理解しようとする場合、将来の開発者の時間を節約できます。

ソースコードにこれらの関数名が多数ある場合、問題は命名規則ではありません。問題は、バグのあるソフトウェアがあることです。

同僚の提案には価値があります。コードへの変更をそのチケット番号でバグデータベースに記録された理由、変更が行われた理由に関連付けて、トレーサビリティを提供します。

ただし、機能が存在する唯一の理由はバグを回避することであることも示唆しています。つまり、問題が問題でなければ、ソフトウェアにそのようなことをさせたくないでしょう。おそらく、ソフトウェアにその機能を実行してほしいと思うので、関数の名前はそれが何をするのか、なぜ問題のドメインがそれを行う必要があるのかを説明するべきです。バグデータベースがそれを必要とする理由ではありません。ソリューションは、バンドエイドではなく、アプリケーションの一部のように見える必要があります。

私はあなたと彼の両方がこの全体を不均衡になっていると思います。

私はあなたの技術的な議論に同意しますが、特にこれが数日/数週間/数か月でコードベースから削除できる一時的な修正である場合、1日の終わりにはそれほど違いはありません。

自分のエゴを箱に戻し、彼に自分のやり方を持たせるだけだと思います。（もし彼が聞いていたら、君たちは妥協する必要があると思う。両方のエゴは彼らの箱に戻った。）

どちらにしても、あなたと彼にはもっと良いことがあります。

一時的な回避策としてメソッド名にバグ番号を含めることは悪い習慣と見なされますか？

はい。

理想的には、クラスはアプリケーションフロー/状態の概念に最適にマッピング/実装する必要があります。このクラスのAPIの名前は、クラスの状態に対して行うことを反映する必要があります。そのため、クライアントコードはそのクラスを簡単に使用できます（つまり、特に読んでいない限り、文字通り何も意味しない名前を指定しないでください）。

そのクラスのパブリックAPIの一部が基本的に「ドキュメント/ロケーションXに記述されている操作Yを実行する」と言っている場合、APIを理解する他の人々の能力は以下に依存します。

1. 外部ドキュメントで何を探すべきかを知っている

2. 外部ドキュメントを探す場所を知っている

3. 彼らは時間と労力をかけて実際に見ています。

繰り返しになりますが、メソッド名には、この欠陥の「場所X」がどこにあるのかさえ記載されていません。

（現実的な理由はまったくありませんが）コードにアクセスできるすべての人が欠陥追跡システムにもアクセスでき、安定したコードが存在する限り追跡システムが存在することを前提としています。

少なくとも、同じ場所で常に障害にアクセスでき、これが変わらないことがわかっている場合（過去15年間同じURLにあったMicrosoftの障害番号など）、リンクを提供する必要がありますAPIのドキュメントの問題。

それでも、1つのクラスのAPI以外にも影響する他の欠陥の回避策がある場合があります。それなら何をしますか？

複数のクラスで同じ欠陥番号のAPIを使用すると（data = controller.get227726FormattedData(); view.set227726FormattedData(data);実際にはあまりわかりませんが、コードがわかりにくくなります。

操作（data = controller.getEscapedAndFormattedData(); view.setEscapedAndFormattedData(data);）を説明する名前を使用して、他のすべての欠陥を解決することを決定できます。ただし、216147欠陥（「最低の驚き」の設計原則に違反する場合、またはそのようにしたい場合は例外）コードの「WTF / LOC」の測定値を増やします）。

TL; DR：悪い練習です！あなたの部屋に行きなさい！

プログラマーの主な目標は、コードを実行し、表現を明確にすることです。

回避方法の命名（....回避方法）。この目標を達成するようです。うまくいけば、何らかの段階で根本的な問題が修正され、回避方法が削除されるでしょう。

私には、バグにちなんでメソッドに名前を付けると、バグが解決されていないか、根本原因が特定されていないことが示唆されます。言い換えれば、未知のものがまだあることを示唆しています。サードパーティシステムのバグを回避している場合、回避策は解決策です。原因がわかっているからです-修正できないか、または修正できないだけです。

SqlClientとのやり取りの一部で正しい式キャストを実行する必要がある場合、コードは「performRightExpressionCast（）」を読み取る必要があります。コードをいつでもコメントして、理由を説明できます。

私は過去4年半にわたってソフトウェアのメンテナンスを行ってきました。飛び込むときに理解するのを混乱させるコードの1つは、歴史のためだけに書かれたコードです。言い換えれば、今日書かれた場合、それはどのように機能するかではありません。私は品質について言及しているのではなく、視点について言及しています。

私の同僚はかつて、「欠陥を修正するときは、本来あるべき方法でコードを作成する」と言いました。私がそれを解釈する方法は、「このバグが存在しなかった場合の外観にコードを変更する」です。

結果：

1. 通常、結果としてコードが少なくなります。
2. 簡単なコード
3. ソースコードのバグへの参照が少ない
4. 将来のリグレッションのリスクが少ない（コードの変更が完全に検証されると）
5. 開発者は、もはや関係のない学習履歴を負担する必要がないため、分析が容易です。

ソースコードは、現在の状態になった方法を教えてくれる必要はありません。バージョン管理は履歴を教えてくれます。ソースコードが動作するために必要な状態にある必要があります。とは言っても、時々「// bug 12345」というコメントは悪い考えではありませんが、悪用されます。

したがって、メソッドに「PerformSqlClient216147Workaround」という名前を付けるかどうかを決めるときは、次の質問を自問してください。

1. コードを記述する前にバグ216147について知っていた場合、どのように処理しますか？
2. 回避策は何ですか？以前にこのコードを見たことがない人がそれを見た場合、彼らはそれに従うことができますか？このコードがどのように機能するかを知るには、バグ追跡システムをチェックする必要がありますか？
3. このコードは一時的ですか？私の経験では、@ mattnzが示すように、通常、一時的な解決策は永続的になります。