[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 로치 미션 제출합니다. by bhoon716 · Pull Request #343 · woowacourse/java-janggi

bhoon716 · 2026-04-09T10:21:42Z

체크 리스트

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

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

DB에 있는 데이터를 다시 도메인으로 조립을 어떻게 하는게 좋을지가 궁금합니다.

지금 구현한 방식은 도메인이 레포지토리를 모르게 하기 위해서, 레포지토리 내에서 하나하나 조립하고 있는데,
이런 방식은 처음 사용해봐서 제대로 했는지 모르겠네요.. 해당 부분 집중적으로 봐주시면 감사하겠습니다!

- 상태 패턴 도입

Gomding

안녕하세요 로치!
사이클2 구현하느라 고생하셨어요 👍
전체적으로 잘 구현해주셨네요
코멘트 남겼으니 의견 나눠보면 좋겠어요~

궁금하신 부분 있으면 언제든 DM이나 코멘트 남겨주세요~

Gomding · 2026-04-09T11:13:10Z

src/main/java/repository/JdbcJanggiGameRepository.java

DB에 있는 데이터를 다시 도메인으로 조립을 어떻게 하는게 좋을지가 궁금합니다.

지금 구현한 방식은 도메인이 레포지토리를 모르게 하기 위해서, 레포지토리 내에서 하나하나 조립하고 있는데,
이런 방식은 처음 사용해봐서 제대로 했는지 모르겠네요.. 해당 부분 집중적으로 봐주시면 감사하겠습니다!

먼저 로치는 어떤 의도로 구현하셨는지 궁금해요!

도메인이 레포지토리를 몰라야하는 이유는 무엇일까요? 어떤 장점이 있나요?

도메인이 레포지토리를 알면 어떤 단점이 있을까요!

레포지토리 내에서 하나하나 조립하고 있는 방식말고 다른 방법도 고민해보셨을까요?

해당 방식을 선택하신 이유도 궁금해요!

도메인이 레포지토리를 알게 되면 도메인 외부의 변경이 도메인까지 영향을 끼친다고 생각했습니다. 만약 테이블 구조가 변경되거나, Jdbc에서 다른 방식으로 변경되는 일이 발생했을 때, 도메인에도 영향을 끼칠 수 있다고 생각했습니다.
만약 모른다면 위와 같은 변경에도 도메인이 수정되지 않아서 유연한 코드로 할 수 있습니다.

다른 방식이 잘 떠오르지 않아서 일단 Repository에서 ResultSet을 꺼내오고, 필요한 타입으로 매핑하고, 다시 객체로 조립하는 방식으로 진행했습니다. 지금 떠오르는 생각으로는 Mapper 클래스를 따로 두면 어느정도는 분리가 가능할 것 같긴 합니다.

src/main/java/config/DataSourceFactory.java

src/main/java/controller/JanggiController.java

Gomding · 2026-04-09T11:20:06Z

src/main/java/domain/board/Direction.java

+
+import java.util.List;
+
+public record Direction(int column, int row) {


enum 으로 표현하는 방법도 있겠네요! 😃

enum으로 바꾸면 Direction.of(col, row)를 사용하지 못해서, 만약에 정의하지 않은 Direction이 필요해지면 새로운 enum 필드를 추가해야해서 오히려 더 불편할 것 같다는 생각이 듭니다!
지금도 '상'이랑 '마'에서 (2, 3), (1, 2) 등등 사용하고 있는데, 모두 enum으로 관리하기엔 조금 번거롭다고 생각합니다.

enum으로 바꾸면 Direction.of(col, row)를 사용하지 못해서, 만약에 정의하지 않은 Direction이 필요해지면 새로운 enum 필드를 추가해야해서 오히려 더 불편할 것 같다는 생각이 듭니다!

Direction 에 enum 요소 추가하는것 VS 새로운 Piece 객체 또는 기존것에 새로운 방향 직접 선언하기
둘 다 비슷한 코드가 발생할 것 같은데 enum 에 요소 추가하는것만 불편한 이유가 있을까요?
로치가 불편함을 느끼는 이유가 단순히 필드를 추가해서가 맞을까? 라는 의문이 들어서요~

(enum 변경은 반영하지 않으셔도 좋아요! 의견만 공유해주세요 ㅎㅎ)

장기 미션에서는 그럴 일이 없지만, 만약에 프로그램에서 동적으로 변하는 Direction이 필요해지면 enum으로는 해당 Direction으로 관리할 수 없다고 생각합니다.
또한, 필요한 Direction이 더 추가가 된다면, 제가 사용한 방식에서는 필요한 부분에 Direction.of(col, row)만 작성만 해주면 되는데, enum 방식은 해당 Direction을 의미하는 enum 요소를 추가하고, 필요한 부분애서 해당 요소를 가져와야 하기 때문에 더 불편하다고 생각했습니다!

기존 방식

// 호출자 Positon next = now.move(Direction.of(2, 2));

enum 방식

// enum public enum Direction { // 생략.. RIGHT_TWO_DOWN_TWO(2, 2); }

// 호출자 Position next = now.move(Direction.RIGHT_TWO_DOWN_TWO);

Gomding · 2026-04-09T11:21:10Z

src/main/java/domain/state/GameState.java

+import domain.piece.Team;
+import java.util.List;
+
+public interface GameState {


상태 패턴을 사용하신것 같네요!
상태 패턴이 필요하다고 판단하신 이유가 궁금해요~

상태 패턴을 사용하지않고 구현하는것과 어떤 차이가 있었나요?

상태패턴을 사용한 가장 큰 이유는 사실 상태패턴을 사용해보고 싶어서 였습니다.
실제로 사이클 1에서는 상태패턴 없이 구현하고 있었는데, 사이클 2에서 승리 조건을 구현하면서 상태패턴을 추가했습니다.

사실 상태패턴을 이용해도 아직까지는 큰 차이는 못 느꼈습니다.
물론 다른 상태가 추가되면 자연스럽고 쉽게 추가를 할 순 있겠지만, 현재는 그럴 일이 없어서 굳이 안 넣어도 될 것 같습니다!

상태패턴을 사용한 가장 큰 이유는 사실 상태패턴을 사용해보고 싶어서 였습니다.

학습을 위한 도입 💯 💯 💯

상태패턴 도입 후 복잡도가 올라갔다고 느낀적은 없었을까요?
기존 코드가 더 가독성이 좋았다던지..

장기에서는 기존 코드가 오히려 더 읽기 쉬웠고, 상태 패턴을 도입했을 때 얻을 수 있는 이점도 크지 않았던 것 같습니다.
오히려 State를 별도로 관리해야 해서 전체적인 복잡도만 조금 높아진 느낌이었습니다.
그나마 긍정적이었던 점은 Controller가 Team을 직접 관리하지 않게 되면서, 그 부분이 약간 더 간결해졌다는 정도였습니다.

다음에 상태 패턴 도입을 다시 고려하게 된다면, 상태의 수가 충분히 많은지, 추후에 상태의 추가나 변경이 자주 발생할 가능성이 있는지 등을 먼저 따져본 뒤 적용할 것 같습니다.

src/main/java/repository/JdbcJanggiGameRepository.java

src/main/java/config/DatabaseInitializer.java

src/main/java/repository/JdbcJanggiGameRepository.java

Gomding · 2026-04-09T11:51:19Z

src/main/java/repository/JdbcJanggiGameRepository.java

+import java.util.Optional;
+import javax.sql.DataSource;
+
+public class JdbcJanggiGameRepository implements JanggiGameRepository {


이름이 Repository 인 이유는 무엇일까요?

네이밍에 크게 의미를 두진 않았습니다..
DAO, Repository 중에서 Repository가 더 친숙해서 사용하게 되었습니다.

좀 더 찾아보니까, 둘 다 비슷하지만 DAO는 저장소에 접근하는 기술 중점이고, Repository는 도메인 관점에서 데이터를 다루는 추상화 계층이라고 합니다.
해당 관점으로 보면 제가 만든 건 Repository보단 DAO가 좀 더 맞다고 생각합니다!

오.. 적절하게 학습해주셨네요~
지금 단계에서는 굳이 DAO 와 Repository 를 구분하지 않아도 된다고 생각하지만
말씀해주신대로 분리해서 볼 수도 있습니다 :)

bhoon716

안녕하세요, 찰리!

사이클 2는 금방 끝낼 수 있을 거라고 생각했는데, 막상 진행해보니 생각보다 훨씬 어렵고 깊게 고민할 부분이 많다는 걸 많이 느끼고 있습니다. 특히 Repository에 대해 계속 고민되는 것 같습니다.

항상 제가 생각하지 못한 지점을 구체적으로 짚어주시고, 단순히 정답을 주기보다 스스로 더 고민해볼 수 있게 질문 형태로 이끌어주셔서 정말 많이 배우고 있습니다.

항상 꼼꼼한 피드백 주셔서 감사합니다!!! 🙇‍♂️

src/main/java/config/DataSourceFactory.java

bhoon716 · 2026-04-10T04:24:57Z

src/main/java/domain/board/Direction.java

+
+import java.util.List;
+
+public record Direction(int column, int row) {


enum으로 바꾸면 Direction.of(col, row)를 사용하지 못해서, 만약에 정의하지 않은 Direction이 필요해지면 새로운 enum 필드를 추가해야해서 오히려 더 불편할 것 같다는 생각이 듭니다!
지금도 '상'이랑 '마'에서 (2, 3), (1, 2) 등등 사용하고 있는데, 모두 enum으로 관리하기엔 조금 번거롭다고 생각합니다.

bhoon716 · 2026-04-10T05:12:49Z

src/main/java/domain/board/Position.java

지금 장기판의 최대/최소 row, column도 알고 있어서 궁성 정보도 알고 있어서 괜찮을 것 같다고 생각했습니다.
다른 방식에는 뭐가 있을까 생각해보고 다른 크루와 얘기해봤습니다.

Palace 클래스를 만든다.

PalaceMoveStrategy 추상 클래스를 만든다.

기물별 PalaceMoveStrategy를 추가한다.

1번 같은 경우는 Palace 클래스가 Positon에 대한 유틸 클래스가 되는 것처럼 느껴졌고,
2, 3번 같은 경우는 TDA 원칙에 위배된다고 판단했습니다.

지금 Position이 책임이 적진 않지만, 객체지향적으로 더 나은 방향이 떠오르지 않아서 이대로가 최선이라고 생각합니다!

src/main/java/domain/movestrategy/ElephantMoveStrategy.java

src/main/java/domain/state/FinishedState.java

src/main/java/repository/JanggiGameRepository.java

bhoon716 · 2026-04-10T08:00:01Z

src/main/java/repository/JdbcJanggiGameRepository.java

도메인이 레포지토리를 알게 되면 도메인 외부의 변경이 도메인까지 영향을 끼친다고 생각했습니다. 만약 테이블 구조가 변경되거나, Jdbc에서 다른 방식으로 변경되는 일이 발생했을 때, 도메인에도 영향을 끼칠 수 있다고 생각했습니다.
만약 모른다면 위와 같은 변경에도 도메인이 수정되지 않아서 유연한 코드로 할 수 있습니다.

다른 방식이 잘 떠오르지 않아서 일단 Repository에서 ResultSet을 꺼내오고, 필요한 타입으로 매핑하고, 다시 객체로 조립하는 방식으로 진행했습니다. 지금 떠오르는 생각으로는 Mapper 클래스를 따로 두면 어느정도는 분리가 가능할 것 같긴 합니다.

bhoon716 · 2026-04-10T08:08:38Z

src/main/java/repository/JdbcJanggiGameRepository.java

+import java.util.Optional;
+import javax.sql.DataSource;
+
+public class JdbcJanggiGameRepository implements JanggiGameRepository {


네이밍에 크게 의미를 두진 않았습니다..
DAO, Repository 중에서 Repository가 더 친숙해서 사용하게 되었습니다.

좀 더 찾아보니까, 둘 다 비슷하지만 DAO는 저장소에 접근하는 기술 중점이고, Repository는 도메인 관점에서 데이터를 다루는 추상화 계층이라고 합니다.
해당 관점으로 보면 제가 만든 건 Repository보단 DAO가 좀 더 맞다고 생각합니다!

src/main/java/repository/JdbcJanggiGameRepository.java

Gomding

안녕하세요 로치!
고민과 함께 잘 수정해주셨네요 👍
추가로 코멘트 남겼으니 확인해주세요!

궁금한 점 있으면 언제든 DM 이나 코멘트 남겨주세요~

Gomding · 2026-04-12T02:05:11Z

src/main/java/domain/state/GameState.java

+import domain.piece.Team;
+import java.util.List;
+
+public interface GameState {


상태패턴을 사용한 가장 큰 이유는 사실 상태패턴을 사용해보고 싶어서 였습니다.

학습을 위한 도입 💯 💯 💯

상태패턴 도입 후 복잡도가 올라갔다고 느낀적은 없었을까요?
기존 코드가 더 가독성이 좋았다던지..

Gomding · 2026-04-12T02:05:26Z

src/main/java/domain/board/Direction.java

+
+import java.util.List;
+
+public record Direction(int column, int row) {


enum으로 바꾸면 Direction.of(col, row)를 사용하지 못해서, 만약에 정의하지 않은 Direction이 필요해지면 새로운 enum 필드를 추가해야해서 오히려 더 불편할 것 같다는 생각이 듭니다!

Direction 에 enum 요소 추가하는것 VS 새로운 Piece 객체 또는 기존것에 새로운 방향 직접 선언하기
둘 다 비슷한 코드가 발생할 것 같은데 enum 에 요소 추가하는것만 불편한 이유가 있을까요?
로치가 불편함을 느끼는 이유가 단순히 필드를 추가해서가 맞을까? 라는 의문이 들어서요~

(enum 변경은 반영하지 않으셔도 좋아요! 의견만 공유해주세요 ㅎㅎ)

Gomding · 2026-04-12T02:11:58Z

src/main/java/repository/JdbcJanggiGameRepository.java

+import java.util.Optional;
+import javax.sql.DataSource;
+
+public class JdbcJanggiGameRepository implements JanggiGameRepository {


오.. 적절하게 학습해주셨네요~
지금 단계에서는 굳이 DAO 와 Repository 를 구분하지 않아도 된다고 생각하지만
말씀해주신대로 분리해서 볼 수도 있습니다 :)

Gomding · 2026-04-12T02:15:20Z

src/main/java/repository/JdbcJanggiGameRepository.java

+        if ("CHO".equals(currentTeam)) {
+            return new ChoPlayingState();
+        }
+        return new HanPlayingState();


enum 같은것을 다룰때는 else 를 주의해서 사용해야한다는 것을 명심해주세요! ㅎㅎ
else 로 반환되는 기본값은 편리하지만 독이 될 수 있습니다~

Gomding · 2026-04-12T02:17:34Z

src/main/java/domain/state/FinishedState.java

+
+    @Override
+    public List<Position> getPiecePositions(Board board) {
+        throw new IllegalStateException("게임이 종료되었습니다.");


잘못된 상태라는게 맞는것 같지만 UnsupportedOperationException 을 던지는게 더 명확할 수 있어요~
지원하지 않는 기능이라는것을 알려야하는 상황이니까요

Gomding · 2026-04-12T02:28:53Z

src/test/java/domain/movestrategy/GeneralMoveStrategyTest.java

+        pieces.put(from, Piece.choPieceOf(PieceType.GENERAL));
+        pieces.put(Position.of(10, 1), Piece.choPieceOf(PieceType.GENERAL));


cho 장군이 두개지요..? 😳

Gomding · 2026-04-12T02:32:55Z

src/main/java/config/DatabaseInitializer.java

+import java.sql.Statement;
+import javax.sql.DataSource;
+
+public final class DatabaseInitializer {


이것도 유틸클래스이니 DataSourceFactory 처럼 생성자를 private 으로 닫아두죠!

Gomding · 2026-04-12T02:37:42Z

src/main/java/repository/JdbcJanggiGameRepository.java

+                gameDao.update(connection, gameId, janggiGame);
+                pieceDao.deleteByGameId(connection, gameId);
+                pieceDao.saveAll(connection, gameId, janggiGame.getPieces());
+                connection.commit();


piece 부분 업데이트 하는 방식이 아닌
전체를 삭제하고 전체를 재저장하는 방식으로 하셨군요!

로치는 어떤 이유로 이런 방식을 선택하셨는지 궁금해요 :)

+) 이벤트 소싱 방식도 고민해보셨을까요?
아래 글을 가볍게 읽고 이벤트 소싱에 대해서 맛만 보셔도 좋겠어요!
(CQRS 같이 현재 단계에서 너무 무거운 지식들은 패스하시고 이벤트 소싱이 뭐지? 라는것만 집중해서 읽어보시면 됩니다! ㅎㅎ)

https://sabarada.tistory.com/231

매개변수가 JanggiGame이다보니, 업데이트 된 피스만 찾아서 변경해주는 것보다 전체를 삭제하고 다시 저장하는 로직이 좀 더 간편할 것 같아서 해당 방식을 채택했습니다!

+) 이벤트 소싱 글 잘 봤습니다! 감사합니다!
처음 듣는 키워드였는데 DB 도입 초기에 고민했던 부분과 비슷해서 이해하는데 어렵진 않았습니다.
초기에는 맨 처음 장기판 초기화 상태랑 move_history를 저장하려고 했었습니다. 이러면 나중에 무르기 기능도 추가하기 쉽고, 매 라운드를 저장하는 방식보다 저장공간도 덜 차지할 수 있어서 좋았습니다.
하지만 게임을 불러올 때마다 모든 move_history를 재연해야 해서 포기했었습니다🥲

Gomding · 2026-04-12T02:39:11Z

src/main/java/repository/JdbcJanggiGameRepository.java

+        } catch (SQLException exception) {
+            throw new IllegalStateException("게임을 저장하는 중 오류가 발생했습니다.");
+        }


이전에는 IllegalStateException 예외 생성시 cause 에 SQLException 을 주입해주셨는데
이번에 수정하면서 없어졌군요 😳
어떤 이유에서 수정하셨을까요?

문제가 있어서 에러가 발생했을 때 SQLException 의 내용없이 디버깅을 빠르게 할 수 있을까요!

수정하면서 cause를 함께 넘기던 부분이 빠졌네요.
별도 의도가 있었다기보다는 리팩토링 과정에서 놓쳤습니다...

Gomding · 2026-04-12T02:40:29Z

src/test/java/repository/JdbcJanggiGameRepositoryTest.java

+        Long savedId = janggiGameRepository.save(janggiGame);
+
+        // then
+        assertThat(savedId).isEqualTo(1L);


id 가 1인지 검증하는것은 조금 위험할 수 있어요!
당장은 성공하지만 테스트 환경, 순서에 따라 실패할 수도 있는 검증입니다 :)

어떻게 검증하면 좋을까요~

+) id 만 검증하면 정상적으로 저장됐는지 충분히 검증하는것일까요?

일단 savedId != null 인지 확인하고, savedId로 다시 findById를 했을 때 동일한 데이터가 나오는지 확인하는게 더 좋을 것 같네요!

만약 Mockito를 쓰면 verify()를 추가하는 것도 괜찮다고 생각합니다.

…Exception 변경

bhoon716

리뷰 감사해요 찰리!
이번에도 많은 깨달음과 새로운 지식들을 배운 것 같아요!!
아직도 많이 부족하지만 계속 노력해볼게요!!

bhoon716 · 2026-04-12T09:37:32Z

src/main/java/domain/board/Direction.java

+
+import java.util.List;
+
+public record Direction(int column, int row) {


장기 미션에서는 그럴 일이 없지만, 만약에 프로그램에서 동적으로 변하는 Direction이 필요해지면 enum으로는 해당 Direction으로 관리할 수 없다고 생각합니다.
또한, 필요한 Direction이 더 추가가 된다면, 제가 사용한 방식에서는 필요한 부분에 Direction.of(col, row)만 작성만 해주면 되는데, enum 방식은 해당 Direction을 의미하는 enum 요소를 추가하고, 필요한 부분애서 해당 요소를 가져와야 하기 때문에 더 불편하다고 생각했습니다!

기존 방식

// 호출자 Positon next = now.move(Direction.of(2, 2));

enum 방식

// enum public enum Direction { // 생략.. RIGHT_TWO_DOWN_TWO(2, 2); }

// 호출자 Position next = now.move(Direction.RIGHT_TWO_DOWN_TWO);

bhoon716 · 2026-04-12T10:19:59Z

src/main/java/domain/state/GameState.java

+import domain.piece.Team;
+import java.util.List;
+
+public interface GameState {


장기에서는 기존 코드가 오히려 더 읽기 쉬웠고, 상태 패턴을 도입했을 때 얻을 수 있는 이점도 크지 않았던 것 같습니다.
오히려 State를 별도로 관리해야 해서 전체적인 복잡도만 조금 높아진 느낌이었습니다.
그나마 긍정적이었던 점은 Controller가 Team을 직접 관리하지 않게 되면서, 그 부분이 약간 더 간결해졌다는 정도였습니다.

다음에 상태 패턴 도입을 다시 고려하게 된다면, 상태의 수가 충분히 많은지, 추후에 상태의 추가나 변경이 자주 발생할 가능성이 있는지 등을 먼저 따져본 뒤 적용할 것 같습니다.

bhoon716 · 2026-04-12T10:28:17Z

src/main/java/repository/JdbcGameDao.java

+        }
+
+        String currentTeam = resultSet.getString("current_team");
+        if (CHO_TEAM_NAME.equals(currentTeam)) {


저도 이 방식이 더 안전해서 좋을 것 같습니다!

bhoon716 · 2026-04-12T10:45:55Z

src/main/java/repository/JdbcJanggiGameRepository.java

+        } catch (SQLException exception) {
+            throw new IllegalStateException("게임을 저장하는 중 오류가 발생했습니다.");
+        }


수정하면서 cause를 함께 넘기던 부분이 빠졌네요.
별도 의도가 있었다기보다는 리팩토링 과정에서 놓쳤습니다...

bhoon716 · 2026-04-12T10:48:35Z

src/test/java/domain/movestrategy/GeneralMoveStrategyTest.java

+        pieces.put(from, Piece.choPieceOf(PieceType.GENERAL));
+        pieces.put(Position.of(10, 1), Piece.choPieceOf(PieceType.GENERAL));


bhoon716 · 2026-04-12T11:02:09Z

src/test/java/repository/JdbcJanggiGameRepositoryTest.java

+        Long savedId = janggiGameRepository.save(janggiGame);
+
+        // then
+        assertThat(savedId).isEqualTo(1L);


일단 savedId != null 인지 확인하고, savedId로 다시 findById를 했을 때 동일한 데이터가 나오는지 확인하는게 더 좋을 것 같네요!

만약 Mockito를 쓰면 verify()를 추가하는 것도 괜찮다고 생각합니다.

bhoon716 · 2026-04-12T15:48:12Z

src/main/java/repository/JdbcJanggiGameRepository.java

+                gameDao.update(connection, gameId, janggiGame);
+                pieceDao.deleteByGameId(connection, gameId);
+                pieceDao.saveAll(connection, gameId, janggiGame.getPieces());
+                connection.commit();


매개변수가 JanggiGame이다보니, 업데이트 된 피스만 찾아서 변경해주는 것보다 전체를 삭제하고 다시 저장하는 로직이 좀 더 간편할 것 같아서 해당 방식을 채택했습니다!

+) 이벤트 소싱 글 잘 봤습니다! 감사합니다!
처음 듣는 키워드였는데 DB 도입 초기에 고민했던 부분과 비슷해서 이해하는데 어렵진 않았습니다.
초기에는 맨 처음 장기판 초기화 상태랑 move_history를 저장하려고 했었습니다. 이러면 나중에 무르기 기능도 추가하기 쉽고, 매 라운드를 저장하는 방식보다 저장공간도 덜 차지할 수 있어서 좋았습니다.
하지만 게임을 불러올 때마다 모든 move_history를 재연해야 해서 포기했었습니다🥲

bhoon716 added 19 commits April 6, 2026 22:43

refactor(controller): 중복 메서드 제거 및 에러메시지 범위 출력 버그 수정

05979e7

feat(cannon): 브릿지 찾을 때, 현재 위치가 보드 내부인지 확인하는 로직 추가

28a1378

fix(general): 장군 이동 위치 검사 범위 수정

a0a4c37

refactor(name): 에러 메시지 String.format 적용

b56f063

feat(controller): 선택한 기물이 이동할 수 있는 위치가 없다면 예외 처리 및 기물 재선택 기능 추가

2e60576

test(cannon): 포는 포를 잡을 수 없음 테스트 추가

9889553

fix(elephant): 테스트에서 상이 아니라 차를 배치한 문제 수정

086e9eb

docs(readme): 기능 요구사항 업데이트

c7f86ef

chore(direction): Delta -> Directions 이름 변경

511afd9

test(guard): 궁성 관련 이동 테스트 추가

caf9b91

feat(guard): 사 궁성 로직 구현

f5ee827

feat(general): 궁 궁성 관련 행마법 구현

0413083

feat(chariot): 차 궁성 관련 행마법 구현

bdfdeda

feat(soldier): 졸/병 궁성 관련 행마법 구현

e0fd114

feat(cannon): 포 궁성 관련 행마법 구현

fc82128

feat(JanggiGame): 게임 승패 판별 및 게임 종료 구현

d69a7a5

- 상태 패턴 도입

feat(score): 매 턴마다 각 플레이어 점수 출력

310a58e

docs(readme): 완료한 기능 체크

a5d796d

feat(db): jdbc(h2) 연결 및 장기 게임 저장, 불러오기 추가

374eea0

Gomding requested changes Apr 9, 2026

View reviewed changes

bhoon716 added 10 commits April 10, 2026 12:47

refactor(JanggiGame): 첫 플레이어 상수 Controller -> JanggiGame 이동

a5b1456

refactor(controller): 게임 시작 시 잘못된 입력 재시도 로직 추가 및 dto 변환 로직 from 추가

c2e370d

refactor(team): 보너스 점수 관리 board -> team 이임

338cef0

refactor(direction): 미사용 상수 제거

f273c64

refactor(position): createDiagonalEdges() 불변 Map 반환 및 미사용 변수, 메서드 삭제

18442fc

refactor(general):미사용 상수 삭제

a2eba6d

refactor(elephant): isBlocked()에서 block되면 바로 리턴되도록 수정

9a085a9

refactor(gamestate): getTeam(), getWinner() 분리

e0baa39

fix(elephant): 테스트에서 chariot이 잘못 들어가있던 버그 수정

2c7fb40

refactor(repository): Repository, DAO 분리

4042b38

bhoon716 commented Apr 11, 2026

View reviewed changes

Gomding requested changes Apr 12, 2026

View reviewed changes

bhoon716 added 11 commits April 12, 2026 18:24

refactor(DatabaseInitializer): 생성자 private, 매개변수 final 추가

0bf71ff

refactor(chariot): 메서드 분리

57fc194

refactor(GameState): 예외 IllegalStateException -> UnsupportedOperation…

fae4c2c

…Exception 변경

refactor(GameDao): 상수 수정

d7742a1

refactor(JanggiGameDao): SQLException cause를 같이 던지도록 수정

4308cef

fix(test): 테스트에서 기물의 진영이 잘못되있던 버그 및 테스트 위치 수정

415ce2e

refactor(GameDao): GameStateFactory 도입으로 State 객체 생성 로직 분리

1e345c1

fix(output): 종료된 게임 불러오면 예외 발생하는 버그 수정

ef05d72

chore: 오타 수정, 미사용 import 제거, import 순서 정렬, final 키워드 추가

e9159c6

chore: 상수 미사용 변경, 오타 수정

4eecb22

docs(readme): 기능 요구사항 완료 업데이트

aa696f7

bhoon716 commented Apr 12, 2026

View reviewed changes


		import java.util.List;

		public record Direction(int column, int row) {

		pieces.put(from, Piece.choPieceOf(PieceType.GENERAL));
		pieces.put(Position.of(10, 1), Piece.choPieceOf(PieceType.GENERAL));

Conversation

bhoon716 commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

체크 리스트

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

DB에 있는 데이터를 다시 도메인으로 조립을 어떻게 하는게 좋을지가 궁금합니다.

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

DB에 있는 데이터를 다시 도메인으로 조립을 어떻게 하는게 좋을지가 궁금합니다.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bhoon716 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

bhoon716 commented Apr 9, 2026 •

edited

Loading