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

[yItWorks]

안녕하세요, 제나! 로운입니다.
이번 리뷰도 잘 부탁드립니다!

체크 리스트

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

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

1. 캡슐화

hand를 private로 바꾸는 것이 캡슐화에 더 효과적이라는 리뷰를 받고, hand의 접근제한자를 protected에서 private로 바꾸며 Dealer 클래스에서 hand를 직접 사용하는 방식의 코드를 바꾸면서 문제가 발생하였던 부분은 두 부분이었습니다.

• 딜러는 하나의 카드만 오픈하는 상황
• 딜러가 hand.calculateScore()를 통해 hit 여부를 정하는 로직

후자의 경우 조언주신대로 getScore()를 통해 해결하였지만 전자의 경우 index를 딜러만 알고있는 것이 바람직하다고 생각해서 고민을 했었습니다. getCardNames()를 오버로딩해서 해결하였는데 올바른 해결 방법인지 궁금합니다.

2. 원시값에 대하여

2-1.
이름을 원시값인 String으로 두지 않고 Nickname 클래스를 만들어 처리하는 과정에서 문제가 발생하였습니다. 제가 정한 규칙은 이름 입력 시, 4~10자만 입력되도록 하는 것이었는데, 딜러는 이름이 2글자라는 점이었습니다.

이를 해결하기 위해 Nickname 클래스에서 “딜러” 만 예외로 두기보다 Name 인터페이스를 두고 Nickname과 DealerName으로 분리했습니다.

단순히 원시값 하나를 위해 인터페이스를 도입하는 것이 오버 엔지니어링이 아닌지, 실무에서도 비슷하게 활용하는지 궁금합니다.

2-2.
수익금에 대해선 클래스를 생성하지 않고 원시값인 Double로 처리하도록 하였습니다. 수익금은 게임 결과에 따라 배팅 금액을 합산하는 역할만 한다고 생각하여 객체를 만들지 않고 진행하였습니다. 모든 원시값을 포장하는 것이 과연 좋은 것인지 궁금합니다.

3. TDD에 대하여

TDD로 개발하려면 테스트를 먼저 구현하고 개발을 시작한다고 생각합니다.

테스트 구현 시, 어떤 메소드가 필요한지나 도메인이 어떻게 생겼는지 대략 설계를 먼저하고 테스트를 작성하는 경우가 많아서 사실 이게 TDD가 맞는지에 대한 고민이 많았습니다.

제가 느끼기에는 코드만 작성하지 않을 뿐이지 설계를 하고 테스트를 작성하는 거 같아서 코드 작성 순서만 평소와 반대로 하는 것 같다는 생각이 들어서 과연 효과적인 방법인지 계속 이 방법을 사용해야 할 지 고민입니다.

심지어 코드 작성 중 초기 설계에서 수정하고 싶은 부분이 생기면 테스트를 고치게 되는 순간이 생겨 TDD로 잘 하고 있는 것인지 항상 되뇌이게 되었습니다.

리뷰어님이 생각하시는 TDD란 무엇인지, 제가 현재 하고 있는 방법이 맞는 것인지, 과연 꼭 필요한 것 인지, 실무에서도 자주 사용하는지 궁금합니다.

[yenawee]

딜러 이름은 항상 '딜러'인데 따로 필드로 가질 필요가 있을까요?

[yenawee]

toString() 메서드는 모든 Object 클래스에 이미 선언되어 있어요. 이 인터페이스는 아무런 강제 사항도 없어보여요, 어떤 클래스든 별도의 메서드를 작성하지 않고도 이 인터페이스를 구현할 수 있습니다

[yenawee]

BettingMoneyInfo는 Map<Name, BettingMoney>를 저장하고 Name 키를 사용하여 값을 조회하지만 Nickname은 equals() 또는 hashCode()를 재정의하지 않으므로 참조 동등성으로 대체됩니다.
e.g) 새로운 Nickname("pobi") != 기존 Nickname("pobi")

[yenawee]

method name 이 행동과 일치하지 않는거같아요. decideStay() 를 확인하는 것 처럼 보입니다!

[yenawee]

Hand는 카드를 건너뛰려는 이유에 대해서는 전혀 알 필요가 없다고 생각해요.
startInclusive 매개변수는 오직 딜러의 특정 규칙, 즉 히든 카드 때문에 존재합니다. 그렇다면 Hand 에 메서드를 오버로딩하는 것 보다 아예 딜러에 로직을 구현하는 것은 어떨까요?

public List<String> getOpenCardNames() {
      List<String> all = getCardNames();
      return all.subList(1, all.size()); // dealer's own concern
  }

[yenawee]

😢 파일 포맷팅 확인해주세요

[yenawee]

안녕하세요 로운!

2단계 잘 구현해주셨네요 😸
코멘트 확인해주세요! (다른 질문들은 코드 리뷰 코멘트를 확인해주세요)

단순히 원시값 하나를 위해 인터페이스를 도입하는 것이 오버 엔지니어링이 아닌지, 실무에서도 비슷하게 활용하는지 궁금합니다.

현재 'Name' interface 때문에 요런 고민이 나온거 같아요. 그런데 생각해보면 인터페이스는 보통 '행위' 를 추상화하는데 사용되지만 Name 은 '상태(Data/Value)' 에 가깝기 때문에 혼란이 온 것이라고 생각해요. 이런 값들은 VO 를 사용해서 유효성 검증을 하는 방식이 일반적인 방법 같다고 생각합니다.

수익금에 대해선 클래스를 생성하지 않고 원시값인 Double로 처리하도록 하였습니다. 수익금은 게임 결과에 따라 배팅 금액을 합산하는 역할만 한다고 생각하여 객체를 만들지 않고 진행하였습니다. 모든 원시값을 포장하는 것이 과연 좋은 것인지 궁금합니다.

모든 원시값을 포장해야 한다는 강박을 가질 필요는 없습니다. 특별한 유효성 검증이나 행위가 없다면요.
하지만 돈, 단위, 식별자, 좌표 등은 VO 로 포장했을때 가지는 이점이 매우 큽니다. 예를 들면 돈을 double 로 관리하면 부동소수점 오차가 생길수 있어서 BigDecimal 을 사용해요. 또 현재 딜러의 수익을 계산하기 위해 -money 처럼 마이너스를 붙이거나 금액 계산 로직 응집도를 위해선 포장하는 것이 안전할 거 같아요.

TDD 에 대해서

TDD 라고 해서 테스트부터 무작정 작성할 수는 없으니 대략적인 설계, 도메인을 머릿속에 그려보는 건 당연하다고 생각해요. 설계가 바뀌어서 테스트를 고치게 되는 것은 초반 설계 고치는 방향때는 그럴수 있지만 계속해서 발생한다면 왜 고치게 되는 것인지, 내 테스트가 '행위'를 잘 테스트하고 있는 것인지 확인해볼 필요성은 있다고 봐요. 지금은 첫 미션이고 단계별로 요구사항이 새로 추가되어서 리팩터링을 했을때 TDD 가 주는 안정감을 느끼기에 너무 초반인 것 같은데 저는 미션 진행하면서 느껴본 적이 많아서 로운도 한번 우테코 진행하면서 체감해보셨으면 하는 바람입니다..🙏
지금 일하면서는 기존 코드에 코드를 덧붙이는 일들이 많기 때문에 사실 테스트 코드부터 먼저 짜는 경우는 극히 드물어요. 하지만 어떻게 짤지 아예 감이 안잡힐때, input, output 생각하고 테스트코드부터 짰던 적이 드물게 있었긴 합니다!