1

いくつかの非直感的なビジネス要件のために、広範なコメントが必要なメソッドがあります。簡潔にならないようにリファクタリングする必要がありました (デファクタリング?) が、ビジネス要件が誤って変更されないようにするために、次の方法でコメントした場所が必要であると言ったとき、私を信じてください。

public bool CheckBasedOnApplicableConditions()
{
    bool conditionOne;
    bool conditionTwo;

    // Comments to explain why BusinessLogic is used
    if (BusinessLogic())
    {
        //Comments discussing SecondaryBusinessLogic
        conditionOne = true;
        conditionTwo = SecondaryBusinessLogic();
    }
    else
    {
        //Comments discussing this scenario
        conditionOne = DifferentBusinessLogic();
        conditionTwo = !conditionOne;
    }

    //Comments about the CheckForCondition calls
    if (conditionOne && CheckForConditionOne())
    {
        return true;
    }
    if (conditionTwo && CheckForConditionTwo())
    {
        return true;
    }
    return false;
}

私は本当に、このメソッドが開発者 (別名、1 か月後の私) によって壊れないように、将来的に保証したいと考えています。ビジネス要件には、2 つの条件のうち少なくとも 1 つを確認する必要があることが含まれていることを強調することが重要だと思います。そこで、最終リターンの前に次のコードを追加しました。

    //ReSharper normally points out this always evaluates to false,
    // but because an exception is being thrown it does not complain.
    if (!conditionOne && !conditionTwo)
    {
        throw new InvalidOperationException
            ("Condition One or Two must be applicable!");
    }

意図された効果は、開発者が不用意にビジネス要件に違反した場合に、警告なしに false を返し、追跡に時間がかかるバグを作成する代わりに、例外がスローされることです。これはあまり見たことのないパターンですが、ReSharper は、throw が追加されたときに、独自の「コードはヒューリスティックに到達できません」という警告を自動的に抑制しました。

私の質問は: このアプローチに意図しない副作用はありますか? つまり、パフォーマンスの低下、または私が見落としている保守性の問題、またはその他の予期しない問題ですか? メソッドをより安定させるためにリファクタリングできることは承知しています。しかし、これには理解が犠牲になるのではないかと心配しています。

4

2 に答える 2

1

自己テストコードは、ある時点までは問題ありません。ここで提案しSystem.Diagnostics.Debug.Assert()ます。

しかし、この種の論理条件の検証は、外部テスト、つまり単体テストまたは (まだあまり成熟していない) コード コントラクトによって処理する方が適切です。

メソッドの結果のみをテストできるため、これはメソッドをより小さな部分にリファクタリングするための引数になります。

于 2013-09-18T18:54:46.457 に答える