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

[yj9107v]

체크 리스트

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

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

1️⃣ 기능이 추가될 때 어떤 점을 조심해야 할지, 그리고 이를 위해 어떤 공부가 필요한지 궁금합니다

궁성 영역이 추가되면서, 궁성 여부를 Position에서 판단할지 아니면 Palace 클래스를 따로 만들어 관리할지 고민이 컸습니다.
고민 끝에 Position이 궁성 영역까지 함께 다루면 책임이 무거워진다고 생각해, Palace 클래스를 만들어 궁성 영역을 관리하도록 구현했습니다. 그리고 각 기물의 이동 전략에서 궁성 정보를 활용할 수 있도록 MoveStrategy 추상 클래스에 Palace를 필드로 두었습니다. 그 결과, 각 이동 전략이 Palace를 통해 현재 위치나 목적지가 궁성 영역인지 판단하고 이동 가능 여부를 결정하도록 구현했습니다.

다만 구현을 하면서, 객체지향적으로 더 나은 설계를 하려면 어떤 기준으로 판단해야 하는지 감이 잘 잡히지 않았습니다.
스스로 고민해 보기는 했지만, 좋은 설계의 기반이 되는 지식이 부족하다고 느껴 결국은 구현 가능한 방향으로 우선 작성하게 되었습니다.

이런 상황에서 더 나은 설계를 하기 위해서는 어떤 방향으로 고민해 보면 좋을지 궁금합니다.
또한 제 코드를 보셨을 때, 제가 특히 부족하게 느끼고 공부해 보면 좋을 개념이나 주제가 있다면 조언 부탁드립니다.

---

2️⃣ JDBC 연결을 구현할 때의 방향성과, 특히 지양해야 할 부분이 궁금합니다

이번 요구사항에서 DB 연결이 추가되었는데, 관련 지식과 경험이 부족하다 보니 학습과 구현을 병행하면서 시간이 오래 걸렸습니다.
그래서 먼저 큰 방향을 아래와 같이 잡고 구현을 진행했습니다.

1. 복원에 필요한 게임 상태 정의
2. Mapper 구현
3. Repository 인터페이스 구현
4. 인메모리 기반 테스트 및 구현
5. JDBC 구현
6. 애플리케이션 연결

위와 같은 순서로 구현을 쌓아 가며 진행했는데, 이 방향이 적절했는지, 혹은 부족하거나 잘못된 부분이 있었는지 궁금합니다.

또 하나는, DB 연결 코드를 작성하면서 “무엇이 좋지 않은 코드인지”, “무엇을 지양해야 하는지”를 명확하게 판단하지 못한 채 요구사항을 만족시키는 데만 집중했던 것 같습니다.
기본적으로 도메인이 저장 방식을 알지 않아야 한다는 점은 의식했지만, 실제로 JDBC를 처음 연결하고 구현하다 보니 어떤 부분을 특히 조심해야 하는지 잘 모르겠다는 생각이 들었습니다.

DB 연결을 구현할 때 제가 특히 조심해서 봐야 할 부분, 그리고 지양해야 할 설계나 코드 방향이 있다면 조언 부탁드립니다.

---

[pkeugine]

안녕하세요 와이제리, PK입니다.

어제 반가웠어요~
짧은 시간이었지만 만나서 즐거웠고, 좋은 시간 보낸 듯 하네요.

저번 사이클에서 리팩터링에 초점을 맞췄죠,
그 흐름을 잘 이어가 주셔서 PR이 좋아요.
지금 당장 머지해도 괜찮을 듯 하네요.

그래서 이번 리뷰 테마는 다음과 같습니다 :

심화 내용을 가득 담았어요.
우리가 흔히 얘기하는 객체지향이나 책임 이런거 말고...
와이제리 애플리케이션에서 실제로 발생할 수 있는 것들을 기반으로 생각거리 및 제안을 남겼습니다.

내용이 좀 어려울 수도 있습니다. 하지만 꽤 재밌을거예요.

하나씩 잘 생각해보고, 와이제리만의 대응을 (반영 || 반박) 기대할게요.
리뷰 다 확인했다고 판단하면 바로 머지하겠습니다.

얼마 남지 않은 미션, 끝까지 화이팅입니다.
방학 전까지 계속 해피해킹하세요!!! 🪐 🪐 🪐

[pkeugine]

사이클 1 때부터 보인 현상인데, GeneralMoveStrategy 와 GuardMoveStrategy 구현이 완전 일치합니다.
당시는 궁성 구현이 남아있던 때라, 미리 중복을 없애지 않는게 좋다고 생각했어요.
실제로 중복인 로직인지, 그렇게 보이기만 하는건지 감이 완벽히 잡히지 않으니까요.

그런데 지금은 모든 기능 구현이 완료되었으니 안심하고 중복 제거를 해볼 수 있을 듯 합니다.
이러면 아래의 코멘트로 인한 변경도 한 곳만 있을테고요.
확실한 중복을 인지하고 없애보는 경험,
그리고 중복 제거로 인한 변경 범위 최소화를 경험해봅시다. :)

[pkeugine]

canMoveTo 구현을 모든 MoveStrategy에 걸쳐 정말 잘 만들어주셨어요 👍
그런데 GeneralMoveStrategy 쪽에서는 검증을 통과하지 못하면 return false 가 아닌 예외를 던져요.
이왕 boolean을 사용하는거, false 를 반환하여 호출하는 쪽에서 false 일 때의 작업을 이어서 처리하도록 해보면 어떨까요?

[pkeugine]

여기 Path.of("src/main/resources/schema.sql") 은 어떤 경로를 기준으로 해석될까요?

한 번 확인 삼아 프로젝트 루트가 아닌 곳에서 실행해봤는데, NoSuchFileException 이 발생합니다.

이유는 Path.of(...) 가 작업 디렉토리 기준 상대 경로여서예요.
지금은 ./gradlew run 이나 IDE 로 프로젝트 루트에서 실행하니까 우연히 맞는 상태고요.

그런데 나중에 JAR로 빌드해서 배포하면 얘기가 달라집니다. (JAR 가 무엇인지 한 번 학습해보죠)
src/main/resources/ 는 소스 디렉토리라서, 빌드 결과물(JAR) 에는 그 폴더 자체가 존재하지 않아요.
빌드 시점에 src/main/resources/ 의 파일들이 어디로 이동하는지,
그리고 런타임에 그 파일을 어떻게 읽어야 하는지 한번 찾아보시면 좋을 것 같아요.
그리고 수정해보죠.

프로젝트 다른 부분들도 한 번 확인해주세요.

[pkeugine]

사이클 1에서도 up, down 관련하여 비슷한 얘기를 나눴던 것 같은데,
와이제리의 프로젝트에서 코드 네이밍 방식을 봤을 때 이 메서드는 이름이 헷갈려요.
한 번 확인해보시고 와이제리도 동의한다면 적절하게 바꿔보죠.

[pkeugine]

플레이어가 상대 장군을 잡는 순간, 보드는 어떤 흐름으로 출력될까요?
한번 playGame() 이후의 흐름을 따라가보세요.

playGame() 은 먼저 "이동 전" 보드를 출력하고 입력을 받아 기물을 이동해요.
그러니 장군이 사라진 "이동 후" 보드는 보이지 않아요.

결국 플레이어는 자기가 장군을 잡은 순간의 보드를 한 번도 못 보고 (제일 기분 좋은 순간인데…!),
바로 점수랑 "X나라 승" 메시지만 보게 돼요.

이게 왜 생기냐면, 지금 구조에서는 "보드를 그리는 시점" 이 "입력을 받는 시점" 에 묶여 있습니다.
playGame() 안에 렌더 + 입력 + 이동 이 한 덩어리인거죠.
그래서 루프가 입력 없이 빠져나가는 순간 마지막 렌더가 누락되는 거예요.

이 세 가지 책임을 어떻게 분리할 수 있을지 한번 고민해보세요.
분리해두면 게임 종료 시점 뿐만 아니라, 나중에 보드만 다시 그리고 싶을 때
(예: 게임 재개, 복기, undo 기능 등) 도 유연해집니다.

[pkeugine]

리뷰하다가 HorseMoveRule 에 List 클래스 경로가 다 들어가 있는 구현을 찾았어요.
이번에 변경된 사항은 아니지만 수정해줍시다!

[pkeugine]

테스트에서만 사용되는 메서드입니다.

[pkeugine]

와이제리가 class 에 final 을 붙이는 기준이 뭔지 궁금합니다.
잘못됐다는건 아니고, 정말 궁금해서 남기는 질문입니다.

[pkeugine]

Q. 실제로 JDBC를 처음 연결하고 구현하다 보니 어떤 부분을 특히 조심해야 하는지 잘 모르겠다는 생각이 들었습니다. 이 방향이 적절했는지 궁금합니다

잘 만들어주셨습니다.
일부 요소에 대해 코멘트 남겼으니, 그것들 중점으로 잘 고민해주시고 학습한 후 리뷰 반영해보면 완벽할 것 같아요.
리뷰가 없는 부분은 제가 생각했을 때 충분히 괜찮은 구현이라고 생각했다고 보시면 됩니다.

제 스타일을 파악하셨을지 모르겠지만 저는 깔끔하고 너무 오버엔지니어링 되지 않은 결과물을 선호합니다.
그런 의미에서 지금 와이제리 PR은 정말 좋아요.

이제 이번 사이클에서 학습한 DB 접근 방식을 바탕으로 테이블에 여러 row를 넣고 관리해보고,
table join 과 객체들 간의 상호작용을 경험해보면 좋을 듯 합니다.

다음 redo(?) 미션으로 여러 체스 게임을 관리하는 기능을 추가해보는 것을 추천드려요.
너무 '잘한 방법일까', '잘못된 방법일까' 에 초첨을 맞추지는 마시구요, 일단 그 기능을 구현하면
리뷰어가 '아 이건 정말 아닌데' 하는 부분을 잡아줄겁니다.

[pkeugine]

저번 사이클 때 커밋과 git 관리에 대한 얘기를 했었죠.
신경 써주신 모습이 보여서 좋습니다 👍

저는 개인적으로 여기서 더 나아가 커밋 수를 더 줄일 수 있다고 봐요.
이번 사이클은 20 ~ 25개 정도가 적당한 듯 하고요.

커밋을 작게 나누자는 말은 분명 그 장점이 있어서일 겁니다.
그 장점을 가장 잘 살릴 수 있는 커밋 사이즈가 어느정도일지 계속해서 고민해보셨으면 해요.

커밋이 너무 작은 단위라면
롤백을 할 때, 배포를 위해 cherry pick 을 할 때, 프로젝트의 흐름을 파악할 때
어쩔 수 없이 여러 커밋을 함께 보고 관리해야 합니다.
그럴 땐 오히려 너무 작은 단위의 커밋은 불편할 수 있어요. 실수를 발생시킬 가능성도 굉장히 높아지고요.

하지만 사이클 1 때보다 분명히 좋아졌어요.
그러니 조금씩 조금씩 와이제리만의 git commit 분리 감각을 익혀봅시다 :)

[pkeugine]

Q. 이런 상황에서 더 나은 설계를 하기 위해서는 어떤 방향으로 고민해 보면 좋을지 궁금합니다.
또한 제 코드를 보셨을 때, 제가 특히 부족하게 느끼고 공부해 보면 좋을 개념이나 주제가 있다면 조언 부탁드립니다

질문에 대한 답변이 하나 누락되어 추가합니다 :

일단 해당 질문에서 다루는 몇가지 내용은 위 코멘트들에 있습니다.
그런데 공부해 보면 좋을 개념은 바로 떠오르지 않네요.

오히려 저는 여태까지 나온 Java 버전들의 차이,
새로 생긴 java api 관련된 내용 학습 및 실습,
그리고 그걸 프로젝트에 적용하는걸 중점으로 먼저 기본기를 다지고 레벨 2에 들어가보면 어떨까합니다.

와이제리가 우테코에서 Java 마스터가 되는거죠.
이 명성과 실력이 ㅎㅎ 분명 앞으로의 우테코 과정 및 커리어에서 굉장히 큰 도움이 될 겁니다.

요즘 AI 가 워낙 뛰어나니 그걸 활용해서 공부하기도 너무 좋고요.
강력 추천드립니다.