一次コードレビューによるTDD(続き)

先週書いたコードレビューによるTDDがTDDディスカッショングループに発表された後(興味のある学生は私信で寝ることができ、マイクロ信号Vic-VVu)、グループの大神たちは次々とフィードバックを与え、最も印象的なのは麦宇安大神から来た.
@葛亮テストは意図をはっきり表現していません.どうしてbest fitになったのですか.1 2などの魔法の数字は何を表していますか.テストを見ているだけで何を測っているのか全然分からない!
耳に逆らうように聞こえるが、耳に逆らうのは忠言で、苦いのは良薬で、急いで自分のテストコードを見に帰って、文脈がなければ、初めてコードを読む読者の角度に立って、確かにテストが何なのか全然知らない.Clean Codeの道に詳しいと思っていた私は急に耻ずかしい.

    @Test
    public void two_matched_tariffs_with_different_rank() {
        Tariff matchedTariff1 = new Tariff(1, 1);
        Tariff matchedTariff2 = new Tariff(2, 2);
        List matchedTariffs = Arrays.asList(matchedTariff1, matchedTariff2);
        List bestFitTariffs = Arrays.asList(matchedTariff1);
        assertListEqual(bestFitTariffs, selectBestFit(matchedTariffs));
    }

誤りを知って改めることができて、善莫大焉、そこですぐに再構築して、まず魔法の数字を消して、コードは以下の通りです.

    @Test
    public void two_matched_tariffs_with_different_rank() {
        Tariff matchedTariff1 = new Tariff(GEO_LEVEL.TOWN, GEO_LEVEL.TOWN);
        Tariff matchedTariff2 = new Tariff(GEO_LEVEL.CITY, GEO_LEVEL.CITY);
        List matchedTariffs = Arrays.asList(matchedTariff1, matchedTariff2);
        List bestFitTariffs = Arrays.asList(matchedTariff1);
        assertListEqual(bestFitTariffs, selectBestFit(matchedTariffs));
    }

テストに合格しました.コードは少しよくなりましたが、テストの意図はまだ明らかではありません.テスト方法といくつかの重要な変数の名前を変更することにしました.コードは以下の通りです.

    @Test
    public void town2town_is_more_fit_than_city2city_tariff() {
        Tariff town2town = new Tariff(GEO_LEVEL.TOWN, GEO_LEVEL.TOWN);
        Tariff city2city = new Tariff(GEO_LEVEL.CITY, GEO_LEVEL.CITY);
        List candidateTariffs = Arrays.asList(town2town, city2city);
        List bestFitTariffs = Arrays.asList(town2town);
        assertListEqual(bestFitTariffs, selectBestFit(candidateTariffs));
    }

テストに合格して、今のコードと最初のコードを比較して、気分がよくなりました:)
群の中のもう一人の大神は性能の問題にも言及して、二叉樹の実現の性能は今の簡単な実現より良いと言って、これは私に次の名言を思い出させます.
「プログラミングでは、早すぎる最適化は万悪の源です.」-Donald Ervin Knuth,1974
Donaldは古典的な巨著「コンピュータプログラム設計の芸術」の著者で、1974年のトゥーリン賞を受賞した.コードの可読性と性能の間で私はコードの可読性を優秀に選択します.あなたが行った局所的な性能最適化はシステムレベルでは微々たるものである可能性があります.本明細書で述べたコードを例にとると、10000と100000のTariffを入力したときのツリー実装と簡単な実装の性能の違いをわざわざテストしました.
データ量
ツリー実装
単純な実装
10,000
16ms
21ms
100,000
198ms
390ms
ツリーのパフォーマンスは、単純な実装よりも確かに優れていることがわかりますが、実際のビジネスでは、一致する見積項目は最大100件を超えず、パフォーマンスにはほとんど差がありません.そのため、コードの読み取りを優先する必要があります.
他の人が書いたコードというコードがあります.プログラマー一人一人がこのコードを読む苦痛な経験をしたことがあると信じています.このような経験を減らすために、私たちは方法、変数の命名にもっと時間と精力を費やすべきではありませんか.コードをもっと簡単に読むべきではありませんか.
今日はCode Reviewの例会の機会を借りて、これらの考えを二叉樹が実現した作者と分かち合い、いくつかの質問に答えました.