ブラックジャックタスクのコメントを整理

タスクもアプリケーションを作成することを忘れないでください。

これまでレーシングカー、宝くじのミッションを行ってきましたが、今回のブラックミッションはドメイン名の理解度が最も低いミッションです.
一度もプレイしたことのないゲームでしたがミッションゲームを見てそのまま回ってきました
結果は以下のように評価された.

実行結果の例は以下の通りですが、このコメントに疑問があるので、再度質問しました.

評論家は、「この目標はブラックジャックゲームを実現することであり、上記の実現事項だけを守るのではない」と話しています.例示に書いてあるのはガイドだけ!
この言葉を聞いて膝がパチパチ!おでこパチ!始まりました.
私が作成したのもアプリケーションです.私はタスクの実現に忙しいので、ユーザーがタスクをより便利に使用し、より面白く楽しむ方法を考えていません.
テイクアウトの民族CEO 金範俊がEOで言った言葉は私に深い印象を残し、その後もこのような開発者になりたいと思っていましたが、目の前の木だけを考えていたので森は見えませんでした.
だから私は反省して、そして努力して开発者になって、私にずっと何が良い制品なのかを悩ませて、私はそれを使ってどんな価値を创造することができます:)

実際のドメイン用語の使用

対象が指す事実と誤解から見ると、対象が指す世界は現実世界の隠喩である.
これは,実際に存在する用語を用いる場合,より容易に理解できるためである.
上のコメントと少し似ていますが、使うドメインの理解を高めることが重要です!

テスト範囲

こんにちはジュディ!体現している部分はよく見えます.
第一段階の仕組みをよく把握しているためか、多くの機能が追加されています.
簡単に悩むことができる部分を残したコメント
そしてテストをしてみると、思ったよりカバー率が低いことがわかりました!
ジュディが考えているドメインの一部でも、少し高いカバー率が必要です.
頼りになるのではないでしょうか.
理解できないコメントや何かあれば、勝手にDM:)
第2段階のコメントを招待してくれてこんなコメントをくれて初めて見た時は表紙が何なのか分からなかったほほほ

そのボタンを押して、アプリを回すと、次のようなテストが行われたかどうかが表示されます.

ドメインのアプローチを100%にするように努力します!
設計からすべてのテストを作成しようと努力していますが、実際に実施すればできないことが多いので、この機能を利用したほうがいいです!

独立判断基準!

1回戦結果の判断基準は以下の通り.

BLACKJACK(1.5, (dealer, gamer) -> gamer.isBlackJack() && !dealer.isBlackJack()),

    WIN(1.0, (dealer, gamer) -> !gamer.isBust()
        && (dealer.calculateResult() < gamer.calculateResult() || dealer.isBust())
    ),
    DRAW(0.0, (dealer, gamer) -> !gamer.isBust()
        && dealer.calculateResult() == gamer.calculateResult()
    ),
    LOSE(-1.0, (dealer, gamer) -> gamer.isBust()
        || (dealer.calculateResult() > gamer.calculateResult() && !dealer.isBust())
    );

そして、勝敗を探す論理は以下の通り.

private static GameResult findResult(final Dealer dealer, final Gamer gamer) {
        return Arrays.stream(values())
            .filter(result -> result.predicate.test(dealer, gamer))
            .findFirst()
            .orElseThrow(() -> new IllegalArgumentException("[ERROR] 존재하는 결과가 없습니다."));
    }

私はENUMの順番で結果を探していたので、私の判断基準には大きな問題はないと思いましたが、評論家から以下のようなコメントをいただき、考え直すきっかけになりました.
この判定基準がprivateとしてカプセル化されていても、各ENUMは独立して使用することができる.
たとえば、この場合、WIN、DRAW、LOSEの順序だけを変更すると、論理がクラッシュする可能性があります.どの症例もすべての状況をカバーするように完全に書かなければならないと思います.どう思いますか?

Collection組み込みメソッドの使用

無知でコードを書くことがある.

private void checkCardSize() {
        if (deck.size() == EMPTY_DECK_SIZE) {
            throw new IllegalStateException("[ERROR] 더이상 카드를 뽑을 수 없습니다.");
        }
    }

上のようにコードdeckを編んだisEmpty()という良い方法があるにもかかわらず,理由もなく不要な定数を作製した.
反省しろジュリリンううう