[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 바니 미션 제출합니다. by frombunny · Pull Request #257 · woowacourse/java-janggi

frombunny · 2026-03-29T10:07:41Z

안녕하세요, 베루스! 만나뵙게 되어 반갑습니다.
저는 이번 장기 미션 리뷰를 요청드리게 된 바니입니다🐰
사전에 DM을 통해 말씀드린 것처럼 리뷰를 받은 후 변경 사항이 많아질 것으로 예상하고 있습니다.
그래서 변경 사항이 생긴 후, 코드 및 설계에 대한 질문도 더 추가될 예정입니다ㅠㅠ
추가적으로, 현재 테스트코드가 미흡합니다. 예외 케이스는 대부분 테스트코드를 작성하지 못했습니다🥲
이 부분은 피드백 반영과 함께 테스트코드를 보강하도록 하겠습니다.
시간 내어 리뷰해주셔서 감사합니다🙇‍♂️

체크 리스트

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

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

1. Board와 Piece의 책임을 어떻게 나누어야 하는지가 가장 큰 고민이었습니다.

현재 구현에서는 기물 이동을 검증할 때 Board와 Piece가 한 번 더 왕복하는 구조가 됩니다.

먼저 Piece가 다른 기물의 존재를 고려하지 않고, 자신의 이동 규칙만으로 해당 위치까지 갈 수 있는지를 판단합니다.
그다음 Board가 실제 경로를 확인해서, 중간에 어떤 기물이 있는지 찾아냅니다.
마지막으로 그 정보를 다시 Piece에게 전달해서, 최종적으로 이동 가능한지 판단하게 합니다.

이 구조를 만들면서 저도 이렇게 두 번 왔다 갔다 할 수 밖에 없을까?라는 생각을 계속 했습니다.
더 단순하게 만들려면 Piece가 보드의 상태를 더 많이 알게 하는 방법도 있었을 것 같습니다.
그런데 저는 Piece가 Board의 전체 상태나 Map<Position, Piece> 같은 정보를 직접 아는 것은 적절하지 않다고 느꼈습니다.

기물은 스스로 어떻게 움직이는가에 집중하고, 보드는 현재 어떤 기물이 어디에 놓여 있는가를 관리하는 쪽이 더 자연스럽다고 생각했습니다.
그래서 다소 왕복이 생기더라도, 각 객체가 알아야 할 정보의 범위를 무리하게 넓히지 않는 방향을 우선했습니다.
완전히 확신이 있어서 선택한 구조라기보다는, 제가 현재 기준에서 가장 덜 어색하다고 느낀 선택에 가깝습니다.

이 부분에서는 제가 객체 간 결합을 줄이기 위해 내린 판단이 실제로도 타당한지, 혹은 오히려 책임이 애매하게 섞인 구조가 되었는지를 중심으로 봐주시면 감사하겠습니다.

2. 이동 검증 흐름을 Board가 조정하는 현재 구조가 자연스러운지 궁금합니다.

지금 Board는 단순히 기물 배치만 관리하는 역할을 넘어서,
실제로 이동 과정 전체를 조정하는 역할도 함께 가지고 있습니다.

예를 들어 move() 안에서

출발 기물과 도착 기물을 조회하고
경로 정보를 만들고
이동 가능 여부를 검증한 뒤
실제로 상태를 변경합니다.

저는 이 과정이 장기판이 현재 판의 상태를 바탕으로 이동을 중재한다는 점에서 어느 정도 자연스럽다고 느꼈습니다.
다만 한편으로는 Board가 점점 많은 흐름을 쥐게 되면서 비대해질 수도 있겠다는 생각도 들었습니다.

그래서 현재처럼 Board가 이동 검증의 흐름을 조정하는 구조가 괜찮은지,
아니면 지금보다 더 역할을 분리하는 방향이 나은지 의견을 듣고 싶습니다.

3. 설계 과정에서 디자인 패턴을 어떻게 바라봐야 하는지가 여전히 어렵습니다.

이번 미션을 하면서 구현 자체보다도, 이 상황에서 어떤 패턴을 떠올려야 하는가가 더 어렵게 느껴졌습니다.
사실 블랙잭 미션에서도 상태 패턴을 스스로 떠올리지 못했는데, 이번에도 비슷한 고민을 많이 했습니다.

구현하면서 Board가 이동 흐름을 조정하고, 기물별 이동 규칙은 각 전략 또는 기물 쪽에 두는 방향으로 가다 보니
결과적으로는 특정 패턴의 형태와 닮아 보인다는 생각은 들었습니다.

하지만 이번 미션에서 제가 가장 헷갈렸던 지점은 패턴을 먼저 떠올리고 거기에 맞춰 설계해야 하는가 아니면
책임과 협력을 먼저 정리하고, 나중에 보니 패턴처럼 설명되는가였습니다.

처음 장기 미션을 봤을 때는 Board를 중재자로 놓고, 기물별 이동 규칙은 전략으로 두는 식으로 생각해볼 수 있지 않을까 고민했습니다.
기물마다 이동 전략이 다르니, 전략 패턴을 활용할 수 있겠다라는 생각도 들었습니다.

저는 아직 어떤 상황에서 어떤 패턴을 적용해야 하는지 감이 잘 잡히지 않습니다.
그래서 제가 패턴을 출발점으로 삼아야 하는지, 아니면 책임 분리와 협력을 먼저 고민한 뒤 결과적으로 패턴처럼 보이면 되는지를 알고 싶습니다.

4. 확장을 어느 범위까지 상상해야 할지 잘 모르겠습니다.

구현을 하다 보면 자연스럽게 여러 확장 시나리오를 상상하게 되어 혼란스럽습니다.
예를 들어 보드의 크기가 달라질 수도 있고, 새로운 기물이 추가될 수도 있고, 기존 말의 이동 규칙이 변형될 수도 있다고 생각했습니다.

이런 가능성을 떠올리기 시작하면 구조를 더 일반화하고 싶어지는데,
동시에 지금 시점에서 그 상상에 너무 많이 대응하려고 하면 오히려 코드가 과하게 추상화되고 복잡해질 수 있다고 느꼈습니다.

저는 아직 지금 필요한 변화와 언젠가 있을지도 모르는 변화를 어디에서 구분해야 하는지 잘 모르겠습니다.
확장 가능성을 고려하는 태도는 필요하다고 생각하지만, 그 범위를 넓게 잡을수록 현재 코드의 이해 비용이 커질 수 있다는 점도 함께 느꼈습니다.
그래서 이 부분에서는 제가 확장을 너무 적게 본 것인지, 아니면 반대로 아직 오지 않은 요구사항까지 상상하며 흔들리고 있는 것인지도 함께 봐주시면 좋겠습니다.

- Piece 구현 - PieceType 구현 - Board 생성 구현

- 초기 포진에 대한 Enum 정의 - Enum을 받아서, 초기화하는 팩토리 추가 - Board는 팩토리에서 생성될 수 있도록 구조 변경

- 원점을 좌하단으로 수정 - 누락된 포 초기화 로직 추가

- KING -> GENERAL - ROOK -> CHARIOT - ADVISOR -> GUARD - PAWN -> SOLDIER

- 인터페이스 메서드로 getPathPositions, canMove를 가짐 - 각각의 기물 구현 클래스 추가 - BoardFactory 변경 - 테스트 코드 변경

- 방향에 대한 Direction 구현 - 졸 움직임 이동 경로 구현 - 사 움직임 이동 경로 구현 - 궁 움직임 이동 경로 구현 - 테스트 패키지 위치 수정

- 마에 대한 이동 경로 구현

- 상에 대한 이동 경로 구현 - Horse 공백 추가

- 차에 대한 이동 경로 구현

- 포에 대한 이동 경로 구현

- 초는 아래에 한은 위에 생성 - 졸/병 움직임을 다른 방향으로 작성

- Path 클래스 작성 - Board에 getPath() 작성

- Piece를 인터페이스에서 record로 변경 - Piece에서 MoveStrategy를 주입받도록 변경

- canMove에서 움직일 수 없는 경우 예외 발생 - 포에 대한 테스트 추가 - 최종 목적지에 대해 같은 진영인지 다른 진영인지는 보드가 판단

- 마에 대한 기물의 움직임 유효성 확인 - 상에 대한 기물의 움직임 유효성 확인 - 포 에러 메시지 수정 - 움직이는 곳이 기물이 없는 경우에 대해 에러 확인

- 간단한 형태로, 움직임만 확인할 수 있도록 뷰 및 컨트롤러 구현 - 현재 좌표, 이동 좌표로 확인만 할 수 있도록 확인

verus-j

안녕하세요 바니~ 리뷰어 베루스입니다.
이전에 저에게 공유주신대로 피드백 반영과 함께 구조 맘껏 바꾸셔도 됩니다.
피드백은 테스트 코드 위주로 남겨드렸는데, 이미 테스트 케이스가 부족하다는 걸 알고 계셔서 작성하기 편하시게 부족한 케이스 남겨드렸습니다. 구조를 맘껏 바꾸실 때 추천드리는 방향은 부족한 테스트 케이스를 먼저 작성하고 테스트 기반으로 리팩터링을 통해 원하는 구조로 개선하는걸 추천드립니다.

다음 리뷰 요청에는 프로덕션 코드 위주로 피드백 남겨드리겠습니다. 질문의 답변도 그 때 남겨드릴게요~

verus-j · 2026-03-30T03:54:33Z

src/main/java/domain/board/Board.java

+    public void move(Position from, Position to) {
+        Piece fromPiece = pieces.get(from);
+        Piece toPiece = pieces.get(to);
+        List<Position> pathPositions = fromPiece.getPathPositions(from, to);
+        List<Path> path = getPath(pathPositions);
+        fromPiece.canMove(path, toPiece);
+
+        if (toPiece != null && fromPiece.isSameTeam(toPiece)) {
+            throw new IllegalStateException("같은 팀의 기물을 잡을 수 없습니다.");
+        }
+
+        Piece remove = pieces.remove(from);
+        pieces.put(to, remove);
+    }


move와 연관된 테스트 케이스가 없습니다~

verus-j · 2026-03-30T03:56:06Z

src/main/java/domain/board/Board.java

+    public List<Path> getPath(List<Position> positions) {
+        List<Path> paths = new ArrayList<>();
+        for (Position position : positions) {
+            if (pieces.containsKey(position)) {


pieces.containsKey(position)이 false인 테스트 케이스가 없는데, 느낌이 positions는 항상 peices에 속한 리스트를 받기 때문일 것 같네요. false인 상황이 실제 프로덕션에서 발생할 수 있을지 검토해주시면 좋을 것 같아요~

verus-j · 2026-03-30T03:56:51Z

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

+    }
+
+    private void validateRange(int x, int y) {
+        if (x < MIN_RANGE || x > MAX_WIDTH_RANGE) {


x < MIN_RANGE 가 true인 테스트 케이스가 없는 것 같습니다~

verus-j · 2026-03-30T03:57:14Z

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

+            throw new IllegalArgumentException("좌표 값이 올바르지 않습니다.");
+        }
+
+        if (y < MIN_RANGE || y > MIN_HEIGHT_RANGE) {


y < MIN_RANGE가 true인 테스트 케이스가 없습니다~

verus-j · 2026-03-30T03:57:38Z

src/main/java/domain/piece/CannonStrategy.java

+        if (!((dx == 0 && dy != 0) || (dx != 0 && dy == 0))) {
+            throw new IllegalArgumentException("포를 해당 위치로 옮길 수 없습니다.");
+        }


포를 이동시킬 수 없는 테스트 케이스가 없습니다~

verus-j · 2026-03-30T03:58:59Z

src/main/java/domain/piece/ChariotStrategy.java

+    @Override
+    public void canMove(List<Path> paths, Piece to) {
+        if (!paths.isEmpty()) {
+            throw new IllegalArgumentException("이동 경로에 기물이 존재하면 이동할 수 없습니다.");
+        }
+    }


차의 canMove와 연관된 테스트 케이스가 없습니다~
이외에도 ChoSoldier, Elephant, General, Guard, HanSoldier, Horse의 canMove와 연관된 테스트 케이스가 없습니다~

verus-j · 2026-03-30T04:07:37Z

src/test/java/domain/piece/CannonStrategyTest.java

+    @Test
+    void 포는_기물이_사이에_하나의_기물이_있으면_정상적으로_움직일_수_있다() {
+        List<Path> paths = List.of(new Path(new Position(3, 0), new Piece(PieceType.HORSE, Team.HAN, new HorseStrategy())));
+
+        assertDoesNotThrow(() -> piece.canMove(paths, new Piece(PieceType.HORSE, Team.HAN, new HorseStrategy())));
+    }


테스트 코드만 살펴봐서는 포의 시작점과 끝점을 이해하기 어렵네요 ㅠㅠ
(3, 0)에 말이 있다는건 알겠지만, canMove(paths, new Piece(HORSE))에서 시작점, 도착점을 알기 어렵고 갑자기 HORSE 기물은 왜 받아야하는지 파악이 어렵네요. 구조 개선하실 때 어떻게 개선할 수 있을지 같이 고민해보면 좋을 것 같아요~

verus-j · 2026-03-30T04:09:08Z

src/test/java/domain/piece/ElephantTest.java

+
+
+    @Test
+    void 마는_위로_두칸_왼쪽으로_세칸_움직일_수_있는_경로가_있다() {


Elephant 테스트인데 네이밍은 마와 연관된 테스트처럼 지어졌네요. 테스트 명 수정하면 좋을 것 같아요~

verus-j · 2026-03-30T04:10:05Z

src/test/java/domain/piece/GuardTest.java

+    }
+
+    @Test
+    void 졸은_우로_한칸_움직일_수_있는_경로가_있다() {


여기도 사와 연관된 테스트인데 졸로 표현되어 있습니다~

verus-j · 2026-03-30T04:11:34Z

src/test/java/domain/piece/SoldierChoTest.java

+
+import static org.assertj.core.api.Assertions.assertThat;
+
+class SoldierChoTest {


초, 한의 병사 모두 후진이 불가능한 테스트 케이스가 없네요~

frombunny · 2026-04-02T17:03:05Z

안녕하세요, 베루스! 리뷰 요청이 늦어진 점 죄송합니다..🥲
구조를 바꾸고 개선하는 과정에서 고민이 많아지다 보니 늦어졌습니다.

지금 돌아보면 더 늦게 낸다고 해서 코드가 크게 좋아지지는 않았을 것 같은데, 필요 이상으로 오래 붙잡고 있었던 것 같습니다.
앞으로 리뷰 요청은 하루를 넘기지 않도록 하겠습니다..!

테스트코드 관련해서 피드백을 주신 부분들을 보면서, 조금 더 테스트코드를 꼼꼼히 짜도록 노력해보았습니다!
바쁘신 와중에도 리뷰해주셔서 정말 감사합니다🙇‍♂️

전략 설계에 대한 고민

나름 상속보다는 조합을 활용하는 방향으로 구조를 풀어보려고 했습니다.
하지만 전략을 두 가지로 나누어 주입하려고 하니 인스턴스 변수가 많아지고, 반대로 모든 전략을 각각 구현하려고 하니 전략 패턴을 충분히 활용하지 못하고 있다는 느낌이 들었습니다.

또, 유사하지만 조금씩 다른 로직들을 어떻게 구조적으로 풀어내야 할지 고민이 많았습니다. 공통적인 부분들을 모아 잘 조립해보고 싶었는데, 괜히 구조의 복잡도만 높이는 것 같다는 생각도 들었습니다. 추상 클래스, 추상 클래스와 전략 패턴의 조합, 현재 구조 유지 등 여러 방안을 시도해봤지만, 결국 방향을 명확히 잡지 못한 채 계속 맴돌기만 했던 것 같습니다.

상속 대신 조합을 선택하려고 했지만, 그 선택을 실제 코드 구조로 자연스럽게 풀어내는 데에는 아직 부족함이 있었다고 느꼈습니다.

레벨 1이 끝나가는 시점인데도 스스로의 설계 기준을 명확히 세우지 못한 것 같아 아쉬움과 답답함이 남습니다.

Offset 도입에 대한 고민

사이클 1에서 Offset이라는 개념을 도입할지에 대해 페어와 깊이 있는 논의를 했습니다. 저는 아래와 같은 이ㅠ로 현재 단계에서는 Offset을 도입하지 않는 것이 더 적합하다고 판단했습니다.

1. 불필요한 변환과 좌표 표현의 일관성
Offset을 도입하면 Board와 Piece 사이에서
Position(좌표) → Offset(상대 거리) → Position(좌표)으로 변환이 반복됩니다.

특히 경로 검증 과정에서 결국 보드 위의 기물을 확인하려면 다시 Position으로 돌아와야 하므로, 하나의 이동 흐름 안에서 좌표 표현이 혼용됩니다. 이로 인해 모델의 일관성이 깨지고, 도메인을 이해하는 데 오히려 부담이 된다고 느꼈습니다.

2. 장기 궁성 로직의 특수성
사이클 1에서는 궁성 로직을 구현하지 않지만, 장기에서 대각선 이동은 궁성이라는 특정 영역 안에서만 허용됩니다.

Offset만으로는 “이 이동이 궁성 내부에서 발생한 것인지”를 판단하기 어렵다고 생각했습니다.
결국 “현재 위치(Position)가 궁성 내부인가?”를 기준으로 판단해야 하므로, 도메인의 중심은 Position이 되어야 한다고 보았습니다.

이 과정에서 상대적 거리 개념을 추가로 도입하는 것은 오히려 규칙을 설명하는 데 방해가 될 수 있다고 느꼈습니다.

3. 설계의 복잡성 대비 효용
현재는 Position과 Direction만으로도 이동 방향과 경로를 충분히 명확하게 표현할 수 있습니다.

향후 벡터 연산이 매우 복잡해지는 상황이 아니라면, Offset을 도입하는 것보다 현재 구조를 유지하는 것이 가독성과 유지보수 측면에서 더 유리하다고 판단했습니다.

Offset은 좌표 간 차이를 표현하는 데에는 적합하지만, 장기 도메인의 핵심 개념인 “경로”, “궁성”, “위치 제약”을 직접적으로 드러내기에는 다소 거리가 있다고 느꼈습니다.
이에 대해 베루스는 어떻게 생각하시는지 궁금합니다 👀

다양한 설계 선택지 속에서 기준을 잡는 것에 대한 고민

크루들과 이야기를 나누다 보면 다양한 설계 아이디어가 나오고,
각각의 방식이 모두 나름의 타당한 근거를 가지고 있어서 “이게 더 좋은가?”, “저게 더 맞는가?”를 계속 비교하게 되는 상황이 많았습니다.

문제는 이 과정에서 장단점을 계속 따져보다 보니, 오히려 스스로의 판단 기준이 흐려지고 결정이 늦어지는 경험을 하게 되었습니다.
특히 이번 미션에서는 여러 의견을 듣는 것이 도움이 되기도 했지만, 동시에 선택지를 과도하게 늘려서 더 혼란스러워지는 순간이 더 많았습니다.

그래서 이번 미션에서는 유난히 앞으로 나아가지 못하고, 정체된 느낌을 받았던 것 같습니다.
스스로 기준을 세우는 능력이 아직 부족한 것 같은데, 스스로의 기준은 어떻게 세우는 게 좋을까요?

이런 경우 베루스는 보통 어떤 기준으로 사고를 정리하고 다음 선택을 내리시는지 궁금합니다..!

verus-j

안녕하세요 바니~
피드백 반영과 함께 구조 변경하시느라 고생하셨습니다. 조금 아쉬운 점은 구조는 많이 개선하셨지만 테스트 코드는 여전히 많이 부족했습니다 ㅠㅠ 커밋 내역을 보니 구조 개선 후 테스트 코드를 작성하셨는데, 만약에 아쉬운 구조대로 테스트 코드를 먼저 작성하고 리팩터링을 진행한다면 어땠을지 상상해보는 것도 좋을 것 같아요.

남겨주신 질문이 조금 길어서 슬랙에 따로 내일 답변드리겠습니다.

verus-j · 2026-04-03T15:07:04Z

src/main/java/domain/piece/strategy/CannonMoveStrategy.java

+
+import java.util.List;
+
+public class CannonMoveStrategy implements MoveStrategy {


리팩터링하면서 테스트 코드가 없어진 것 같네요 ㅠㅠ

파일이 존재해서 확인해봤더니, CannonMoveStrategy에서 잘못된 기물의 테스트를 하고 있어서 그랬던 거였군요...ㅜㅜ 미리 꼼꼼히 확인했어야 하는데 정말 죄송합니다...😭

verus-j · 2026-04-03T15:09:13Z

src/main/java/domain/board/Board.java

+
+        departurePiece.validateBlockingPiece(path, destination);
+
+        if (isExistPieceAt(destination)) {


false인 테스트 케이스가 없는걸보니 빈 공간으로 기물이 이동하는 경우에 대한 테스트 케이스가 없는 것 같습니다~

verus-j · 2026-04-03T15:09:52Z

src/main/java/domain/piece/strategy/ElephantMoveStrategy.java

+        if ((Math.abs(deltaX) == 3)) {
+            return Direction.decideDirection(deltaX, 0);
+        }


조건문 안에 들어오는 테스트 케이스가 없습니다~

verus-j · 2026-04-03T15:10:54Z

src/main/java/domain/piece/strategy/ElephantMoveStrategy.java

+        if (hasBlockingPiece) {
+            throw new IllegalArgumentException("이동 경로에 있는 다른 기물을 뛰어넘을 수 없습니다.");
+        }


hasBlockingPiece가 false인 케이스가 없네요. 정상적인 케이스에 대한 테스트가 없는 것 같아요.

verus-j · 2026-04-03T15:11:23Z

src/main/java/domain/piece/strategy/ElephantMoveStrategy.java

+        int absoluteX = Math.abs(deltaX);
+        int absoluteY = Math.abs(deltaY);
+
+        return (absoluteX == 2 && absoluteY == 3) || (absoluteX == 3 && absoluteY == 2);


다양한 방향으로 이동하는 케이스에 대해 테스트하면 좋을 것 같아요~

verus-j · 2026-04-03T15:22:58Z

src/test/java/domain/piece/strategy/CannonMoveStrategyTest.java

+import static org.assertj.core.api.Assertions.assertThatThrownBy;
+
+class CannonMoveStrategyTest {
+    private final MoveStrategy chariotMoveStrategy = new ChariotMoveStrategy();


잘못된 MoveStrategy를 테스트하는 것 같습니다.

이 부분 꼼꼼히 확인했어야 하는데 정말정말 죄송합니다 ㅜㅜ..
포 테스트가 통과하지 않는 부분이 있었는데, 이로 인해 발견하지 못했더라구요🥲
이번을 계기로 앞으로 테스트코드는 신경써서 꼼꼼히 작성하도록 하겠습니다..

verus-j · 2026-04-03T15:24:08Z

src/main/java/domain/piece/strategy/CannonMoveStrategy.java

+    @Override
+    public void validateBlockingPiece(List<PathInfo> pathInfos, Position destination) {
+        if (pathInfos.stream().anyMatch(pathInfo -> pathInfo.isPieceType(PieceType.CANNON))) {
+            throw new IllegalArgumentException("포는 포를 넘거나 잡을 수 없습니다.");
+        }
+    }


포의 조건 중에 넘을 수 있는 기물 갯수제한이 빠진 것 같습니다. 확인부탁드려요~

포가 포를 넘거나 잡는 제약에만 집중하여 포가 넘을 수 있는 기물 갯수 제약을 놓쳤습니다😭
이 부분도 제가 꼼꼼히 확인하지 못했습니다 죄송합니다 ㅠㅠ

verus-j · 2026-04-03T15:26:39Z

src/main/java/domain/piece/strategy/ElephantMoveStrategy.java

+
+public class ElephantMoveStrategy implements MoveStrategy {
+    @Override
+    public List<Position> getPath(Position departure, Position destination) {


메서드가 너무 긴 것 같습니다. 적절히 메서드를 추출해 추상화 수준을 높여보면 좋을 것 같아요~

verus-j · 2026-04-03T15:27:29Z

src/main/java/domain/piece/strategy/SoldierMoveStrategy.java

+    }
+
+    @Override
+    public List<Position> getPath(Position departure, Position destination) {


전반적으로 MoveStrategy의 하위 클래스들의 getPath 구현 로직이 기네요. 메서드 추출로 추상화 수준을 높여보면 좋을 것 같아요~

verus-j · 2026-04-03T15:28:44Z

src/main/java/domain/path/PathGenerator.java

+import java.util.ArrayList;
+import java.util.List;
+
+public class PathGenerator {


PathGenerator로 Path를 생성하기 위해 정적 메서드를 제공해야하는지 고민해보면 좋을 것 같습니다. 현재 구조에서 다른 객체에게 책임을 맡길 수 있을 것 같아요~

frombunny and others added 25 commits March 24, 2026 19:59

docs(README): 보드 초기화 요구사항 정리

9c01c02

feat(Position): 좌표 기능 구현

59fcc57

feat(InitBoard): 장기판 생성 구현

327b8af

- Piece 구현 - PieceType 구현 - Board 생성 구현

feat(InitBoard): 장기판 초기화 방법들에 대한 구현

1be6794

- 초기 포진에 대한 Enum 정의 - Enum을 받아서, 초기화하는 팩토리 추가 - Board는 팩토리에서 생성될 수 있도록 구조 변경

fix(InitBoard): 장기판 원점 좌표 수정

02d30c2

- 원점을 좌하단으로 수정 - 누락된 포 초기화 로직 추가

refactor(InitBoard): 기물들의 클래스명 변경

bcff3b2

- KING -> GENERAL - ROOK -> CHARIOT - ADVISOR -> GUARD - PAWN -> SOLDIER

refactor(InitBoard): Piece 인터페이스 도입

07bc1de

- 인터페이스 메서드로 getPathPositions, canMove를 가짐 - 각각의 기물 구현 클래스 추가 - BoardFactory 변경 - 테스트 코드 변경

feat(PieceMove): 졸, 궁, 사에 대한 이동 경로 구현

f37bd67

- 방향에 대한 Direction 구현 - 졸 움직임 이동 경로 구현 - 사 움직임 이동 경로 구현 - 궁 움직임 이동 경로 구현 - 테스트 패키지 위치 수정

feat(PieceMove): 마에 대한 이동 경로 구현

2fdf8a0

- 마에 대한 이동 경로 구현

feat(PieceMove): 상에 대한 이동 경로 구현

44b13c5

- 상에 대한 이동 경로 구현 - Horse 공백 추가

feat(PieceMove): 차에 대한 이동 경로 구현

f7c7a9d

- 차에 대한 이동 경로 구현

feat(PieceMove): 포에 대한 이동 경로 구현

e6d3cfb

- 포에 대한 이동 경로 구현

feat(InitBoard): 초/한 진영에 대한 기물 정보 추가

1a30917

- 초는 아래에 한은 위에 생성 - 졸/병 움직임을 다른 방향으로 작성

feat(PieceMove): 기물의 이동 경로에 대한 클래스 추가

1c49c85

- Path 클래스 작성 - Board에 getPath() 작성

refactor(Piece): Piece를 record로 변경

4a8fb06

- Piece를 인터페이스에서 record로 변경 - Piece에서 MoveStrategy를 주입받도록 변경

feat(Piece): 같은 팀인지 확인하는 메서드 작성

5fbb7ac

feat(PieceMove): canMove 구현

ea97418

feat(PieceMove): 기물이 움직일 수 있는지에 대한 메서드 추가

5109408

- canMove에서 움직일 수 없는 경우 예외 발생 - 포에 대한 테스트 추가 - 최종 목적지에 대해 같은 진영인지 다른 진영인지는 보드가 판단

docs(README): 기물의 이동 기능사항 추가

5fcb757

style: 코드 포맷 수정, 필요없는 주석 제거

4723ed7

fix(PieceMove): 버그 수정

e595d08

- 마에 대한 기물의 움직임 유효성 확인 - 상에 대한 기물의 움직임 유효성 확인 - 포 에러 메시지 수정 - 움직이는 곳이 기물이 없는 경우에 대해 에러 확인

feat(view): 장기에 대해 확인할 수 있는 뷰, 컨트롤러 추가

1d2e22c

- 간단한 형태로, 움직임만 확인할 수 있도록 뷰 및 컨트롤러 구현 - 현재 좌표, 이동 좌표로 확인만 할 수 있도록 확인

docs(README): 토론에서 작성한 규칙, 미션 중 기록 작성

83f9817

style: 와일드 카드 제거

ec81880

test(PieceMove): 상에 대한 테스트 오류 수정

9e98fcc

verus-j requested changes Mar 30, 2026

View reviewed changes

frombunny added 4 commits March 31, 2026 15:06

feat(Position): 좌표 생성 및 검증 로직 구현

5a2beb6

feat(Board): 보드 초기화 구현

563868b

refactor(Position): 매직넘버 상수 처리

779dd7e

test(Board): 보드 초기화 테스트 리팩토링

0fc9a24

frombunny added 3 commits April 1, 2026 15:23

feat(Position): 좌표 차이 계산 로직 구현

11e40a6

feat(Direction): 방향 판정 로직 구현

8f6a7db

feat(MoveStrategy): 차 이동 로직 구현

b36fa6e

frombunny force-pushed the step1 branch from e9c3c81 to b36fa6e Compare April 2, 2026 05:58

frombunny added 21 commits April 2, 2026 15:05

refactor: 패키지 이동

4368531

refactor: 코드 포맷팅 수정

0637768

feat(MoveStrategy): 궁/사 이동 로직 구현

d9c59fc

feat(MoveStrategy): 포 이동 로직 구현

4087a05

feat(MoveStrategy): 졸/병 이동 로직 구현

6d434a0

refactor: 사용되지 않는 선언 제거

780e132

feat(MoveStrategy): 마 이동 전략 구현

877247c

feat(MoveStrategy): 마 이동 전략 구현

a311337

feat(MoveStrategy): 상 이동 전략 구현

99610dc

feat(MoveStrategy): 상 이동 전략 구현

aae6b44

test(PathInfo): PathInfo 누락 테스트 추가

561cda7

test(Position): Position 누락 테스트 추가

3549d35

test(Piece): Piece 누락 테스트 추가

74fc93a

test(Board): Board 누락 테스트 추가

43e9627

test(PathGenerator): PathGenerator 누락 테스트 추가

906399c

fix(Board): 장기판 테스트 오류 수정

a17bc6b

feat(view): 입출력 구현

2a4b1e5

feat(Controller): 컨트롤러 구현

8a3671f

feat(Game): 승패 판정 구현

700e8ea

refactor: 사용되지 않는 선언 제거

4a6f08f

view: 상차림 선택 구현

809c2ae

test(MoveStrategy): 마,상 기물 이동 테스트 케이스 추가

033710a

verus-j requested changes Apr 3, 2026

View reviewed changes

frombunny added 2 commits April 4, 2026 01:33

fix(MoveStrategy): 포 이동 시 경로에 기물이 여러개 있으면 이동할 수 없도록 수정

9701db2

test(MoveStrategy): 포 이동 경로에 기물이 여러개 있을 경우의 테스트 추가

4e68aac



		@Test
		void 마는_위로_두칸_왼쪽으로_세칸_움직일_수_있는_경로가_있다() {


		import static org.assertj.core.api.Assertions.assertThat;

		class SoldierChoTest {


		import java.util.List;

		public class CannonMoveStrategy implements MoveStrategy {


		departurePiece.validateBlockingPiece(path, destination);

		if (isExistPieceAt(destination)) {

Conversation

frombunny commented Mar 29, 2026

체크 리스트

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

1. Board와 Piece의 책임을 어떻게 나누어야 하는지가 가장 큰 고민이었습니다.

2. 이동 검증 흐름을 Board가 조정하는 현재 구조가 자연스러운지 궁금합니다.

3. 설계 과정에서 디자인 패턴을 어떻게 바라봐야 하는지가 여전히 어렵습니다.

4. 확장을 어느 범위까지 상상해야 할지 잘 모르겠습니다.

Uh oh!

verus-j 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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

전략 설계에 대한 고민

Offset 도입에 대한 고민

다양한 설계 선택지 속에서 기준을 잡는 것에 대한 고민

Uh oh!

verus-j left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

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

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

frombunny commented Apr 2, 2026 •

edited

Loading

frombunny Apr 3, 2026 •

edited

Loading