FE 로또 미션 1단계 토론 | 2023.02.17

[woowapark]

로또 미션 1단계를 구현하며 설계해본 과정을 자유롭게 나누어주세요.

• 우리는 이렇게 설계했다! 를 상대 페어에게 설명해주기
  • 어떤 단위로 모듈을 나누었는지, 각각은 어떤 책임을 가지고 있도록 하였는 지 등을 알 수 있게 이야기해 주세요.
  • 어떤 곳에서 객체(또는 클래스)를 사용하고, 어떤 곳에서 함수를 사용했는지도 살펴보세요.
• 어떤 순서로 문제에 접근했는지 이야기해보고, 그 순서 중에 특별히 좋았던/어려웠던 순간이 있다면 언제였는지 나눠주세요.

체크사항

• ✅ '어떤 생각과 고민의 과정을 거쳤는 지'가 잘 드러날 수 있게 이야기를 나누고 글로도 적어주세요.
• ✅ 두 페어(페어 vs 페어)당 1개의 코멘트에 함께 논의한 내용을 작성하여 공유해주세요.

[Dahyeeee]

수아 + 레고

• MVC 패턴을 지키며, 객체는 객체답게를 지키려고 노력하며 설계함.
  • 컨트롤러(클래스) => 로또 게임(클래스) => 로또 (클래스)
  • view(객체)
• 로또 객체부터 고민하기 시작. 규모가 작은 클래스부터.
• TDD를 지키려고 상수나 뷰같은 객체보다는 작은 클래스부터 고민해서 테스트를 해결하는 방향으로 구현
• 재사용할 수 있는 함수를 유틸로 분리하는 것을 신경썼다
• 어려웠던 점: 이것저것을 혼재해서 같이 작성하다보니 커밋을 할 타이밍이 애매한 느낌, TDD가 익숙하지 않아서 어렵고 시간이 오래 걸렸다. MVC패턴을 제대로 이해하고 적용하고 있는지 고민이 되었다.
• 좋았던 점: 테스트를 미리 하다보니 디버깅이 쉬웠다. 오래 걸렸지만 그만한 가치가 있었던 것 같다.

애슐리 + 헤다

• 수아레고와 설계는 비슷함
• 다만 계산기를 따로 클래스로 빼서 로또 게임안에서 계산을 하는 역할을 부여함.
• 하다보니 관성적으로 mvc 패턴을 사용했는데, 다른 패턴을 모르기 때문에 다른 설계 가능성이 닫혀 있었다.
• 실행 순서 흐름에 따라 구현
• 객체 클래스 → 역할에 따라 구분했다.
• tdd - 예외사항, 기능 목록을 미리 상세히 적었더니, tdd가 비교적 수월했던 것 같음.
• 하다가 tdd로 돌아가는 경우 종종 있었다.
• 어려웠던 점: TDD 사고 흐름이 익숙하지 않았다. 네이밍.. 대박어려움..
• 좋았던 점: 어떻게 보면 단일 패턴으로 코드를 짰기 때문에 단순했던 거 같다.

[2yunseong]

(윤생, 코난) vs (노아이즈, 세인)

우리는 이렇게 설계했다! 를 상대 페어에게 설명해주기

• 윤생, 코난
  • 책임 분리에 대해 고민을 많이 해보았고 Lotto에 관련된 일을 시키는 LottoController, 실제로 Lotto에 관한 일을 하는 LottoMachine을 만들고, 또 LottoRank라는 로또 순위 계산만을 담당하는 객체를 만듬으로써 책임분리를 고민을 많이 해봤다.
• 노아이즈, 세인
  • 어떻게 하면 변경이 적은 로직을 짤 수 있을까에 대한 고민을 많이했다. 콘솔과 하나의 입력과 그에 대한 출력을 하나의 View라는 단위로 보고 컴포넌트로 보았다.

어떤 순서로 문제에 접근했는지 이야기해보고, 그 순서 중에 특별히 좋았던/어려웠던 순간이 있다면 언제였는지 나눠주세요.

• 상속보다는 조합 ⇒ 당첨 로또(WinningLotto)가 로또(Lotto)를 상속받는 것이 아닌 로또 인스턴스를 생성해 생성자 파라미터로 넘겨주게 구현하였다.
• 확장성이 가지는 상충관계에 따른 고민을 많이 해보았다.
• LottoStore에서 계산해서 값을 넘겨줄 수 있었을 것 같은데, 아예 View가 상태 값을 가지고 있었다. ⇒ 상태관리에 대한 논의

[solo5star]

구현 순서를 어떻게 했는지

• 기능 목록을 카테고리로 나눠서 적어봤다!
• 구현 순서는 기능목록부터 구현!
• 아커, 첵스 페어는 기능목록할 때 프로퍼티랑 메서드까지 다 했다.

어떻게 분리했는지

• MVC 적용
• 예외는 InputView에서 했다
• 로또 구매하는 주체, 로또 객체, 로또를 발행하는 주체
• 솔로스타+타미 페어의 LottoController 안에 proceed prefix 네이밍이 좋았다.
• 아커+첵스 페어에서는 App에서 컨트롤러 역할을 수행함
• 아커+첵스 페어에서는 유틸에서 수익률 계산 등등을 했다. 유틸의 재사용성을 높일 수 있어 좋은거같다!

어려웠던 점

• 솔로스타+타미 페어: 책임을 분리하는 게 어려웠다
• 네이밍이 어려웠다. 어떻게 하면 의미를 잘 전달할 수 있는지?
• TDD하는 것이 어려웠다. 시간이 오래 걸린다. 어떻게 돌아가야 할 지 머리속에서 떠올려야 하니까.
• 개발 환경 설정 하는 것이 어려웠다.

[jeongwusi]

고니, 패트릭, 네이브, 에이든

---

어떤 단위로 모듈을 나누었는지, 각각은 어떤 책임을 가지고 있도록 하였는 지 등을 알 수 있게 이야기해 주세요.

• 고니, 패트릭: MVC 모델을 적용
• 에이든, 네이브: view하고 도메인으로 나누고 App.js에서 컨트롤러를 역할을 한다.

어떤 곳에서 객체(또는 클래스)를 사용하고, 어떤 곳에서 함수를 사용했는지도 살펴보세요.

• 재사용하면 class이용하고 아니면 const를 이용한 함수를 사용했다.

어려운 점

• 단위 테스트 중심의 기능 구현이 어려웠다.
• controller를 통한 조립이 너무 어려웠다.
• 시간 분배를 잘 못한 거 같다.

[sh981013s]

제레미, 황펭:

• MVC 패턴 적용

  • 도메인 로직(Lotto, LottoMachine, Comparer, ProfitCalculator), I/O VIew, Controller
  • 유효성 검사 Validator => Controller 호출

• 좋았던 점

  • TDD를 처음 시작할 당시 어느정도의 단위로 테스트를 다루어야할지 의견이 상충되었지만 건설적인 토론을 통해 적당한 단위의 테스트코드를 실행하면서 성공적으로 미션을 완수할 수 있었다.

부엉이, 엽토:

• 필드를 최대한 줄이고자 저장하지 않아도 된다싶은 데이터는 바로 사용 및 가공
  • 최종적으로 필요한 데이터만 관리하자 (상태 개체수 감소)
• 최대한 도메인 로직을 순수함수로 사용해보려 했지만, 마지막 실제 연결 시 어려웠다.

[kyw0716]

🙋제로, 센트 & 해온, 가람 토의 내용

1️⃣ getter의 사용

값을 꺼내기만 하고, 따로 해당 값 자체를 수정하거나 하는 경우가 아니라면 getter의 사용을 지양해야 될 이유가 없을 것 같다.

2️⃣ 당첨 번호와 보너스 번호를 저장하는 방식

당첨 번호를 저장할 때 로또 객체를 사용해 번호를 저장하고, 보너스 번호를 저장할 때는 이를 상속받아온 객체에 보너스 번호를 추가적으로 저장하는 방식을 사용해보는 것도 좋을 것 같다.

3️⃣ 상수 분리에 함수를 넣는 방식이 맞을지

이는 outputView 로직에 해당하는 부분인 것 같아 따로 분리하는 것이 좋을 것 같다.

[feb-dain]

쿠마, 야미 vs 도담, 가브리엘

• 인상 깊었던 점

  • 도담 : 함수명을 열심히 작성한 게 보인다.
  • 야미 : 분리를 잘 하신 것 같습니다.
  • 쿠마 : validator와 사용자 입력 받는 부분을 처리하는 메서드를 만든 게 인상 깊었다.
  • 가브리엘 : 코드가 가독성있었다.

• 클래스를 사용한다면 필드를 꼭 사용해야 할까?

  • YES : 클래스 메서드의 존재 이유는 인스턴스 프로퍼티를 변경하는 것이라고 생각한다.
  • NO : 은닉할 수 있고, 생성자를 사용할 수 있어서

• 테스트 코드를 위해 은닉화를 포기해야 할까 vs 은닉화를 하고 테스트 코드를 삭제해야할까?

  • 단위 테스트 보다는 전체 테스트에 집중하는 것이 어떨까
  • 테스트 코드가 테스트 만을 위한 코드는 아니라고 생각한다

[D0Dam]

여러 의견이 나왔군요! 다들 합리적인 의견 같아서 배워갑니다~!

[gabrielyoon7]

좋아요

[ukkodeveloper]

🍗 참새 & 우코 🧓🏻

우리는 이렇게 설계했다!

• 접근(처음) : 기능단위로 목록 작성 → 잘게 나누려고 노력! 작은 단위가 테스트 편하니까(ex. 검증/ 로또 비교 같은)
  • 기능 목록 만들 때 입으로 게임 진행하면서 기능을 작성해 보았다.(게임을 머릿속으로 돌려서 순서에 따라 기능 정리 + 얘기를 하면서 둘이 + 순서도 안그리고 말로 이야기 한 덕분에 같은것을 이해하는 느낌! + 안빼먹기 좋았다.)
• 테스트 후에 객체 만들고 메서드만들고 로직 짰음
• 클래스 vs 함수 → 함수로 고려 안했음. 굳이 따지면 util과 validate 정도? 객체 리터럴로 묶어서 한번에 export 함

어떤 순서로 문제에 접근했는가?

• “기능 목록 중에 한번에 되겠다” 라는 부분부터 짰다.

  1. 좋았던 점
  • 짜면서 이걸 어떻게 하지 라는 생각하지 않았음

  b. 어려웠던 점

  • 작은 기능을 먼저 만들고, 상위 기능에서 이를 호출하는 과정에서 예상치 못한 문제를 마주쳤다.

  • 유효성 검사하는 과정에서 전처리를 여러번 나누어야 하는 번거로움이 생겼다.

  • 전처리 → 검사 → 전처리→ 검사 형태라 코드가 길어져서 좀 어려웠음

  • 정규표현식 → 상황별로 에러메시지를 보내기 어려움 → 그래서 안쓰다보니까 유효 검사 갯수도 많아지고 해서 불편했음.

  • (우코 : 배열을 인자로 넘겨줘서 수익률 계산을 할 걸 하고 아쉬움이 남음)

    (참새: 저번에 static 메서드의 인자로 받는 방식으로 하긴 했는데 리뷰에서 악수 같다고 받아서(테스트만을 위해서 만든게 아닌가.)그래서 이번에는 인자 안 받는 형식으로 진행)

어디에서 의견충돌이 났나

유효성 검사 : 참새(자기자신과의 싸움) - 정규표현식을 쓰고 싶었다.. 근데 쓰면 혼날 것 같아서 안씀

💁🏻‍♀️ 루루 & 도리 🧏🏻‍♂️

우리는 이렇게 설계했다!

1. 요구사항을 보면서 필요한 것을 명사 기록(ex. 로또 구매, 로또 발행 등)한 다음에 항목별 파생되는 기능을 정리했다.
2. TDD 시도.
   1. 로또 객체 생성
   2. 유효성 검사는 하다가 방식에 대한 궁금증이 생기게 되어 나중에 모두 구현한 다음에 다시 테스트 작성함.
   3. 로또 오름차순으로 정렬
   4. ⚠️ 하지만 로또 랜덤 요소 때문에 TDD를 많이 하지 못 했음 → 결국 인풋부터 순차적으로 진행 ( TDD가 까다롭고 어렵다는 것을 느낌. 많이 경험하지 못한것에 대한 아쉬움)
3. Lotto winLotto LottoGame
   1. winLotto 가 로또 게임 결과를 도출하는 메서드를 갖고 있었지만 해당 역할이 LottoGame에 있어야 맞다고 생각하여 해당 메서드를 LottoGame으로 변경.
   2. LottoGame이 원래는 object였지만, 재시도를 할때 안에 이미 있는 데이터를 초기화해야하는 문제가 생겨 처음에는 명시적으로 초기화 했지만, 이후에 class로 변경하면서 해당 문제를 해결함.

우리는 이걸 목적으로 했다.

1. 기존에 잘 쓰지 않았던 JS문법을 시도하자.

   1. 객체 상속을 사용해보자.
      1. 객체 상속을 해보자.
   2. 내장 함수를 많이 사용해보자(every, filter)

2. 객체 class에 대해 많이 시도하자.

😊좋았던점👍

1. 코드 외적인 부분 - 페어가 활기차고 의욕이 넘쳐서 덕분에 힘이 되었다.
2. 페어와 대화를 통해 어떤 부분이 모르는지를 파악할 수 있었음. 공부 방향을 정할 수 있었다.

😢어려웠던 점

1. 체력이 둘다 약해서 오후에 힘이 없어 힘들었다..

어떤 순서로 문제에 접근했는가?

1. 간단한 것부터 구현!⇒ 합의점이 쉬우니까 😊
   1. 단순 계산
   2. 비교 등등..
2. 서로 의견 충돌이 있을 때 일단 돌아가게 만들어 놓은 다음에 토론을 했음. (합의점이 어려운 것은 나중에 구현해 보면서 좋은 것을 채택하는 방식이었음.) → 같이 만든 코드라는 느낌

[turtle601]

아인 + 파인

- Controller: UI 와 domain 로직을 연결
- LottoGame: 로또 게임에서 당첨 통계, 로또 발행, 수익률 계산 (로또 게임의 로직)
- Random: 랜덤을 뽑는 건 유틸, 숫자 뽑느 것도 유틸
- LottoTicket: 로또 티켓 한장 → 보너스 번호가 있는지 당첨번호가 중복이 있는지…
- 유틸
- 일반화: 정규식, 랜덤, 오름차순, 콘솔
- Validate 함수 → throw 에러 체크
- InputView, OutputView(도메인 로직 분리)

• 개발방식: TDD가 너무 어렵고 감이 잡히질 않아서 돌아가는 코드를 먼저 작성 후 그 다음 TDD를 하려고 노력하다보니 TDD를 완벽히 실행하지는 못했다.
  • 좋았던 점 : 전체적인 도메인 로직을 구현해서 이해하기 쉬웟다.
  • 어려웠던 점: 함수 메서드 네이밍 어려웠다. 최대한 유틸로 뺄 수 있는 거를 고민 많이 했다. TDD로 했으면 함수의 범위가 작았을 거 같은데…

유스 + 푸만능

- LottoGame: 컨트롤러 역할
- LottoMahcine: 구입금액 유효성 검사 + 로또 발행
- WinningNumbers: 당첨 번호 유효성 검사
- LottoStatistics: 로또 통계
- Lotto: 로또 한장
- BonusNumber: 보너스 번호 유효성 검사 + 보너스 번호
- InputView, OutputView(도메인 로직 분리)

• 개발방식: 기능 구현 목록을 상세히 작성 후 기능 구현 목록에 맞게 테스트를 먼저 작성하고 TDD를 최대한 활용하여 개발하려고 노력했다.
  • 좋았던 점: 테스트 코드를 기반으로 리팩토링을 아주 빠르게 할 수 있어서 좋았다.
  • 어려웠던 점: 설계에 관해서 이해도 맞지 않아서 어려웟다. 작업 기간이 길었다.

[woo-jk]

(룩소 + 슬링키) vs (도밥 + 아이크)

이번 미션에서 중점을 뒀던 점

룩소 + 슬링키

• 2단계(UI 적용)에 대응하기 위해 코드의 유지보수 및 확장성을 고려한 코드 작성

도밥 + 아이크

• TDD 방식을 연습하는 과제였던 만큼, 테스트에 중점을 두려고 노력함
  로또 게임에 관련된 로직을 최대한 테스트 가능한 구조로 만드는 것을 목적으로 함

토의 했던 내용

입력 검증 로직은 어디서 해야하는가?(Controller vs Domain)

• Controller파의 의견: 모듈화를 지향할 경우 최대한 로직을 잘게 쪼개고 조립하는 식으로 가야한다. 그러므로 입력 검증 로직 또한 도메인에서 분리한 뒤 컨트롤러에서 작성해야한다.
• Domain파의 의견: 유지보수와 확장성을 위해 도메인에서 작성해야한다. UI를 변경하거나 다른 기능을 추가한다고 가정 했을때, 도메인 로직에 검증 로직이 없다면 확장성이 떨어진다.

모든 로직을 테스트 해야하는가?

[ksone02]

클린 + 에디

이렇게 어려웠어요

• 객체 책임 분리가 어려웠습니다. 도메인에 작성해야 하는 로직과 유틸에서 빼줘도 되는 로직을 분리하는 과정에서 많이 고민했습니다.
• TDD를 쓰면서 초반에 설계하며 작성한 코드에서 구조가 달라졌을 때 테스트를 수정해줘야 하는 경우 변경이 번거로웠습니다.

우리 이렇게 설계했어요

• 기능목록 작성 -> 도메인에 관한 기능 추상화 후 테스트 작성 -> 도메인 구체화 -> 뷰,컨트롤러 같이 작성

[nlom0218]

노아/쵸파 & 라잇/우스

1. 구현하며 고민하고 생각한 점.

라잇 & 우스

Model에 존재하는 class의 생성 기준
직관적이고, 획일화된 함수 명명 (get, check, is.. 등 함수명과 동작하는 기능 자체가 매칭이 잘 되는지)
정석적인 TDD
깃모지 및 기능 목록 작성에 많은 에너지를 쏟았다.

노아 & 쵸파

TDD의 적용, 설계에 대한 고민
재사용성이 높은 함수 만들기 위한 고민
로또의 등수를 반환하기 위한 함수
객체 또는 클래스로 구현할지 고민

2. 상대 페어와 토론 후 느낀 점

라잇

클래스를 생성하는 기준에 대한 고민이 깊어졌습니다. 또한 상대페어의 utils함수 재사용성 범위가 인상깊었습니다.

우스

Validate에서 재사용성 높은 유틸 함수가 인상적이였고 Console에서 await를 사용하여 사용자가 값을 입력했을 때 콜백 방식보다 쉽게 매개변수를 전달할 수 있어서 부러웠습니다. 다음번에 또 다른 콘솔 미션이 있다면 저도 적용할 것이라고 생각했었습니다.

노아

TDD 적용과 TDD를 통해 코드를 구현하는 것에 대해 생각해 볼 수 있었고, 라잇과 유스가 네이밍을 하기 위한 고민 과정이 멋졌다! 기능 목록 또한 꼼꼼하게 작성하여 기능 목록만 보고도 바로 코드를 구현할 수 있도록 한 점이 인상깊었다.

쵸파

인스턴스를 여러번 만들 때만 모델을 정의했었는데 모든 데이터에 모델을 만든 것을 보고 이런 방법도 있구나 느꼈습니다.
기능구현 목록이 잘 작성되어있어서 인상이 깊었습니다.