[🚀 사이클2 - 미션 (블랙잭 베팅)] 에버 미션 제출합니다.

[Chocoding1]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

TDD

TDD를 시도해 보려고 하니, 처음 테스트 파일의 이름을 정하는 것부터 막히는 경험을 했습니다. TDD를 위해 가장 단순한 로직을 먼저 테스트하기 위해서는 그 로직이 어떤 객체에 존재해야 하는지 먼저 정해야 하는 건가요? 만약 그렇다면 TDD로 개발을 시작하기 전에 전체 서비스의 설계를 완벽하게 해놓아야 하는지 궁금합니다.

초기 설계

초기에 설계하실 때 어떤 흐름으로 어떤 객체들이 필요할지 정하시는지 궁금합니다.

리팩토링

이번에 배팅 수익금 계산 기능을 추가하는 과정에서 많은 리팩토링이 필요했습니다. 한 번에 많은 클래스들이 꼬여있다 보니 어디서부터 풀어나가야 할지 감을 못 잡았는데요, 이렇게 복잡하게 꼬인 코드들을 풀 때는 어떤 방식으로 접근하는 것이 좋을까요?

[pci2676]

리팩토링
이번에 배팅 수익금 계산 기능을 추가하는 과정에서 많은 리팩토링이 필요했습니다. 한 번에 많은 클래스들이 꼬여있다 보니 어디서부터 풀어나가야 할지 감을 못 잡았는데요, 이렇게 복잡하게 꼬인 코드들을 풀 때는 어떤 방식으로 접근하는 것이 좋을까요?

리팩터링을 하는 기법이 있을것 같은데 리팩터링하실때 가장 힘들었던 부분이 무엇이었나요?

힘들었던 부분이 생겼던 이유는 무엇이었을까요?

저는 보통 리팩터링 한다면 공개 API 에 대한 테스트를 충분히 만들어두고 내부 구현체를 갈아끼우는 식으로 작업을 많이 했던것 같아요

리팩터링에 대한 이야기는 예전부터 많은 개발자들이 이야기해왔던 터라 마틴 파울러 아저씨의 읽어볼만한 글 남겨드릴게요~

https://martinfowler.com/bliki/BranchByAbstraction.html

https://martinfowler.com/bliki/StranglerFigApplication.html

[pci2676]

빠르게 반영해주셨네요!

조금 더 개선해보면 좋을 부분에 리뷰를 남겨두었으니 확인해주세요

[pci2676]

답변을 어디에 남길까 하다가 readme 작성하신 곳이 적절할것 같아서 답변드려요~

TDD
TDD를 시도해 보려고 하니, 처음 테스트 파일의 이름을 정하는 것부터 막히는 경험을 했습니다. TDD를 위해 가장 단순한 로직을 먼저 테스트하기 위해서는 그 로직이 어떤 객체에 존재해야 하는지 먼저 정해야 하는 건가요? 만약 그렇다면 TDD로 개발을 시작하기 전에 전체 서비스의 설계를 완벽하게 해놓아야 하는지 궁금합니다.

초기 설계
초기에 설계하실 때 어떤 흐름으로 어떤 객체들이 필요할지 정하시는지 궁금합니다.

TDD를 시작하기에 앞서 요구사항을 먼저 정리하는것 같습니다.
요구사항을 정리할때 필요한 기능들이 무엇이 있는지 나열해보고 성격이 비슷한 것 끼리 묶어봅니다.
그리고 요구사항을 해결하기 위한 객체들이 어떤것들이 필요할지 어떤 객체끼리 상호작용을할지 그려보는것 같네요. 이때 성격이 비슷한 것끼리 묶은 하나의 집합이 하나의 객체가 되거나 여러개의 객체로 할당되는것 같네요.

아래와 같은 예시를 보여드릴수 있을것 같네요

## 시나리오

- 플레이어 이름을 쉼표단위로 입력받는다.
- 카드 분배
  - 딜러는 1장을 받는다
  - 유저는 2장을 받는다.
- 카드 리스트를 출력한다
- 유저 카드의 합이 21미만이면 카드를 추가로 받을 수 있다.
- 딜러는 16이하면 1장을 추가로 받는다.
  - 딜러는 17이상이면 카드를 받지않는다.
- 결과출력
  - 딜러와 플레이어의 카드리스트와 합계를 출력한다.
  - 최종 승패를 출력한다.

## 기능

- 입력
  - 쉼표로 분리해서 Player 객체로 생성
  - 플레이어에게 카드를 더 받을지 물어본다

- 플레이어
  - **딜러**
    - 딜러가 패를 나눠 준다
      - 1장, 2장
  - **유저**
    - 결과 객체를 만든다.
- 카드패 
  - 자신의 점수의 합을 계산
  - 다른패와 점수를 비교
  - Burst 여부
  - 블랙잭 여부
- 카드뭉치
  - 카드를 1개씩 가져온다.

- 게임
  - 유저 카드를 추가로 받을지 질문하고 추가한다.
  - 딜러의 카드 추가가 필요하면 추가한다.

위 예시는 정말 간단하게 작성한 것 이고 지금 저한테 작성하라고 한다면 더 세세하게 작성할 것 같긴하네요

방법이야 여러가지겠지만 이러한 과정은 실무를 하면서도 시작단계에 해당하는 굉장히 중요한 작업이니 연습해보시면 좋을것 같습니다 :)

추가로 궁금한 점이 있다면 편하게 질문주세요

[pci2676]

이전에 "Users는 User만 알고 있는게 좋을것 같다"는 이야기를 나눴었는데요~ 이번에 List<User>로 합치면서 오히려 instanceof와 캐스팅이 생겨버린것 같아요.

추상화를 했는데 구체클래스를 꺼내쓰는건 추상화한 보람이 조금 흐려지는것 같습니다. instanceof 없이도 딜러와 플레이어를 구분할 수 없을까요?

[pci2676]

테스트에서 for 반복문으로 각 플레이어의 카드 수를 검증하고 있는데요~ 테스트 코드에 반복문이 들어가면 어떤 플레이어에서 실패했는지 파악하기 어려워질 수 있습니다.

[pci2676]

기존에 있던 예외 메시지 검증(.hasMessage(...))을 제거하셨는데요~ 앞서 BetAmountTest에서도 언급한것과 같은 부분인데, 오히려 이전 코드가 더 좋은 테스트였던것 같아요.

메시지 검증을 다시 추가하는걸 권장드립니다~

[pci2676]

비단 이 코드에만 해당하는 것은 아닌데요

public static 메서드에 복잡한 비즈니스 로직이 구현되어있다면 정말 static 으로 구현하는게 맞는지 의심해볼 필요가 있을것 같아요

static 하게 구현한다는것은 사실 GemeResult가 아니라 다른곳에 위치해도 동일하게 구현할 수 있고, 어떤 클래스에 선언했느냐의 차이만 발생하는것 같아요

물론 해당 코드가 어떤 맥락을 위해 존재하겠구나 라는 생각은 할 수 있겠지만요

메서드에 참여한 객체들끼리 메세지를 주고받아볼순 없을까요?