NEXTSTEP CleanCode JSミッション3-レーシングカーレビュー


前回のミッションウィークの時、私はコロナに閉じ込められた.🤦‍♀️ これは初めてまともな任務を行った.だから多くの面で不足点があり、疑問もたくさんあります.
🔗 PRリンク

🎯 第1段階の要件


車の名前を付けることができます.前進する自動車を出力する場合、自動車名を一緒に出力します.自動車名はカンマ(,)で区切られ、名前は5文字を超えてはならない.ユーザは何回移動するかを入力できる必要がある.所定の回数内に、n台の自動車は前進または停止することができる.
この部分は、動画を入れた場合にSTEP 3のミッションとされていましたが、現在は単独では実現していません!前進の条件は0から9の間でランダム値を求め、ランダム値が4より大きい場合は前進し、3より小さい場合は停止する.

➰ every()


自動車名はカンマ(,)で区切られ、名前は5文字を超えてはならない.
最初は、自動車の名称長が有効かどうかを検証する際に、名称を含む配列を返そうとしたが、各要素の長さが5文字以下のtrue/falseを返し、より良い方法があるかどうかを考えたが、~の前にコード調査で受け取ったフィードバック内容용도에 맞는 배열 메서드를 사용하기だったので、every()を使用したのを覚えている.
function isCheckCarNameLength(carName) {
	return carName.every((item) => item.length <= MAX_CAR_NAME_LENGTH);
}
確かにeveryを使っていて、私が望んでいる意図で動いています.some()every()は実はあまり使ったことがないので、今回の機会に使ってみるといいですね.これからは使う練習をしましょう!

trim()


車の名前をカンマで区切る場合、入力した写真は下の写真と同じなので、名前と名前の間にカンマをつけるとは思いませんでした.

他の人のコードコメントを見て指摘された人もいるので、この部分も修正しました.以前は名前を文字列として入力していたら"EAST, WEST, SOUTH, NORTH".split(", ")というように分かれていましたが、今回は"EAST, WEST, SOUTH, NORTH".split(',').map((item) => item.trim());のように分かれています.この過程で、この関数は2回以上使用され、ユーティリティ部分に分離されます!

➰ Array.from


自動車の前進回数を示す部分は、本来は入力された前進回数に応じて生成され、その後地図で巡回する方式でArray.fromを使用すれば、その部分を減らすことができる.
// 원래 방식
${Array(Number($carTryInput.value))
	.fill(0)
	.map(() =>
		isMoveCar() ? `<div class="forward-icon mt-2">⬇️️</div>` : null
	)
	.join('')}
// 바꾼 방식
${Array.from({ length: Number($carTryInput.value) }, () =>
	isMoveCar() ? `<div  class="forward-icon mt-2">⬇️️</div>` : null
).join('')}
Array.fromはDOM Listのように、似たような配列を本格的な配列に変換する場合以外は使用したことがなく、この方法があることに驚きました.検索すると,長さ属性を表すために配列自体にlengthというキーが用いられていることが分かったが,これがこの原理の要約である.だから連続する数列を作るときはArray.fromで簡単に書くことができます…!😶

🧪 アラートのテスト


Cypressでalertをテストする際,公平なプログラミングでstubの使用を習得した.ここでto.be.calledWithでフィルタリングするとalert内のメッセージを検証できます!
it('자동차의 이름이 5글자를 초과하면 경고창을 띄워준다.', () => {
    const alertStub = cy.stub();
    cy.on('window:alert', alertStub);

    cy.get('#car-names-input').type('EASTTT, WEST, SOUTH, NORTH');
    cy.get('#car-names-submit')
        .click()
        .then(() => {
            expect(alertStub.getCall(0)).to.be.calledWith(
                ERR_MSG.OVER_CAR_NAME_MAX_LENGTH
            );
        });
});

📝 コメント


コードを書く過程で,構造に多くの悩みが生じた.
  • 素子で記述するが、素子の回収性や複雑な構造からの利点は少ない、
  • .
  • ですが、それを教室に集中するにはclassを使う必要がありますか?と思います.
  • だから各関数を分けて、イベントがトリガーされると、関数を呼び出すように書きます.STEP 1段階はこのように書いても大丈夫ですが、あとでもう少し機能を増やせば、この仕組みはあまり良くないはずなので、他の人の仕組みを参考にしました.MVCを応用している人もいれば、ドメインを基準に設計している人もいますが、ここでドメインの概念は私にとって曖昧なので、評論家に聞きました.

    ドメイン


  • ドメイン
    💡 ドメインは、現在解決すべき問題(ビジネスドメイン)です.
  • 隔離ドメイン
    まず、すべての要件を表示し、必要なドメインを考慮します.
    レーシングカーゲームを例にとると、
  • を走行できる車です.
    -勝利者を特定するために自動車を管理するためのドメイン
  • ここですべてを解決できるでしょう?
  • ドメインの特定のデータの管理と方法によって役割の責任を分担することを目的としています.
  • 要するに、ドメインを分割する目的は、次のとおりです.
    責任を分担することで、ドメインに個別の責任と役割を割り当て、メンテナンスの効率を向上させます.
    この点.
    説明は分かりやすいのですが、やはり概念があいまいな感じがするので、前に買った対象向けの事実や誤解の中で、ドメイン名についての部分だけ読んでいて、その中で印象的な文章がありました.
    残念なことに、要求事項が変更されます.ソフトウェアの分野では、例外のない唯一のルールは、常に変更することです.
    ... (中略)
    将来に対応する最善の方法は、変更を予測することではなく、設計に変更を許容できる選択の余地を提供することである.優秀なデザイナーは、将来どのような変化が起こるか予測しません.
    良いデザインは後で変更できる余地を残したデザインです.変更に対応するために余地を残す最善の方法は、頻繁に変更する可能性を中心としてではなく、安定した構造を中心に設計することである.
    p.182
    ユーザがプログラムを使用するターゲット領域をドメインと呼ぶ.ドメインモデルは,ソフトウェア目的分野における概念と概念の関係,各種規則や制約などを深く抽象化している.
    ソフトウェアオブジェクトは現実オブジェクトに対する抽象ではないことを改めて強調した.ソフトウェアオブジェクトと現実オブジェクトの関係を最も効果的に表現できる言葉は隠喩である.
    ... (中略)
    では、私たちが隠喩で投影すべきオブジェクトは何ですか?それはユーザがドメインの概念を考えることである.すなわち,ソフトウェアオブジェクトを作成するために,隠喩が必要なオブジェクトはドメインモデルである.
    p.188
    読んでみると、ドメイン名の概念もよく分かりませんが、いろいろな面でいい文章がたくさんあって、感嘆しながら読みました.前の章は読んでいませんが、ドメイン名の内容のある章だけを読んでいますが、他の部分を早く読みたいという良い話もたくさんあります...!

    テストコード


    また,テストコードを作成する際にも,多くの悩みがある.
  • どの部分をテストして、どこまでテストしますか?
  • のテストコードの重複性を減らすにはどうすればいいですか?
  • この部分も親切に答えてくれたというコメントがありました

    最初の問題では、結果値が予想される形で発生/プロセスに基づいてテストされた場合、正常に増加/正常なプロセスを超えた場合、異常処理をうまく行うことができますか?同じ部分だと言います.しかし、実際の作業でこれらの部分を一つ一つテストすると、テストコードや要求が増えていきますが、よろしいでしょうか.私はあなたに質問しました.あなたは単位テストを使うかもしれません.これらの話を聞いて、ユニットテストにも興味を持ちました!
    また、重複を減らす場合は、beforeEachを使用して事前に重複タスクを実行したり、Commands機能を使用したり、複数の部分を使用したりすることができます.

    終了後


    実はSTEP 1はまだタスクが終わっていないのですが、2回目に評価を受けたら、修正が必要なところがあるはずなので、事前に回顧記事をアップしておきました.今回のタスクを行う過程で,도메인という概念に興味を持ち,テストコードの考慮事項や様々な問題に悩み,収穫が豊富であった.これはとても面白い経験です.😊😊
    また、今回のミッションでは、時間を延ばして急いで行うのが嫌なので、チェックを作り、各機能管理状態のスケジュール管理を行いました.確かに、このようにして遅延を減らして、任務の負担を軽減して、本当に嬉しいです!


    このように管理する.
    いろいろ勉強しなければならないステップだったので、とても面白かったです.終わりだ!