6

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

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

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

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

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

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

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

4

8 に答える 8

6

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 年で読みやすくなるでしょう。

于 2009-06-05T20:42:07.157 に答える
4

ここでは単体テストが役立ちます。特別なケースを実際にシミュレートするテストを持つことは、多くの場合、コードがその動作を行う理由に関するドキュメントとして役立ちます。これは、コメントで問題を説明するよりも優れていることがよくあります。

これは、特殊なケースの処理を独自の関数と適切なコメントに移動することに取って代わるものではありません...

于 2009-06-05T20:48:42.060 に答える
2

プロジェクトのナレッジ ベースまたは wiki がある場合は、そこにグラフを追加し、マシューのファウラーの引用に従ってメソッドにリンクし、エッジ ケースの変更のソース管理コミット メッセージにもリンクできます。

//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

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

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

于 2009-06-05T20:52:38.133 に答える
1

Don Knuthは、プログラムのドキュメントにプロット、グラフ、チャート、数式など、理解するために必要なものを簡単に含めることができるように、文芸的プログラミングを発明しました。文芸的プログラムは、何かがそのようになっている理由と、それが時間の経過とともにどのようにそのようになったのかを説明するための優れた方法です。多くの文芸的プログラミングツールがあります。「noweb」ツールは最も単純なツールの1つであり、一部のLinuxディストリビューションに付属しています。

于 2009-06-05T22:25:54.780 に答える
1

関して

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

部：

埋め込みたい「グラフィック」がグラフで、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.
*/
于 2009-06-05T21:12:31.590 に答える
1

私は通常、テスト駆動型開発や、テストに過度のストレスを与える同様のスタイルを支持するわけではありませんが、これは一連の単体テストが大いに役立つ完璧なケースのようです。また、最初に変更後のバグを検出するためでもなく、対処が必要なすべての特殊なケースを単に文書化するためでもあります。

コメントを含むいくつかの優れた単体テストは、それ自体が特殊なケースの最良の説明です。また、コード自体のコメントも簡単になります。コードのその時点で解決されている問題を示すいくつかの単体テストを簡単に示すことができます。

于 2009-06-05T20:52:34.733 に答える
0

コード コメントだけでなく、より詳細なドキュメントが必要なようです。そうすれば、誰かがドキュメントで問題の関数を調べて、特別なケースを必要とするサンプル画像を提示することができます.

于 2009-06-05T21:04:42.323 に答える
0

問題の特定の性質を知らずに答えを出すのは簡単ではありませんが、私の経験では、ハードコードの特殊なケースの処理は避ける必要があります。メイン処理アルゴリズム以外の特殊なケースを処理するために、ルール エンジンなどを実装することを考えたことはありませんか?

于 2009-06-05T20:40:15.430 に答える