[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 흑곰 미션 제출합니다.

[jyt6640]

안녕하세요 로키 !

이것저것 일정이 있어서 사이클 2가 조금 늦어졌네요 ㅠㅠ
항상 제 코드를 열심히 봐주시는 로키 정말 감사하고 이번에도 열심히 배울게요!!

체크 리스트

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

학습 내용

픽스쳐

이번 리뷰를 통해 픽스쳐라는 개념을 처음 정리해봤어요.

픽스쳐는 테스트를 수행하기 위해 미리 준비하는 데이터 또는 상태라고 이해했습니다.
예를 들어 댓글 작성 테스트를 한다면, 댓글 작성 전에 필요한 회원 정보와 게시글 정보가 픽스쳐라고 될 수 있다고 생각이 들었습니다.

결국 픽스쳐의 목적은 테스트가 항상 같은 환경에서 일관되게 실행되도록 만드는 것이라고 이해했습니다.

이 관점에서 보면 현재 PositionInfo.from(List)는 테스트 편의를 위한 생성 헬퍼의 성격이 띄었다고 생각이 들었고 로키가 리뷰를 달아준 내용대로 test 패키지의 fixture로 분리하는 방향이 더 적절하다고 느꼈습니다.

표준 예외 선택 기준

표준 예외도 이번 기회에 다시 정리해보았습니다.

IllegalArgumentException

• 전달한 인자 자체가 잘못된 경우에 사용하는 예외

IllegalStateException

• 인자는 정상이어도, 객체의 현재 상태 때문에 동작을 수행할 수 없는 경우에 사용하는 예외
  장기 도메인 기준으로는 아래처럼 이해했습니다.

제가 이해한 두 예외의 차이는 사용자가 이상한 값을 입력하면 위의 예외가 맞고 객체의 상태로 다른 동작을 할 수 없을 때는 상태로 예외를 내보내는 것이라고 이해했습니다.

Point 캐시 전략

Point는 이번 단계에서 equals/hashCode를 구현하지 않고 캐시 기반으로 관리했습니다.

이유는 장기판 좌표는 9 x 10의 고정된 유한 집합이기 때문에 Point.of(x, y)를 통해 동일 좌표를 동일 인스턴스로 재사용하도록 구성했고 private constructor + static factory로 생성 경로를 제한해 외부에서 임의의 동일 좌표 인스턴스가 생성되지 않도록 했습니다.

현재 장기판은 크기가 고정되어 있고, 보드마다 새로운 좌표 체계가 생기는 구조가 아니라고 판단해 이 방식을 선택했습니다.

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

1. 경로 추상화

현재의 전략은 시작점과 끝점 사이의 경로를 반환하는 구조로 되어있습니다.
그 사이에 경로를 반환하고 기물이 있는지를 판단하는 로직으로 설계가 되어 있는데 다른 크루들과 얘기를 나눠봤을 때에는 수학적으로 계산하기 보다 하드코딩을 해서 방향으 직접 명시를 했을 때의 장점이 있다고 생각이 들었습니다.

만약 리뷰어가 장기를 구현하신다고 하면 수학적으로 경로를 계산을 진행할 것인지 방향을 직접 명시해서 갈 수 있는지 없는지를 판단하실 것인지에 대해서 궁금합니다.

2. 설계의 정도

페어 프로그래밍을 하면서 설계를 어느 정도까지 구체화한 뒤 구현에 들어가야 하는지 고민이 들었습니다.

저는 비교적 추상화된 수준까지 설계해온 상태였고, 페어는 조금 더 구체화된 상태였습니다. 다행히 큰 흐름은 비슷해서 빠르게 구현으로 넘어갈 수 있었지만 그만큼 설계 과정에서 더 고민해볼 수 있는 여지가 줄어들었다고 느꼈습니다.

구현 속도는 빨라서 좋았다는 장점이 있었지만 설계의 깊이 측면에서는 아쉬움도 남았습니다.
리뷰어분께서는 페어 프로그래밍 상황에서 설계를 어느 정도 수준까지 맞춘 뒤 구현에 들어가는 것이 적절하다고 생각하시는지 궁금합니다.