[2단계 - 행운의 로또 미션] 크리스(이송원) 미션 제출합니다. #54

swon3210 · 2021-02-26T12:49:18Z

STEP 2

데모 사이트 : https://swon3210.github.io/javascript-lotto/

🎯 step2 에서 추가된 기능

당첨 번호와 보너스 번호를 입력할 수 있다.
- 로또 번호들 중 중복된 번호가 있으면 안내메시지를 출력한다.
- 로또 번호들 중 1 ~ 45 사이의 숫자가 아닌 숫자가 있다면 안내메시지를 출력한다.
결과 확인하기 버튼을 누르면 당첨 통계, 수익률을 모달로 확인할 수 있다.
- 당첨 번호와 보너스 번호를 입력하지 않으면 안내메세지를 출력한다.
다시 시작하기 버튼을 누르면 초기화 되서 다시 구매를 시작할 수 있다.

🔧 step2 에서 추가된 테스트

입력된 번호들 중 중복된 번호가 있다면 안내메세지를 출력한다.
입력된 번호들 중 1 ~ 45 사이의 숫자가 아닌 숫자가 있다면 안내메시지를 출력한다.
당첨번호가 모두 입력되지 않으면 결과를 확인할 수 없다.
결과 확인 버튼을 누르면, 당첨 통계, 수익률을 보여준다.
다시 시작하기 버튼을 누르면, 로또게임이 초기화된다.

❗ step2 에서 추가된 컨벤션

클래스에서 속성명 앞에 _ 가 붙여진 것은 해당 속성이 protected 속성임을 뜻하며 인스턴스 외부에서 해당 속성을 수정해서는 안됩니다.
클래스에서 속성명 앞에 # 가 붙여진 것은 해당 속성이 private 속성임을 뜻하며 상속이 수행된 클래스 내부에서도 해당 속성을 사용하려 해서는 안됩니다.
어떤 인스턴스에 pascal case 표기된 속성이 있다면 해당 속성이 사실 getter 임을 뜻합니다. 이를 조작하려는 시도를 하지 않도록 유의해주십시오.

🖼️ 구조도

📁 디렉터리 구조

📦src
 ┣ 📂lotto
 ┃ ┣ 📂validation
 ┃ ┃ ┣ 📜validationResult.js
 ┃ ┃ ┗ 📜validator.js
 ┃ ┣ 📜controller.js
 ┃ ┣ 📜domReader.js
 ┃ ┣ 📜LottoGame.js
 ┃ ┣ 📜service.js
 ┃ ┗ 📜view.js
 ┣ 📂utils
 ┃ ┣ 📜calculate.js
 ┃ ┣ 📜format.js
 ┃ ┣ 📜querySelector.js
 ┃ ┗ 📜random.js
 ┣ 📜constants.js
 ┣ 📜elements.js
 ┣ 📜index.js
 ┣ 📜store.js
 ┗ 📜templates.js

중점을 둔 부분

이전에 조언해 주신 CSS 클래스 모듈화를 이번에 적용시켜보았습니다.
이리저리 흩어져 있는 상수들을 LOTTO 와 같은 하나의 객체로 묶는 식으로 분류를 시도했습니다. 이때 모듈화시킨 CSS CLASS 와 element 를 가져올 때 사용하는 SELECTOR 또한 상수화시키고 객체로 묶었습니다.
핸들러와 유효성 검사 로직을 다른 객체로 분리하지 않고 controller 객체에게 담당시켰습니다. 이때, controller 가 비대해지는 것을 막고자 model 과 view 를 연결하는 일을 service 객체를 따로 두어 맡겼습니다.
마찬가지로 controller가 비대해지는 것을 막고자, validator 의 여러 원자화 되어 있는 유효성 검사를 바로 가져와서 사용하기 보다 '구매금액 입력값 체크 결과', '로또 번호 입력 체크 결과'와 같이 추상화된 체크 동작을 수행하는 validationResult 객체를 따로 두어 controller 가 사용하게 하였습니다.
따로 어떠한 view 조작 역할도 수행하지 않고 단순히 사용자의 화면상에 있는 데이터 정보만을 가져오는 로직을 domReader.js 파일 안에서 따로 관리하도록 하였습니다.

궁금한 점

service 와 validationResult 를 통해 controller가 비대해지는 것을 막으려던 시도가 충분히 유지보수 측면에서 유효하다고 생각하시나요?
view 를 조작하지 않고 단순히 화면(DOM) 상의 데이터만을 불러오는 함수는 view 에 담아야 하는건가요? 아니면 제가 한 것처럼 완전히 별도로 분류해두는 것이 좋을까요?

…lotto into chris

Vallista

안녕하세요 크리스님! 2단계 행운의 로또 미션 수고 많으셨습니다!

상세한 설명과 함께 디렉터리 구조, 스트럭쳐를 잘 정리해주셔서 쉽게 리뷰할 수 있었습니다!! 정말 감사합니다!
코드 라인 단위로 크게 수정할 것은 보이지 않아서, 3단계를 진행하시면서 아래의 피드백을 적용해주시면 좋을 것 같습니다!

아래는 전반적인 피드백입니다. 👍

메소드나 함수가 전반적으로 parameter가 온전히 들어올 것이라 가정하고 짜여진 코드가 많이 보였습니다! javascript는 타입이 느슨하여, parameter가 이상하게 들어올 수 있는 확률이 굉장히 높습니다. 그래서 해당 부분에 대해서 안전하게 코드를 작성하시면 좋을 것 같아요!
테스트 코드에 중복적으로 사용되는 일렬의 코드 패턴이 보였습니다! 해당 부분은 함수로 분리하여 중복된 로직을 줄이면 좋을 것 같습니다! 또한, 기능에 대한 테스트와 레이아웃에 대한 테스트로 분리를 하거나 도메인 단위로 테스트를 분리하면 좋을 것 같아요! 추후에 로직이 길어지면 확인하기 어려워 질 것 같습니다!
css id, class의 네이밍 규칙이 일관적이지 않아보입니다! BEM 방법론을 이용해 이름의 포멧을 가져가는 건 어떨까요?
private, protected, public이 class 내에서 순서가 있었으면 좋겠습니다! 이 부분은 상세 코드에 라인으로 리뷰를 남겼습니다! 참고해주세요!
전반적으로 잘 코드가 역할별로 구분이 되어 있어서 좋았습니다!!! 👏 👏 👏 점점 성숙해지는 코드를 작성하고 계시는군요!!! 💯 💯

아래는 궁금한 점에 대한 답변입니다!

service 와 validationResult 를 통해 controller가 비대해지는 것을 막으려던 시도가 충분히 유지보수 측면에서 유효하다고 생각하시나요?

일반적으로 알고잇는 service layer pattern의 개념은 아닌 것 같긴 합니다! 더 다양한 도메인이 있을때, 도메인 단위로 나누고자 할 때 service layer로 분리하곤 하는데요, 지금의 역할은 controller에서 로직을 1차적으로 분리하는 역할을 하는 것 같아요. 하지만 이렇게 하면 controller, service 파일 두 개를 왔다 갔다 하면서 수정해야할 것 같습니다! 그래서, controller가 비대해지는 걸 막는 용도로 추가 프로세스를 만들기보단, controller 폴더를 만들어, 하위의 모듈을 만들어 controller에서 모듈을 관리하는 형태의 레이어를 구현해서 비대해지는 것을 수직적이 아닌, 수평적 확장으로 가져가는게 좋아보입니다!
validationResult의 경우 validator.js는 util에 있는게 맞아 보입니다! 그 validator를 가져와서 서비스 성격에 맞게 조합하는 역할을 validationResult가 한다면 충분히 유지보수 측면에서 유효할 것 같습니다!

view 를 조작하지 않고 단순히 화면(DOM) 상의 데이터만을 불러오는 함수는 view 에 담아야 하는건가요? 아니면 제가 한 것처럼 완전히 별도로 분류해두는 것이 좋을까요?

추후를 생각해보면 지금 방법이 더 좋을수도 있어보입니다. 다만 template이나 view나 사실은 동일한 역할을 하므로, view에 합병시키고, view에서 해당 도메인 마다 module을 만들어서 레이어내에서 관리하는게 좋아보입니다! 왜 그러냐면, template은 번외로 빠져있기 때문에 다른 dependency가 생길 수 있기 때문입니다.

Vallista · 2021-02-28T05:27:19Z

cypress/integration/lotto.spec.js

+  it('다시 시작하기 버튼을 누르면, 로또게임이 초기화된다.', () => {
+    cy.get('#cost-input').type('3000');
+    cy.get('#cost-submit-button').click();
+    cy.get('.winning-number').eq(0).type(1);


일렬적인 패턴이 반복되고 있네요!

3000을 타이핑 한 후,

클릭

0번째에 타이핑을 1 하고 ~ 7까지 타이핑

모달 버튼 클릭

이러한 반복 행위는 함수로 빼도 괜찮지 않을까요~?

그렇네요...! 반영했습니다! 앞으로도 3개 이상 테스트에서 반복되는 2줄 이상의 코드는 함수로 만들어보겠습니다!

Vallista · 2021-02-28T05:30:02Z

index.html

          </section>
-          <form class="mt-9" style="display: none">
+          <form id="winning-number-input-form" class="mt-9 removed">


id 네이밍이 굉장히 기네요! 하위에도 element 의 id가 길어지는 걸 볼 수 있구요!
BEM 방법론을 적용하여 특정한 규칙으로 만들면서 유효하게 관리하면 어떨까요?

BEM 을 적용하면 오히려 id 나 클래스가 길어지는 것으로 알고 있었는데 확실히 더 깔끔해진 것 같습니다! 그런데 조금이라도 더 짧게 하기 위해

check-number-form__input 이 아니라
check-number__input 이런 식의 생략을 추가한 것이 있는데 이 정도 생략은 괜찮은 것 같나요? 저는 개인적으로 해당 태그가 form 임을 클래스나 id 에서 명시해줘야 할 것이라고는 생각이 안들어서 일단은 뺐습니다!

넵 좋은 것 같습니다!

Vallista · 2021-02-28T05:31:36Z

src/assets/css/index.css

@@ -31,10 +31,14 @@ body {
  padding-bottom: 4px;
 }

-#purchase-item-list.hide-lotto-numbers .lotto-numbers {
+#purchase-item-list.lotto-numbers-removed .lotto-numbers {


display를 none하거나 display를 block으로 보이도록 설정하는 것을 따로 visible, invisible등의 css 로직으로 때내서 사용하는게 좀 더 좋지 않을까요? 그 때 그 때 마다 -removed 와 같은 긴 이름을 붙이는 것 보다 나아보여서요!

별도로, 위의 winning-number나 bonus-number의 width, height가 같아보이는데요! 이 친구들을 묶을 수 있는 하나의 클래스 단위를 만들어서 함께 쓰면 좋을 것 같습니다 :)

아래의 display.css에서 쓰고 있네요! 그걸 써보는 건 어떨까요? 요 로직은 필요없어보입니다!

winning-number나 bonus-number 에 적용할 스타일링은 input-box 라는 이름의 클래스에 넣어서 관리하도록 만들었습니다!

개인적인 생각으로는 저 lotto-numbers-removed 라는 클래스는 로또 아이템들이 안보이게 만드는게 아니라 로또 아이템 안의 로또 번호들만 안보이게 하는 동작에 사용되기 때문에, 정확히 어떤 동작이 일어나는지를 명시하기 위해서 어느 정도 길더라도 저렇게 명시하는 것이 필요하다고 생각했습니다. 다만 너무 길다는 생각이 들어서 lotto-numbers-removed => numbers-removed 로 변경하였습니다.

지적해주신 것처럼 #purchase-item-list 이 요소에 저런 조건식을 붙이지 않고 .lotto-numbers 요소들에 removed, added 라는 클래스를 넣고 붙이는 식으로 동작하는 방법이 더 간단하다는 말씀의 의도는 알겠습니다. 다만 그렇게 하면 모든 .lotto-numbers 요소들의 클래스를 일괄적으로 조작해주는 동작을 해야하는데, 그러면 .lotto-numbers 요소의 개수만큼 리플로우가 일어나지 않을까 하는 우려가 있습니다.

기존에 #purchase-item-list 요소에 클래스 하나를 넣고 붙이는 동작은 한번의 리플로우만 발생시키는 방식이라고 생각해서 렌더링 성능을 생각해보면 이쪽이 더 유효한 방법이 아닐까 하는 의견을 조심스럽게 내봅니다.

혹시 그 정도의 성능 차이는 크게 의미 없다고 생각하시는지, 제가 놓치고 있거나 제대로 이해하지 못한 부분이 있다면 지적해주시면 감사드리겠습니다.

제가 생각하기에는, 성능이 무조껀 좋은 코드가 능사는 아닌 것 같아요. 해당 프로젝트에 맞게 함수를 만들고 설정하시면 될 것 같은데요~ 실시간 형태로 repaint, reflow가 몇십번 일어나지 않는 걸로 보이는데, 적용할 이유가 없어보입니다!

그리고 display가 reflow 의 문제가 있어보인다면, visibility나 opacity등으로 reflow의 해결도 할 수 있을 것 같습니다.

Vallista · 2021-02-28T05:32:37Z

src/assets/css/index.css

  display: none;
 }

+#purchase-item-list.lotto-numbers-added .lotto-numbers {
+  display: '';


display: ''는 무얼 나타내는걸까요? display: block; 이 좀 더 명확하지 않을까요?

빈 문자열로 만들면 가장 초기의 display 값으로 돌아간다는 말을 듣고 적용했던 것인데, 확실히 'block'이나 'initial'이라는 값으로 나타내는게 더 명시적이겠군요! 수정했습니다!

Vallista · 2021-02-28T05:33:44Z

src/assets/css/shared/modules/display.css

@@ -1,3 +1,7 @@
-.hide {
+.block-added {


분리한 것은 아주 좋습니다!

감사합니다! 그런데 생각해보니 block-added 는 뭔가 이해가 잘 안될 수도 있는 이름 같기도 해서 block-added 를 d-block 으로 변경했습니다!

Vallista · 2021-02-28T05:36:16Z

src/constants.js

+  .find(reward => reward.shouldCheckBonus)
+  .matchCount
+
+export const VALID_CHECK_RESULT = '';


공백을 체크하기 위한 값일까요?

네 맞습니다. 상수 명이 그런 의문을 불러 일으킬만큼 명시적이지 않았다는 생각이 드네요. 좀 더 의미가 명확하게 전달되도록 VALIDATION 이라는 상수 객체에 NO_ERROR_MESSAGE 라는 이름으로 넣었습니다!

Vallista · 2021-02-28T05:39:05Z

src/lotto/LottoGame.js


 export default class LottoGame {
  #lottoItemList = [];
+  #winningNumberList = [];


클래스내에 멤버변수나 private, protected, public 함수의 순서를 일관성있게 관리해보는 건 어떨까요?

사용처를 기준으로 생각해보면, LottoGame이 어떤 함수를 가지고 있는지 알아야 하니, 가장 우선으로는 public method - 상속받는 곳에서 알아야하니 protected method - 내부에서 작업할 때에만 쓰이는 private method - 변수는 외부에서 알아야 할 필요 없고, 내부에서만 확인하면 되니 member variable.

public

protected

private

member variable

순서로 정해보는 건 어떨까요?

메서드 순서는 조언해주시는 대로 하는게 정말 백번천번 맞는 말씀이라고 생각합니다! 그런데 해당 클래스가 하는 일을 가장 잘 대변해주는 것이 그 클래스 안의 변수라는 생각이 들어서 변수들을 가장 뒤로 빼야 하는지에 대해서는 조금 의문이 듭니다.

물론 변수보다 메서드가 앞에 있는 것이 코드를 읽어들이는데 있어서 더 편할 것이라는 생각에는 동의합니다! 다만 많은 클래스 작성 코드에서 변수를 메서드 보다 앞으로 두는 경우가 많이 보이기 때문에 변수가 뒤에 있는 순서는 다른 많은 개발자들에게 혼란을 주지 않을까 하는 생각도 듭니다. 혹시 실제 현업에서도 변수를 메서드들보다 뒤에 선언하는 것이 보편적인 컨벤션인지 여쭤볼 수 있을까요?

클래스가 하는 일을 가장 잘 대변해 주는게, 클래스 안 변수 인지는 다시 한번 생각해보시는 것이 좋을 것 같습니다~ :)
클래스는 객체와 행동으로 나뉩니다. 외부에서 객체의 내부 상태를 보고 판단할 수 있는게 맞을까요? 행동을 보고 클래스가 어떤 친구인 지는 알 수가 있는데, 내부 상태만 갖고는 알기 어렵습니다.

비유를 하면, 자전거가 굴러가는지, 안굴러가는지는 내부 상태를 정의한 값으로만은 알 수 없습니다. 상태만 정의되어있고 move라는 행동이 없다면 굴러가지 않죠. 대규모 프로그래밍을 하게되면, 사실 상태가 의미가 없는 경우가 많습니다. 해당 클래스를 빠르게 보면서 이 친구는 어떤 역할을 하는 친구인지.. 어떤 행동을 하는지만 알면 대략적으로 어느 부분을 수정해야하는지 확인할 수 있고, 그리고 수정해야하는 메서드를 잘 나눠놓았다면 메서드 단위로 수정을 해주면 되겠죠. 해당 메서드를 수정할 때에는 내부에서 사용되는 상태를 파악하면 되는거고. 결국 상태는 많이 확인을 안하게 됩니다. 다만 이 전제는 객체지향적으로 메소드나 함수, 클래스를 잘 짜놓았을 경우의 상황입니다.

실제 현업에서는 어떻게 하는지 프로젝트의 오너, 프로젝트의 성향에 따라 다르겠지만 제가 여태까지 보아온 프로젝트는 규모가 클 수록, 아래에 있는 경우가 많았습니다.

Vallista · 2021-02-28T05:46:38Z

src/lotto/domReader.js

+
+export const getCorrectNumbers = () => {
+  const winningNumbers = $('.winning-number', $correctNumberWrapper)
+    .filter(({ value }) => value !== '')


filter -> map 하신 부분 좋습니다!

감사합니다!

Vallista · 2021-02-28T05:59:24Z

src/lotto/validation/validator.js

+    return new Set(numbers).size !== numbers.length;
+  },
+
+  isNumberOutOfRangeExist(numbers) {


numbers가 array가 아닐 경우도 있을 것 같습니다! 그에대한 예외처리도 하면 좋을 것 같아요!

함수를 작성하실 때, 유조님께 드렸던 피드백을 참고해보시는 것도 좋겠습니다!

와 저도 이런 순서는 생각 못하고 있었는데...엄청 유용한 조언 감사드립니다! 말씀하신대로 반영했습니다!

그리고 매개변수에 대한 타입이나 기타 유효성 검사에 대해서 질문드리고 싶은게 있습니다! 저는 controller 에서 입력값에 대한 유효성 검사를 수행하도록 위임했다고 생각했기 때문에 어차피 controller 에서 알맞은 형태의 값이 넘겨지거나 값이 가공되서 넘겨질 것이기 때문에 view와 model 메서드에서는 굳이 인자에 대한 검사를 해줄 필요가 없다고 생각했던 것이 사실입니다.

그러나 지금 생각해보면 model 과 view 에서도 유효성 검사가 있는 식으로 안정장치가 많은 것이 좋다는 것이 납득이 됩니다. 하나 걸리는게 있다면

'그렇다면 매개변수를 받는 모든 함수들의 매개변수에 다 타입 체크와 유효성 검사를 수행해야 하는 것인가?'

라는 의문입니다. 그렇게 할 경우 유효성 검사와 타입 체크 코드를 모듈화 한다고 하더라도 코드가 중복되는 부분이 너무 많아질 것이라는 생각이 드는데, 잘못된 입력값이 들어올 가능성이 매우 낮다고 생각되는 함수에는 이러한 매개변수 검사 코드를 생략할 수 있는 것일까요? 매개변수에 대한 검사를 수행할 함수와 그렇지 않아도 될 함수의 기준이라는 것이 따로 있는 것인가요? 아니면 그냥 매개변수가 있다면 당연히 일괄적으로 검사를 수행하는게 맞는 것인가요?

일단 가능한 거의 모든 함수에 매개변수 예외처리 로직을 넣었습니다!

자바스크립트의 경우에는 가능한 모든 함수에 예외처리를 해줘야 한다 생각합니다. 이러한 처리가 힘들고 불편하기 때문에 typescript 와 같은 정적 타입 언어가 대세가 되었다고 생각하구요!

이 프로젝트의 경우에는 크리스님의 말씀처럼 필요없는 부분이 있을 수 있습니다. 다만, 제가 생각하기에 협업을 진행하게 된다면 (최소 2인이상의) 특정 함수들은 빈번하게 서로 사용하게 될 것입니다. 그러면 사용하게 될 때 이 함수는 중요한 함수이고, 예외 상황이 필요할 것 같은 상황 (다른 사람이 사용하는 입장에서 메소드나 함수를 만드셔야 합니다) 이 많이 찾아올 것입니다.

그렇기 때문에 누가 사용할 지 모르는 상황에서 예외처리 로직은 필수불가결하고, 해당 함수처럼 느슨한 결합이 있는 경우 (아에 단독으로 쓰일 수 있는 경우)에는 예외처리는 필수적으로 해야한다고 생각합니다. (유효성 검사, 타입체크 모두) 다만 결합이 강해질수록 이러한 예외는 적어질 수 있다고 생각해요.

Vallista · 2021-02-28T06:01:00Z

src/templates.js

+      <td class="p-3">${rankItem.winCount}개</td>
+    </tr>
+    `
+  ).join('');


join(', ')로 안해도 되나요~? 공백과 콤마가 붙을 것 같아서요!

이 부분은 사실 이해를 잘 못했습니다! 공백과 콤마를 붙여야 하는 이유가 있나요?

아! 요거는 무시하셔도 됩니다!

Vallista · 2021-02-28T06:21:20Z

코맨트를 확인하시면, 머지하도록 하겠습니다!

swon3210 · 2021-03-01T08:12:41Z

덕분에 평소에 애매하다고 생각했던 것들이 조금씩 정리되는 것을 느꼈습니다! service 객체를 따로 두니 코드를 짜는 것이 상당히 번거로워지고 이름을 붙이는게 상당히 어려웠었는데 굳이 역할을 분리하지 않아도 모듈화를 할 수 있다는 어찌보면 단순한 사실을 깨닫게 해주신 것에 감사드립니다! 그리고 BEM 도 평소에는 어지럽게만 느껴서 적용해볼 생각을 못했었는데, 덕분에 공부할 기회가 생겼습니다.

swon3210 · 2021-03-01T08:16:55Z

그리고 리뷰해주신 사항들을 반영하는 와중에 이용자가 입력한 금액을 처리하는 방식을 좀 더 사용자 친화적이라고 생각되는 방향으로 변경한 부분이 있습니다. 고칠 때는 미처 생각을 못했는데...혹시 리뷰하는데 방해가 되었다면 죄송합니다...!

Vallista · 2021-03-03T17:31:06Z

3단계를 진행하고 계시겠지만.. 늦었지만 머지 합니다!

Vallista · 2021-03-03T17:31:17Z

추가적으로 코맨트에 답변을 남겼습니다~

swon3210 · 2021-04-15T12:35:26Z

[CSS] BEM 네이밍 - 3

BEM 을 통해 마크업 구조화 하기

CSS 클래스 명명을 의미론적으로 하기 위해서는 BEM 을 적용할 수 있다.
BEM 은 SCSS(SASS) 의 & 와 함께 활용하면 더 직관적이고 명확한 CSS 코드를 작성할 수 있게 해준다.
BEM 이란? : https://www.notion.so/songwon2019/BEM-Block-Element-Modifier-95121e03e45940109d501a98c45cfc11

swon3210 · 2021-04-15T12:38:40Z

[예외처리] 함수의 예외처리 - 4

거의 모든 함수의 매개변수에는 예기치 못한 입력에 대비한 방어 코드가 들어있어야 한다.

안전하게 동작하는 함수를 작성하는 기본적인 순서는 다음과 같습니다.
- 한글로 어떤 행동을 하는 함수인지 정의한다.
- 해당 함수가 어떤 parameter가 필요한지 정의한다.
- 해당 parameter는 어떠한 예외가 있는지 bad case를 정의하여 return 구문을 작성한다.
자바스크립트는 매개변수의 타입을 보장하지 않기 때문에, 항상 매개변수에 대한 타입 검사를 수행해야 한다. 그러나 결합이 매우 강한 관계의 함수가 있다면(사실상 해당 함수가 사용될 부분이 정해져 있을 때) 예외처리를 융통성 있게 줄일 수는 있을 것이다.
- 그것이 귀찮다면 Typescript 를 사용할 수 있다. 그러나 런타임에서의 타입에러는 발생할 수 있음을 명시한다. 이용자 입력과 같은 예상치 못한 입력값에 대해서는 자바스크립트 코드로 타입 가드를 수행하는 것이 좋다.

swon3210 added 24 commits February 22, 2021 16:13

docs: step2 기능 & 테스트 항목 추가

1b29e74

refactor: class 기반 querySelector => id 기반 querySelector

bcfb7df

feat: modal 열고 닫기 기능 추가

0441001

test: step 2 유저 입력 값 테스트 코드 구현

138152f

test: step 2 기능 테스트 코드 구현

8f7a174

feat: 당첨 번호와 보너스 번호를 입력

b3015b1

feat: 결과 확인하기 버튼을 누르면 당첨 통계, 수익률을 모달로 확인

0ff747f

feat: 다시 시작하기 버튼을 누르면 초기화 되서 다시 구매를 시작

d6981cf

refactor: view에서 alert를 처리하도록 변경

d5f43af

feat: 당첨 번호를 모두 입력하지 않았을 경우 에러 처리

d04dc82

test: not.exist => not.be.visible 로 변경

965b02f

refactor: elements 선택자 상수화

9e3d93d

refactor: init 메서드에서 hideResult 동작 분리

9022e46

refactor: 메서드 및 변수명 변경

506af7e

docs: 통과된 테스트에 체크 마크 추가

045ead8

Merge branch 'swon3210' of https://github.com/woowacourse/javascript-…

8a63b01

…lotto into chris

refactor: onCostSumbit => onCostSubmit 오타 수정

69fecee

refactor: validation 관련 파일 및 메서드 명 변경

f654044

refactor: view 메서드 명 변경

60c7dc4

refactor: LottoGame 관련 메서드 이름 변경

48f83bd

refactor: 바뀐 view, LottoGame 메서드명 service 에 반영

c288e07

refactor: 문제가 없을 시의 check result 문자열 상수화

51c8a8f

refactor: css class 문자열 상수화 및 적용

56145e8

refactor: 이름을 구분하여 getter 와 private, protected 속성을 더 잘 구분할 수 있게 변경

0439909

swon3210 changed the base branch from main to swon3210 February 26, 2021 12:50

pocojang requested a review from Vallista February 26, 2021 13:33

pocojang assigned Vallista Feb 26, 2021

docs: step3 기능 및 테스트 항목 추가

48f39d0

Vallista approved these changes Feb 28, 2021

View reviewed changes

swon3210 added 6 commits March 1, 2021 01:35

feat: 로또 구매에 사용할 금액을 추가할 수 있음

2029389

refactor: BEM CSS 작명 방법론 도입 & 테스트 코드를 도메인 별로 분리

972cfd1

refactor: LottoGame 클래스 내부의 변수와 메서드 순서를 변경

591d57b

refactor: Validation 을 위한 상수 객체 추가

c8e8697

refactor: number input 태그의 스타일링을 .input-box 클래스에서 일괄 관리

fc61f4f

fix: validator 메서드에 인자가 array 인지 검사하는 로직 추가

c8861f8

fix: view, model, controller, utils 함수 모두에 예외처리 추가

dfa427d

Vallista merged commit 3ae74ef into woowacourse:swon3210 Mar 3, 2021

		@@ -1,3 +1,7 @@
		.hide {
		.block-added {

[2단계 - 행운의 로또 미션] 크리스(이송원) 미션 제출합니다. #54

[2단계 - 행운의 로또 미션] 크리스(이송원) 미션 제출합니다. #54

Conversation

swon3210 commented Feb 26, 2021 • edited Loading

STEP 2

🎯 step2 에서 추가된 기능

🔧 step2 에서 추가된 테스트

❗ step2 에서 추가된 컨벤션

🖼️ 구조도

📁 디렉터리 구조

중점을 둔 부분

궁금한 점

Vallista left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swon3210 Mar 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swon3210 Mar 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vallista commented Feb 28, 2021

swon3210 commented Mar 1, 2021

swon3210 commented Mar 1, 2021

Vallista commented Mar 3, 2021

Vallista commented Mar 3, 2021

swon3210 commented Apr 15, 2021 • edited Loading

[CSS] BEM 네이밍 - 3

BEM 을 통해 마크업 구조화 하기

swon3210 commented Apr 15, 2021 • edited Loading

[예외처리] 함수의 예외처리 - 4

거의 모든 함수의 매개변수에는 예기치 못한 입력에 대비한 방어 코드가 들어있어야 한다.

swon3210 commented Feb 26, 2021 •

edited

Loading

swon3210 Mar 1, 2021 •

edited

Loading

swon3210 Mar 1, 2021 •

edited

Loading

swon3210 commented Apr 15, 2021 •

edited

Loading

swon3210 commented Apr 15, 2021 •

edited

Loading