# 1주차 2조 피어세션 리포트

## 개인별 브랜치 링크

* 송지 : https://github.com/SongJiyeon/chess-app/tree/feature-step1
* Beck : https://github.com/SangHwi-Back/chess-app/tree/feature-BoardPawnTest
* Austin: https://github.com/ehgud0670/chess-app
* Sello: https://github.com/sally4405/chess-app/tree/step1
* 이연 : https://github.com/lxxyeon/chess-app/tree/feature-step1
* 지연 : https://github.com/jiyeonlab/chess-app/tree/board-pawn

---

## 개인별 설계 의도 소개

### 송지

1. 말 종류의 확장성을 고려해서 Type을 가능한 세분화함.
2. 테스트를 위해서 가급적 함수형으로 작성함.
3. 가급적 Board가 모든 비지니스 로직을 담당하게 해서 로직 분산을 막았음.

### Beck

1. 체스판을 뜻하는 Board 는 모든 위치와 위치에 있는 Piece 를 갖는다.
2. Piece 는 pawn, knight 등을 의미하는 프로토콜이고, 자신의 색/이동방향/색을 갖는다.
3. 이외에 체스판의 위치값, 체스말 종류, 체스말 색, 이동방향은 모두 Enum 을 사용. 경계조건을 넘지 않도록 하기 위한 의도를 가짐.

### Austin

1. Board 가 입력값을 받으면 InputManager 가 입력값을 파싱하도록 했고(파싱이 안됨 오류를 뱉음),
2. 받은 입력값을 Board 차원에서 검증하고 동작하도록 구현했습니다.
3. 프로토콜을 먼저 선언해 외부에 노출되어야 할 메서드가 구분지으며 구현했습니다.
4. 조건문의 댑스가 깊어지지 않게 구현하였습니다.

### Sello
* 각 객체가 최대한 본인의 역할만 하도록 구현
* 확장 가능성을 고려해 구현

### 안이연
* Board, Pawn 기능별 테스트 작성을 고려하여 메소드 작성
* 공통 사용 및 변하지 않는 변수 고려하여 선언

### 지연
1. ChessBoard에는 Position, Piece로 구성된 Square를 관리하고, 게임 진행과 관련된 역할을 넣음
2. Position과 Piece 타입을 선언하고, 생성과 이동에 관한 판단을 해당 타입 진행

---

## 개인별 구현 방식 설명

### 송지

1. Piece 타입은 PieceType, ColorType을 갖는다.
2.

### Beck

1. Board 클래스에서 체스판과 체스말을 모두 초기화.
2. Board 에 이동 혹은 점수계산하는 로직을 모두 추가(리팩토링 필요)
3. Board 에 모든 검증을 구현(리팩토링 필요)
4. Piece 는 자신의 색과 종류를 갖도록 함. 초기화 함수에서 일부 상태값을 직접 정의해주어야 함(리팩토링 필요)

### Austin

### Sello
* 이동을 위한 로직을 객체별로 나눠서 구현
* `PieceType` actionList: 각 타입별 피스가 보드에 상관 없이 이동할 수 있는 액션 배열
* `Piece` getMovablePositions: 다른 피스에 상관 없이, 피스의 현재 위치와 피스의 타입에 따라 이동할 수 있는 위치 배열
* `Board` canMovePiece: 다른 피스의 위치까지 고려하여 이동할 수 있는지 반환
* PieceType을 enum으로 구현해 case로 pawn과 case별 속성들을 추가

### 안이연
*
### 지연
1. ChessBoard는 Position과 Piece를 가지는 Square 타입을 갖는다
2. Position에는 Rank와 File를 가지고 있고, 초기화가 가능한 위치인지를 반환한다
3. Piece는 컬러, 최대 생성 개수 등을 가지고 있고, Position을 받아 이동 가능한지를 반환한다
---

## 질의응답 항목과 의견들

### 송지

### Beck

* 대각선 이동에 대한 논의
* 색을 이름 그대로 사용하는 것에 대한 논의

### Austin

* Color를 enum으로 썼는데 다른 방법도 있을까
* Enum 의 rawValue 를 Enum의 내부에서만 쓰는게 좋다고 알고 있는데 차주까지 이유를 알아오려고 합니다.
* 객체의 이름을 먼저 정하기보다는 요구사항을 먼저 어떤게 있는지 찬찬히 살펴보는 것이 중요하다.
* 네이밍은 너무 길면 읽기 어렵고 너무 간결하면 기억하기 어렵다.

### Sello

* 나이트 piece가 추가된다면, 다른 말을 뛰어넘을 수도 있는데 지금의 Action 객체로 표현 가능한가?
-> 정상 이동과 말을 뛰어넘는 이동 두 가지를 모두 배열에 추가하고, 말을 뛰어넘는 이동 액션에는 option 추가 고려할 듯

### 안이연
* 테스트 케이스 케이스 항목 선언 방식 논의

### 지연