特殊なケースとヒューリスティックを管理する方法

StackOverflow https://stackoverflow.com/questions/958003

  •  12-09-2019
  •  | 
  •  

質問

明確に定義された特定のアルゴリズムに基づいたコードを使用することがよくあります。これはよくコメントされており、適切であると思われます。ほとんどのデータセットでは、このアルゴリズムはうまく機能します。

しかし、その後、特定のデータセットに関する特定の問題を解決するために、エッジケース、特殊ケース、ヒューリスティックが追加されます。特殊なケースの数が増えるにつれて、コメントはますます曖昧になります。1 年ほど後にこのコードを見直して、それぞれの特殊なケースやヒューリスティックが追加された理由を思い出そうとするのが怖いです。

私は時々、ソース コードにグラフィックスを埋め込んだりリンクしたりする方法があればいいのにと思うことがあります。そうすれば、「このデータ セットのグラフでは、この特定の機能がルーチンを誤ってトリガーしていました。そのため、この部分はコードが追加されました。」

このような状況に対処するためのベストプラクティスは何ですか?

これらの珍しい/特殊なケースを処理するには、常に特別なケースが必要とされるようです。コードを比較的読みやすく理解しやすい状態に保つには、どうすればよいでしょうか?

写真からの特徴認識を扱う例を考えてみましょう (私が取り組んでいることと正確には異なりますが、たとえは適切だと思われます)。一般的なアルゴリズムが失敗し、特殊なケースが必要な特定の画像を見つけた場合、私はその情報をコメント (または、以下で誰かが提案しているように、説明的な関数名) にできる限り記録します。しかし、欠けていることが多いのは、問題の動作を示す特定のデータ ファイルへの永続的なリンクです。私のコメントは問題を説明する必要があり、おそらく「この動作の例についてはファイル foo.jp を参照してください」と言うでしょうが、このファイルはソース ツリーに存在しないため、簡単に失われる可能性があります。

このような場合、参照用にデータ ファイルをソース ツリーに追加しますか?

役に立ちましたか？

解決

プロジェクトのナレッジ ベースまたは Wiki がある場合は、その中にグラフを追加し、メソッド内でそれにリンクすることができます。 マシュー・ファウラーの名言e およびエッジ ケース変更のソース管理コミット メッセージにも含まれます。 

//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
   //modify param to solve for edge case
   return param;
}

Commit Message: Solution for X and Y edge case, see description at KB#2312

これは手間がかかりますが、単なるテスト ケースやコメントよりも徹底的にケースを文書化する方法です。テスト ケースは文書化するだけで十分だと主張する人もいるかもしれませんが、たとえば、失敗したデータ セット全体をその中に保存したくないかもしれません。

曖昧な問題は曖昧な解決策につながることを忘れないでください。

他のヒント

Martin Fowler氏は、あなたが、あなたのコードにコメントを追加する必要性を感じたときにメソッドにそのコードをカプセル化し、法にコメントを代わる名前をつけることができるかどうか最初に見ることを彼のリファクタリングの本の中で述べます。

という名前のメソッドを作成することができ、抽象ほどます。

private bool ConditionXAndYHaveOccurred(object param)
{
   // code to check for conditions x and y
   return result;
}

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param)
{
   //modify param to solve for edge case
   return param;
}

次に、あなたのようなコードを書くことができます。

if(ConditionXAndYHaveOccurred(myObject))
{
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject);
}

未厳格な具体例が、それは1年か2年での可読性を助けるでしょう。

ユニットテストはここに助けることができます。実際には特殊なケースをシミュレートしたテストでは、多くの場合、コードはそれが何をした理由についてのドキュメントとしての役割を果たすことができます。これは、多くの場合、単なるコメントで問題を記述し、その後改善することができます。

これは、独自の機能とまともなコメントに扱う特殊なケースを移動置き換えないことを...

私は通常、テスト駆動開発とテストがあまりにも多くのストレス似たスタイルの提唱者ではないんだけど、これはユニットテストの束が多くを助けることができる完璧なケースのようです。そして、いなくても、後で変更からバグをキャッチするために、単に対処するために必要なすべての特殊なケースを文書化するために最初の場所でます。

彼らのコメントといくつかの良いユニットテスト自体は特殊な例最良の説明です。そして、コード自体のコメントには、あまりにも簡単になります。一つは、単にコード内のその時点で解決される問題を示すいくつかのユニットテストを指すことができます。

タグについて
  

私は時々、ソースコードでグラフィックを埋め込むまたはリンクする方法があった希望します、   私は、このデータセットのグラフでは」効果的、この特定の言うことができます   ここでの機能は、ルーチンが誤ってトリガさせたので、それはなぜこの作品です   コードは」追加されました。

パートます：

あなたは埋め込みたいという「グラフィック」はグラフであり、あなたが使用している場合 Doxygenのに、あなたの場合

：には、ドキュメントにグラフを生成するために、あなたのコメントにコマンドドットを埋め込むことができます 
/**
If we have a subgraph looking like this:
\dot
digraph g{
A->B;
A->C;
B->C;
}
\enddot
the usual method does not work well and we use this heuristic instead.
*/

ドン・クヌースは、お使いのプログラムのマニュアルをプロットし、グラフ、チャートを含めるために、それは簡単にするために文芸的プログラミングを発明しました数学の方程式、および任意の他、あなたがそれを理解しておく必要があります。識字プログラムは、何かがそれが道であり、それがどのように時間をかけてそのようになっている理由を説明するのに最適な方法です。多くの、多くの文芸プログラミングツールがあります。 「nowebの」ツールは、最も簡単なの一つであり、いくつかのLinuxディストリビューションに同梱されます。

あなたの問題の特定の性質を知らずに答えを与えることは容易ではありませんが、私自身の経験では、ハードコード上の特殊なケースの取り扱いは避けなければなりません。あなたがメインの処理アルゴリズムの外に特別な場合を扱うため、そのようなルールエンジンか何かを実装について考えていないことがありますか？

あなただけのコードのコメントよりも徹底したドキュメントを必要とするように

これが鳴ります。その方法は、誰かが文書に問題の機能を調べることができ、特別なケースを必要とする例の絵を提示すること。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top