[정찬욱] 로또 미션 Step2 #8
Conversation
WalkthroughThe project has shifted from a Car Racing Mission to a Lotto Mission, encompassing updates in various files to support this change. This includes modifications to README, test scripts, and the implementation of new classes for managing lotto functionalities such as ticket generation, result calculation, and user interaction. The new functionalities are backed by extensive test suites to ensure accuracy and reliability. Changes
Sequence DiagramsLotto Purchase FlowsequenceDiagram
participant User
participant InputManager
participant LottoMachine
participant OutputManager
User->>InputManager: Enter purchase amount
InputManager->>LottoMachine: Create lotto machine with amount
LottoMachine->>LottoMachine: Generate lottos
LottoMachine->>OutputManager: Display purchased lottos
OutputManager->>User: Show purchased lottos
Lotto Winning Calculation FlowsequenceDiagram
participant User
participant InputManager
participant LottoMachine
participant LottoMatcher
participant LottoReturnCalculator
participant OutputManager
User->>InputManager: Enter winning numbers
InputManager->>LottoMatcher: Calculate matching lottos
LottoMatcher->>LottoReturnCalculator: Calculate return rate
LottoReturnCalculator->>OutputManager: Display winning results
OutputManager->>User: Show winning results
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range, codebase verification and nitpick comments (2)
src/utils/getUserFriendlyErrorMessage.js (1)
1-8: Consider using optional chaining.The
getUserFriendlyErrorMessagefunction is correctly implemented. However, you can simplify the code by using optional chaining.- const errorCode = match && match[1]; + const errorCode = match?.[1];Tools
Biome
[error] 3-3: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/service/outputManager.js (1)
12-19: Improve thetypeofcheck.The
typeofcheck forprocessFncan be improved by using a more explicit check for function type.- typeof processFn === "function" ? processFn(value) : value; + typeof processFn === 'function' ? processFn(value) : value;
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (40)
- README.md (1 hunks)
- package.json (1 hunks)
- src/tests/Lotto.test.js (1 hunks)
- src/tests/LottoMachine.test.js (1 hunks)
- src/tests/LottoMatcher.test.js (1 hunks)
- src/tests/LottoNumber.test.js (1 hunks)
- src/tests/LottoReturnCalculator.test.js (1 hunks)
- src/tests/WinningLotto.test.js (1 hunks)
- src/constants/errorMessage.js (1 hunks)
- src/constants/index.js (1 hunks)
- src/constants/lotto.js (1 hunks)
- src/controller/calculateWinningResults.js (1 hunks)
- src/controller/createWinningLotto.js (1 hunks)
- src/controller/handleErrorAndPrint.js (1 hunks)
- src/controller/index.js (1 hunks)
- src/controller/purchaseLottos.js (1 hunks)
- src/controller/shouldRestartGame.js (1 hunks)
- src/main.js (1 hunks)
- src/model/Lotto.js (1 hunks)
- src/model/LottoMachine.js (1 hunks)
- src/model/LottoMatcher.js (1 hunks)
- src/model/LottoNumber.js (1 hunks)
- src/model/LottoReturnCalculator.js (1 hunks)
- src/model/WinningLotto.js (1 hunks)
- src/model/index.js (1 hunks)
- src/service/index.js (1 hunks)
- src/service/inputManager.js (1 hunks)
- src/service/outputManager.js (1 hunks)
- src/utils/arrayUtils.js (1 hunks)
- src/utils/formatKoreanCurrency.js (1 hunks)
- src/utils/formatNumber.js (1 hunks)
- src/utils/getUserFriendlyErrorMessage.js (1 hunks)
- src/utils/index.js (1 hunks)
- src/utils/isDuplicated.js (1 hunks)
- src/utils/readLineAsync.js (1 hunks)
- src/utils/retryOnFailureAsync.js (1 hunks)
- src/utils/validate.js (1 hunks)
- src/view/index.js (1 hunks)
- src/view/showPurchasedLottos.js (1 hunks)
- src/view/showWinningResults.js (1 hunks)
Files skipped from review due to trivial changes (11)
- README.md
- src/constants/index.js
- src/constants/lotto.js
- src/controller/handleErrorAndPrint.js
- src/controller/index.js
- src/model/index.js
- src/service/index.js
- src/utils/formatKoreanCurrency.js
- src/utils/index.js
- src/view/index.js
- src/view/showPurchasedLottos.js
Additional context used
Biome
src/utils/getUserFriendlyErrorMessage.js
[error] 3-3: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/utils/validate.js
[error] 9-9: Invalid
typeofcomparison value: this expression is not a string literalnot a string literal
(lint/suspicious/useValidTypeof)
src/model/LottoMatcher.js
[error] 63-63: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
Additional comments not posted (84)
src/utils/isDuplicated.js (1)
1-7: LGTM!The
isDuplicatedfunction is correctly implemented and efficiently checks for duplicates in an array.src/utils/formatNumber.js (1)
1-5: LGTM!The
formatNumberfunction is correctly implemented and efficiently formats the number to the specified number of digits.src/utils/retryOnFailureAsync.js (1)
1-11: LGTM!The
retryOnFailureAsyncfunction is correctly implemented and efficiently retries the asynchronous function on failure.src/constants/errorMessage.js (4)
2-3: LGTM!The error message is clear and provides specific instructions.
4-4: LGTM!The error message is clear and provides specific instructions.
5-6: LGTM!The error message is clear and provides specific instructions.
7-7: LGTM!The error message is clear and provides specific instructions.
package.json (2)
6-6: LGTM!The addition of the "type" field is appropriate for enabling ECMAScript modules.
10-11: LGTM!The addition of the test scripts is appropriate and follows best practices.
src/controller/shouldRestartGame.js (2)
3-7: LGTM!The function is straightforward and correctly handles user input.
11-17: LGTM!The function is straightforward and correctly handles user input.
src/utils/arrayUtils.js (2)
1-15: LGTM!The function is straightforward and correctly generates the array.
17-22: LGTM!The function is straightforward and correctly shuffles the array.
src/service/inputManager.js (3)
1-2: Import statement looks good.The import statement correctly imports
readLineAsyncfrom the utils.
3-15: Class and methods are well-implemented.The
InputManagerclass and its methods are implemented correctly. Thescanmethod handles asynchronous input and processes it with a callback function if provided.
17-19: Exporting an instance is appropriate.Exporting an instance of
InputManageris a good approach for singleton usage.src/__tests__/LottoReturnCalculator.test.js (2)
1-2: Import statements look good.The import statements correctly import the necessary modules for testing and the
LottoReturnCalculatorclass.
4-19: Test suite is well-implemented.The test suite correctly verifies the calculation of the rate of return. The test data and assertions are appropriate.
src/controller/calculateWinningResults.js (3)
1-2: Import statements look good.The import statements correctly import the necessary constants and classes.
4-12: Function implementation looks good.The
calculateWinningResultsfunction correctly calculates the winning counts and rate of return. The logic is clear and appropriate.
14-14: Export statement looks good.The export statement correctly exports the
calculateWinningResultsfunction.src/utils/readLineAsync.js (3)
1-2: Import statement looks good.The import statement correctly imports the
readlinemodule.
3-19: Function implementation looks good.The
readLineAsyncfunction correctly handles asynchronous reading of input. The error handling for non-string queries is appropriate.
21-21: Export statement looks good.The export statement correctly exports the
readLineAsyncfunction.src/utils/validate.js (1)
1-5: LGTM!The function
throwErrorWithConditionis implemented correctly.src/service/outputManager.js (3)
4-6: LGTM!The constructor is implemented correctly.
8-10: LGTM!The
21-23: LGTM!The
linebreakmethod is implemented correctly.src/main.js (3)
1-7: LGTM!The import statements are correct.
9-22: Add a validity check for thepurchaseLottosresponse.Ensure that the response from
purchaseLottosis valid before proceeding.- const { count, lottos } = await purchaseLottos(); + const { count, lottos } = await purchaseLottos(); + if (!count || !lottos) { + throw new Error('Invalid response from purchaseLottos'); + }
23-23: LGTM!The main function invocation is correct.
src/controller/purchaseLottos.js (3)
1-4: LGTM!The import statements are correct.
6-18: Add input validation for the scanned value.Ensure that the input value is a valid number before converting it.
- const trimedInputValue = inputValue.trim(); + const trimmedInputValue = inputValue.trim(); + if (isNaN(trimmedInputValue) || trimmedInputValue <= 0) { + throw new Error('Invalid input value'); + } - return Number(trimedInputValue); + return Number(trimmedInputValue);
23-23: LGTM!The export statement is correct.
src/model/WinningLotto.js (3)
7-13: Constructor looks good!The constructor correctly initializes the
WinningLottoclass and validates the bonus number.
15-17: Getter method looks good!The getter method correctly returns the value of the
#bonusNumberproperty.
19-24: Validation method looks good!The static method correctly validates that the bonus number is not duplicated in the winning numbers.
src/__tests__/WinningLotto.test.js (2)
5-12: Test case for bonus number validation looks good!The test case correctly checks that an error is thrown if the bonus number is duplicated in the winning numbers.
14-21: Test case for bonus number retrieval looks good!The test case correctly checks that the bonus number can be retrieved.
src/view/showWinningResults.js (1)
5-21: Function looks good! Verify the necessity of thereversemethod.The function correctly displays the winning results and rate of return using the
outputManager. Verify if thereversemethod is necessary onLOTTO.RANKING_INFO.Verification successful
The
reversemethod is necessary.The
RANKING_INFOarray is defined in descending order by default. Thereversemethod is used to iterate over the array in ascending order, which is necessary for displaying the results correctly.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify if the `reverse` method is necessary on `LOTTO.RANKING_INFO`. # Test: Check the sorting order of `LOTTO.RANKING_INFO`. Expect: Already sorted in the required order. rg --type js 'RANKING_INFO' -A 5Length of output: 1419
Script:
#!/bin/bash # Extract the complete definition of `RANKING_INFO` from `src/constants/lotto.js`. rg 'RANKING_INFO' -A 10 src/constants/lotto.jsLength of output: 256
Script:
#!/bin/bash # Extract more lines from `src/constants/lotto.js` to get the complete definition of `RANKING_INFO`. rg 'RANKING_INFO' -A 50 src/constants/lotto.jsLength of output: 516
src/model/LottoNumber.js (3)
7-11: Constructor looks good!The constructor correctly initializes the
LottoNumberclass and validates the number.
13-15: Getter method looks good!The getter method correctly returns the value of the
#numberproperty.
17-31: Validation method looks good!The static method correctly validates that the number is an integer and within the valid range.
src/model/LottoReturnCalculator.js (3)
1-12: LGTM!The constructor and class properties are correctly implemented.
14-16: LGTM!The
rateOfReturnmethod is correctly implemented.
18-32: LGTM!The static methods
#calcRateOfReturnand#getPrizeMoneyare correctly implemented.src/model/Lotto.js (3)
1-16: LGTM!The constructor and class properties are correctly implemented.
18-20: LGTM!The
numbersmethod is correctly implemented.
22-37: LGTM!The static method
#validateNumbersis correctly implemented.src/__tests__/Lotto.test.js (4)
1-19: LGTM!The test cases for invalid constructor arguments are correctly implemented.
21-25: LGTM!The test case for constructor argument length exceeding 6 is correctly implemented.
27-31: LGTM!The test case for constructor argument length less than 6 is correctly implemented.
33-37: LGTM!The test case for retrieving lotto numbers is correctly implemented.
src/__tests__/LottoNumber.test.js (4)
1-20: LGTM!The test cases for invalid constructor arguments are correctly implemented.
22-26: LGTM!The test case for constructor argument less than 1 is correctly implemented.
28-32: LGTM!The test case for constructor argument greater than 45 is correctly implemented.
34-40: LGTM!The test case for setting lotto number is correctly implemented.
src/__tests__/LottoMachine.test.js (4)
5-8: LGTM!The test case correctly checks for an error when a non-integer value is passed to the
LottoMachineconstructor.
11-14: LGTM!The test case correctly checks for an error when a value less than 1000 is passed to the
LottoMachineconstructor.
17-29: LGTM!The test case correctly checks if the correct number of lottos are issued for various input prices using
test.each.
31-37: LGTM!The test case correctly checks if a lotto contains 6 numbers.
src/model/LottoMachine.js (5)
13-26: LGTM!The constructor and properties correctly initialize the
LottoMachineand provide access to the number of lottos and the lottos themselves.
28-37: LGTM!The
#validatePricemethod correctly validates that the price is an integer and is at least 1000.
40-42: LGTM!The
#countLottomethod correctly calculates the number of lottos that can be purchased with the given price.
44-53: LGTM!The
#createLottosand#createLottomethods correctly create an array of lottos and generate a single lotto with sorted numbers.
55-59: LGTM!The
#getLottoNumbersmethod correctly generates a shuffled array of lotto numbers.src/model/LottoMatcher.js (5)
6-15: LGTM!The constructor and properties correctly initialize the
LottoMatcherand provide access to the winning counts.
17-35: LGTM!The
#calculateWinningCountsmethod correctly calculates the winning counts for the given lottos and winningLotto.
37-39: LGTM!The
#getMatchingCountmethod correctly calculates the number of matching numbers between a lotto and the winningLotto.
42-44: LGTM!The
#updateWinningCountsmethod correctly updates the winning counts based on the lotto match results.
46-53: LGTM!The
#updateCountsmethod correctly updates the counts based on the matching count and bonus match.src/controller/createWinningLotto.js (5)
6-15: LGTM!The
createWinningLottofunction correctly usesretryOnFailureAsyncto create a winning lotto with retry logic.
19-26: LGTM!The
retryCreateWinningNumbersfunction correctly usesretryOnFailureAsyncto create winning numbers with retry logic.
28-41: LGTM!The
createWinningNumbersfunction correctly handles user input for winning numbers and creates aLottoinstance.
44-51: LGTM!The
retryCreateBonusNumberfunction correctly usesretryOnFailureAsyncto create a bonus number with retry logic.
53-65: LGTM!The
createBonusNumberfunction correctly handles user input for the bonus number and creates aLottoNumberinstance.src/__tests__/LottoMatcher.test.js (8)
1-8: Imports look good!The import statements are correctly added and necessary for the test cases.
10-28: Test case looks good!The test case correctly verifies the properties and types of the
winningCountsobject.
30-37: Test case looks good!The test case correctly verifies the first-place winning count.
39-46: Test case looks good!The test case correctly verifies the second-place winning count.
48-55: Test case looks good!The test case correctly verifies the third-place winning count.
57-64: Test case looks good!The test case correctly verifies the fourth-place winning count.
66-73: Test case looks good!The test case correctly verifies the fifth-place winning count.
76-85: Function looks good!The
createLottoMachineMockfunction correctly creates a mock LottoMachine with the provided lotto numbers.
| static #getRanking(matchingCount, isBonusMatch) { | ||
| const currentInfo = LOTTO.RANKING_INFO.find( | ||
| (info) => | ||
| info.matchingCount === matchingCount && | ||
| Boolean(info.isBonusMatch) === isBonusMatch | ||
| ); | ||
|
|
||
| return currentInfo && currentInfo.ranking; |
There was a problem hiding this comment.
Use optional chaining for better readability.
The #getRanking method can be improved by using optional chaining.
- return currentInfo && currentInfo.ranking;
+ return currentInfo?.ranking;Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| static #getRanking(matchingCount, isBonusMatch) { | |
| const currentInfo = LOTTO.RANKING_INFO.find( | |
| (info) => | |
| info.matchingCount === matchingCount && | |
| Boolean(info.isBonusMatch) === isBonusMatch | |
| ); | |
| return currentInfo && currentInfo.ranking; | |
| static #getRanking(matchingCount, isBonusMatch) { | |
| const currentInfo = LOTTO.RANKING_INFO.find( | |
| (info) => | |
| info.matchingCount === matchingCount && | |
| Boolean(info.isBonusMatch) === isBonusMatch | |
| ); | |
| return currentInfo?.ranking; |
Tools
Biome
[error] 63-63: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
| export const validate = { | ||
| type(value, typeValue, errorMessage) { | ||
| throwErrorWithCondition(typeof value !== typeValue, errorMessage); | ||
| }, |
There was a problem hiding this comment.
Fix the typeof comparison.
The typeof comparison should use string literals.
- throwErrorWithCondition(typeof value !== typeValue, errorMessage);
+ throwErrorWithCondition(typeof value !== typeValue.toLowerCase(), errorMessage);Committable suggestion was skipped due to low confidence.
Tools
Biome
[error] 9-9: Invalid
typeofcomparison value: this expression is not a string literalnot a string literal
(lint/suspicious/useValidTypeof)
AI가 해주는 리뷰입니다1. 코드 분석이 Pull Request는 로또 게임의 기본 구조를 구현하고 있습니다. 주요 특징은 다음과 같습니다:
2. 강점
3. 개선점
4. 구체적 제안
5. 학습 포인트
6. 향후 요구사항 변경 대비
이러한 방식으로 코드를 구조화하면, 향후 요구사항 변경에 더욱 유연하게 대응할 수 있을 것입니다. |
AI가 해주는 궁금한 점에 대한 답변입니다.1. 레이어전반적으로 레이어 구분이 잘 되어 있습니다. 하지만 몇 가지 개선할 점이 있습니다:
2. 가독성전반적으로 메서드 이름과 순서는 이해하기 쉽고 논리적입니다. 몇 가지 제안:
3. 분리코드가 이미 잘 분리되어 있지만, 다음과 같은 추가 분리를 고려해 볼 수 있습니다:
이러한 추가 분리는 코드의 책임을 더욱 명확히 하고, 테스트와 유지보수를 용이하게 만들 수 있습니다. 하지만 과도한 분리는 복잡성을 증가시킬 수 있으므로, 프로젝트의 규모와 요구사항을 고려하여 적절한 수준의 분리를 결정해야 합니다. |
suyeon1218
left a comment
suyeon1218
left a comment
There was a problem hiding this comment.
안녕하세요 찬욱님...!! 찬욱님의 코드에선 controller를 유심히 봤습니다...! controller를 파일별로 분리하는 시도도 신기했는데 이건 이것 나름대로 잘 읽히는 것 같아요..! 도메인을 여러개로 나눠서 각각의 역할을 확실하게 분리하려고 한게 눈에 띕니다 ㅎㅎ! 열심히 고민하신 흔적인 것 같아요. AI리뷰는...찬욱님이 보시기엔 쓸만하신 것 같나요...?! (아직 못봄...)
예외처리 위치 정하기
- 어떤 한계가 있었나요...?! 이렇게 쓰면 모든 input을 한번씩 다 래핑하면서 retry가 붙는 메서드 이름을 한번씩 다 만들어줘야 한다는 부분은 단점이 될 수도 있을 것 같아요. 에러처리의 한계를 극복하면서 외부에서 일일이 래핑하지 않아도 되는 방법은 없을까요...!
MVC 패턴
- 찬욱님은 input과 관련한 건 모두 controller에 넣었는데...저는 view에 넣었습니다...! React에서 input을 받는다고 하면 Input컴포넌트를 통해 받는 걸 생각했는데 찬욱님 생각은 어떠신가요?
가독성
- LottoMatcher를 읽을때 최초의 큰 함수에서 다른 함수로 계속 이동해가며 로직을 처리한다는 느낌을 받았어요. 함수가 하나의 역할만 하도록 분리하는 측면에선 매우 잘 분리하신 것 같은데, 이렇다 보니 처음 코드에서 반환받는 값은 결국 가장 아래있는 함수를 통해 받는 거니까... 어떤 값이 들어오게 될지 유추가 잘 안되는 단점도 있는 것 같아요. 함수를 역할별로 분리하면서 반환값을 유추할 수 있게 하는 게 너무 어려운 것 같아요...
레이어
각 도메인이 가진 역할 자체는 잘 분리했다는 생각이 듭니다! 정말 꼼꼼히 분리하셔서 이렇게도 분리할 수 있겠구나 감탄하면서 본 것 같아요!!
| const showPurchasedLottos = (count, lottos) => { | ||
| outputManager.print(`${count}개 구매했습니다.`); | ||
| outputManager.printAll(lottos, (lottos) => lottos.numbers); | ||
| }; |
There was a problem hiding this comment.
뷰에서 도메인을 몰라야 하는 게 MVC의 원칙이라고 알고 있어요...! 그런데 여기선 lottos의 numbers를 참조하게 되면 도메인이 어떻게 이뤄져 있는지를 View가 알고 있다고 가정하게 되는 것 아닐까요...!
There was a problem hiding this comment.
아 맞네요.. 중요한 부분 알려주셔서 감사합니다!
| export const range = (start, end) => { | ||
| if (end === undefined) { | ||
| end = start; | ||
| start = 0; | ||
| } |
| const length = end - start; | ||
| const result = Array(length); | ||
|
|
||
| for (let i = 0; i < length; i++) { | ||
| result[i] = start + i; | ||
| } |
There was a problem hiding this comment.
이런 방식으로도 사용할 수 있을 것 같아요!
const result = [];
while (start < end) {
result.push(start);
start += 1;
}아니면 이런 방식...?
const length = end - start;
return [...new Array(length)].map((el, index) => el = start + index);There was a problem hiding this comment.
ㅎㅎ 사실 저 코드의 비밀은 ai에게 가장 빠른 속도를 가진 range 함수를 만들어달라고 했을 때 알려준 코드랍니다.
그래서 실제로 맞는지 테스트해보니까 저렇게 미리 배열을 만들어놓고 해당 인덱스에 입력하는게 속도가 빠르더라구요!
| ERR_001: | ||
| "입력하신 값은 로또 번호로 사용할 수 없습니다. 1부터 45 사이의 숫자를 입력해 주세요.", |
There was a problem hiding this comment.
에러를 번호로 구분하게 되면 에러를 명시적으로 작성하는 것과 달리 어떤 장점이 있나요?
There was a problem hiding this comment.
이렇게하면 개발자용 에러 메세지랑 사용자용 에러 메세지를 에러 코드를 통해 관리할 수 있어요!
| { | ||
| ranking: 1, | ||
| matchingCount: 6, | ||
| prizeMoney: 2_000_000_000, | ||
| }, | ||
| { | ||
| ranking: 2, | ||
| matchingCount: 5, | ||
| isBonusMatch: true, | ||
| prizeMoney: 30_000_000, | ||
| }, |
There was a problem hiding this comment.
isBonusMatch를 사용하지 않는다면 false를 명시하는 게 일관성을 해치지 않지 않을까요?!
There was a problem hiding this comment.
저도 처음에는 그렇게 작성했는데 ai들이 없어도 된다고 해서...
There was a problem hiding this comment.
controller를 여러개로 분리해놓으셨군요...! 이런 방법도 있을 수 있겠네요 🤔
There was a problem hiding this comment.
사실 좋은 방법인지는 모르겠지만 지금거에서 좀더 수정해서 하나의 작업단위로 분리를 해볼까 합니다!
| return LottoMatcher.#updateWinningCounts(lottoMatchResults, initialCounts); | ||
| } |
There was a problem hiding this comment.
initialCounts를 calculateWinningCounts에선 사용하지 않고 updateWinningCounts로 넘겨준다면 updateWinningCounts에서 선언해도 되지 않을까요!
There was a problem hiding this comment.
그래도 되긴하지만..! update하는 함수니까 값의 초기값을 들고 있는건 뭔가 안맞지 않을까 생각이 듭니다!
| static #getMatchingCount(lottoNumber, winningLottoNumber) { | ||
| return lottoNumber.filter((number) => winningLottoNumber.includes(number)) | ||
| .length; | ||
| } |
There was a problem hiding this comment.
오홍... 이렇게 선언형으로도 일치하는 번호의 개수를 카운트해줄 수도 있군요
| if (ranking) { | ||
| counts[ranking] += 1; | ||
| } |
There was a problem hiding this comment.
getRanking에서 어떤 값을 반환하는지 궁금해지게 하는 제어문인것 같아요...!
| constructor(price) { | ||
| LottoMachine.#validatePrice(price); | ||
|
|
||
| const count = LottoMachine.#countLotto(price); |
There was a problem hiding this comment.
어떤 count인지 처음읽을 때 헷갈려서 함수를 보고 나서 이해할 수 있었던 것 같아요...! lottoCount 혹은 purchasingCount 등으로 구매개수라는 사실을 명확히 나타내는 건 어떨까요?
There was a problem hiding this comment.
로또 기계가 뭘하는지 보고 한번에 알긴 어렵겠군요..
3 participants
추가 요구사항 구현 목록
미션을 수행하면서 어려웠던 점
기존에는
inputManager의retyrScan메서드의 콜백에서 에러를 처리하는 형식으로 했었는데, 이렇게 구현하다보니 예외 처리에 한계를 느꼈습니다. 그래서retryOnFailureAsync라는 메서드를 만들어서 외부에서 처리를 해줄 수 있게 수정했는데, 이게 맞는지 애매하네요...shouldRestartGame,handleErrorAndPrint메서드를 어디에 넣는게 좋을지 고민을 많이 했네요.리뷰 받고 싶은 부분 & 궁금한 점
각 레이어에 속한 함수나 클래스의 위치가 괜찮은지 의견 공유 부탁드립니다.
클래스 내부의 메서드들 혹은 파일의 메서드들의 나열된 순서가 코드를 읽을때 괜찮은지, 이름은 이해가 되는지 궁금합니다!
최대한 분리를 했지만 더 분리할 코드가 있을까요?
어떤 지점에서 재미를 많이 느끼는지, 희열을 많이 느끼는지, 몰입을 많이 하는지
사실 코딩하면서 재미와 희열까지 느껴본 기억은 없는듯하고, 구현을 끝내거나 코드 정리가 깔끔하게 되면 뿌듯함을 느낍니다.
하기 싫지 않은 상태에서 특정 시간 내에 끝낼 수 있을 정도의 목표를 정하고 일을 시작하면 몰입이 되는 것 같아요.
Summary by CodeRabbit
New Features
Tests
Scripts
package.jsonfor better test management.Documentation