1주차 그룹 피어세션 리포트

[godrm]

여기에 그룹별로 리포트를 제출해주세요.
다음과 같은 내용을 포함하며 형식은 자유롭게 작성하세요

• 개인별 브랜치 링크
• 개인별 설계 의도 소개
• 개인별 구현 방식 설명
• 질의응답 항목과 의견들

[zzisun]

1: 썸머, 스티븐, 민이, Pilvi

개인별 브랜치 링크

썸머: https://github.com/code-squad/swift-chess-app/tree/summer
스티븐: https://github.com/sunghyun-k/swift-chess-app
민이: https://github.com/mini0212/swift-chess-app/tree/feature/week1-chess-game
Pilvi: https://github.com/Jae-eun/swift-chess-app/tree/pilvi

개인별 설계 의도 & 구현 방식 소개

썸머:
보드에서 배치, 이동 관리
매치에서 보드 초기화 후 게임 실행
플레이어블에서 기물이 움직일 수 있는지 확인
Mock 플레이어를 생성하여 이동 로직 테스트
목 플레이어를 계속 생성해야 하는 문제가 있을 수 있음.

스티븐:
Position: Int의 구현. -> Int라는 타입이 호환성이 좋음(배열 index, 콘솔 입출력에서 손쉽게 사용가능.)
ChessStringRepresent: Position을 Int로 구현하여, 체스판이 꼭 8X8이 아닐수 있음을 예상. Int값으로 비교.
ChessPiece: protocol을 사용하여 말의 움직임을 각 구체타입이 관리하는 것을 생각. 몇 기물은 서로를 알아야하는 이슈가 있어 다형성이 필요없다 생각해 열거형 사용.
ChessBoard: 이동하는 경우 ChessPiece가 이동 가능한 포지션을 다 가져오는 함수가 있음. 거기서 각 enum을 비교하여 이동가능한 상황인지 확인.
standardChessBoard: 체스보드가 8x8이 아닐수 있어서 만듦.
ChessGame: 사용자 플레이만 관여.
ChessGameTests: 추후 분리 예정.
체스의 움직임 확인.
체스보드 생성했을 때 함수가 제대로 작동하는지.
보드상 움직임이 실패하는 경우
점수가 제대로 표현 되는지.
같은 사람이 연속으로 이동하는지?
이동시킬 기물이 없을 경우 를 테스트

민이: 체스게임, 폰, 보드, 포지션 크게 4 파일로 만듦.
폰은 색상값만 가지고 있음.
보드에서는 보드를 보여주는 것을 함.
File과 Rank 타입을 만들어서, case의 allCount로 보드를 생성하도록 함.
체스게임 안의 move() 함수는 보드에서 움직일 수 있는 것을 체크해서 동작함.
같은 알파벳으로만 움직일 수 있는 기능에 대해서 아직 구현하지 못했음.

Pilvi:
ChessPieces: Pawn 이외에 체스말 종류가 있기에 ChessType를 선언. ChessPiecesColor의 toggle은 흑과백의 순서를 변경함. getMovablePositions함수를 통해 자신이 이동할 수 있는 위치 제공함.
ChessBoard: rank,file을 Int타입으로 선언해 확장성있는 보드크기. 초기화 시, 크기를 입력받음.
BoardPosition: "A1" 입력을 [String: Int] -> ["A":1]로 바꿔줌
ChessGame: 현재 차례인 체스말의 컬러를 가지고 있음. 보드 초기화, 이동할 위치입력, 차례를 번갈아 게임을 진행함.

질의응답 항목과 의견들

썸머:
Playable 프로토콜의 역할: 팀 컬러에 따라 어느 방향으로 움직일 수 있는지 기능 제공
moveCallCount의 의미: 함수가 얼마나 호출되었는지 확인하기 위함

Pilvi:
Protocol을 만든 의도: Protocol을 만들고 mock객체를 만들어왔다.

[inddoni]

6: delma, pete, BeePeach, Lychee

1주차

220929,

브랜치 링크

• BeePeach
• Lychee
• Delma

설계 의도

Lychee

• 객체: Pawn, Board
• PawnPosition, File, Rank 도 타입으로 정의
• Board -> 2차원 배열 empty, black, white [[BoardState]]
• 테스트 코드 : 요구사항에 나온 동작들 단위로

Beepeach

• 구두로 설명

delma

• Piece - File, Rank
• Location
• 각 객체의 역할이 확장 가능한 부분(Piece)과 한정된 부분(File, Rank)으로 나눠서 구현하려고 하였음

개인별 구현 방식 설명

Lychee

• PR 보며 구두로 설명

Beepeach

• PR 보며 구두로 설명

delma

• PR 보며 구두로 설명

[dochoi-bot]

1주차 5그룹 그룹 피어세션 리포트

요구사항을 해결하기 위한 구조

Lin

상위 타입

Board
Piece / Position
Pawn

하위 타입

의 구조로 구성이 되어있습니다.

Board는체스말의 위치(체스판), 체스말의 움직임을 관리합니다.

Piece는 체스말에 대한 정의(프로토콜)이며 색상, 점수, 모양과 움직일 수 있는 위치를 알려줄 수 있습니다.
구현체로는 Pawn이 이있습니다.

Position은 file, rank로 이루어져 있고 체스말의 위치를 나타냅니다.

데미안

Freddy

체스판 및 체스말을 관리하는 Board와 확과 백을 나타내는 Player, 8x8 체스판 좌표 나타내는 Position, 체스말을 표현하는 프로토콜인 Piece와 이를 채택한 체스말 Pawn으로 구성되어 있습니다.

---

설계한 구조를 구현하기 위해 신경썼던 부분

Lin

• 각각의 역할을 나누는 것에 고민을 하였습니다.
  • Board 내부에서 position과 piece를 어떻게 적절하게 호출하고 관리하는 것
  • 타입에 대한 기준

데미안

• 추후 코드 변화를 위해 최대한 간단하게 구현하려 했습니다. 다만 position의 범위 제한을 board의 책임이라고 생각했는데, postion 자체에 넘기는 방식이 있음을 깨달았습니다

Freddy

Board와 Pawn 사이에 공유되는 값인, 8x8 체스판에서의 좌표를 어떻게 공유할지에 대해서 고민을 많이 했습니다. Board와 Piece(Pawn) 사이에서 이 좌표가 많이 사용되는데 Postion이라는 별도의 객체를 만들고 Position이 failable initializer를 통해서 유효한 좌표인지를 확인하도록 구현하였습니다.

---

궁금했던 사항

Lin

• 테스트를 어디까지 작게 나누고 무엇을 테스트해야하는 지 다른 사람들의 기준이 궁금합니다.

데미안

• 체스 말의 이동 포지션은 체스와 플레이어 두개의 변수에 의존하는데 어떻게 구현하는 게 좋을까요?

Freddy

• 어떻게 테스트를 구성할지? (Unit Test에 대한 공부가 필요합니다..)

---

개인별 브랜치 링크

Lin

https://github.com/Limwin94/swift-chess-app/tree/feature/step-2

데미안

• https://github.com/code-squad/swift-chess-app/tree/ChoiDongKyu96

Freddy

https://github.com/sonfrdy/swift-chess-app/tree/feature-chess1

질의응답 항목과 의견들

• 변화를 너무 예상하고 모든 책임을 잘게 나누면 그에 따른 오버엔지니어링과 코드의 늘어남이 생기고 코드 맥락 파악은 어려워 지는것이 아닌가?

[HEROHJK]

4그룹 1주차

개인별 브랜치

호종
Jake
윤재영
김척척

개인별 설계 의도

• 호종
  • 최대한 세밀하게 분리
  • Command <-> Chess Board에서의 포지션을 변환하는 함수들을 작성하여 Chess Board에서는 Rank, File을 활용
• 윤재영
  • Board와 Piece 프로토콜로 구현에 필요한 사항을 정의
  • Board는 보드판과 기물들의 위치를 관리
  • Piece는 기물의 고유 특성을 관리
• Jake
  • Piece가 Board를 알지 못하도록 Piece와 Board의 의존관계를 정의함
  • Board는 Piece들의 배치와 움직임을 관리
  • Piece는 color, type, image를 책임짐
• 김척척
  • (미완성)

개인별 구현 방식

• 호종
  • ChessBoard는 Unit Protocol을 가진 2차원 배열로 구현
  • Score는 배열에서 합산하여 계산하도록 구현
  • 테스트는 클래스당 함수 하나로 분리하지 못함
  • Chess를 전체적으로 컨트롤하는 부분은 아직 구현하지 않음.
• 윤재영
  • Board 프로토콜을 상속한 ChessBoard 클래스 구현
  • Piece 프로토콜을 상속한 Pawn 클래스 구현
  • 2차원 배열로 보드판과 기물들의 위치정보를 구현
  • 2차원 배열의 index를 통해서 기물 움직임 구현
• Jake
  • Piece는 color, type, image를 갖는다.
  • type별로 점수가 다를 수 있다.
  • 현재 위치에서 갈 수 있는 모든 경우의 수를 추출하는 distances() 함수가 있다. 대각선과 직선은 가장 멀리갈 수 있는 경우를 가정.
  • Board는 board, score, display, move 등의 함수로 게임 플레이와 연관된 기능들을 제공.
  • 행렬을 보기 좋게 정리하다보니 Board[Rank][File] 방식으로 배치했으며, position은 익숙한 (x, y) 좌표로 감지하기 위해 (File, Rank) 방식을 취함.
• 김척척
  • (미완성)

질의 응답 항목과 시간들

• Command 변환 검사
• 모든 상황을 검사했는지?
• 위치를 저장하는 경우가 중복일때는 어떻게 했는가?
• 이동 가능 함수를 두개로 분리한 이유가 있는지?
• 스코어 구현을 어떻게 했는지?
• 테스트 함수 이름을 한글로 한 이유?

[ryan-son]

개인별 브랜치

• Ryan Son
• Mason
• taemin Yun
• seungeon Kim

개인별 구현 방식

Ryan Son

• 요구사항을 읽고 Board, Pawn은 필요하겠다고 판단하여 먼저 정의
• 체스판 초기화 -> 테스트, Board 이동로직/점수 계산 -> 테스트, 사용자 입력 검증 및 파싱 -> 테스트 순으로 구현

사용자 입력 읽기 및 파싱

• CommandReader가 사용자 입력을 받고 CommandParser가 문자열로 된 사용자 입력을 앱 도메인에서 이용하는 모델(MoveCommand) 로 변경합니다.
• MoveCommand는 출발점과 목적지를 가진 모델로, rank와 file값을 정수형으로 가지고 있습니다.

체스판 초기화, 체스말 이동, 점수 계산 및 콘솔 출력 (Board)

• 체스판 타입인 Board는 요구사항대로 체스판을 초기화하는 이니셜라이저와 테스트를 위해 주어진 체스판 상태로 초기화하는 이니셜라이저로 생성자를 구성하였습니다.
• 체스판 위의 체스말을 이동시키는 move(from:to:), 점수를 계산하여 출력하는 currentPoints()와 콘솔에 체스판 현황을 출력하는 display() 메서드를 제공합니다.

체스말

현재는 Pawn이 유일한 체스말 타입입니다. Pawn은 체스말 타입의 요구사항을 명세한 Piece 프로토콜을 준수합니다. Piece 프로토콜은 체스말마다 다르게 구현될 필요가 있는 사항이 아니라면 일부 기본구현을 제공합니다.

Mason

설계 구현 설명

• 요구사항을 꼼꼼히 확인하여 도식화 진행

• 단계를 구분하려면 역할을 나누어야겠다고 생각함.
• 뷰나 출력을 구현하지 않으니 다른 곳에서도 사용할 수 있도록 구성하는 것을 의도
• 입력이 제대로 되었는지, 내부에서 이동 가능한지 검증(해당 위치로 갈 수 있는지)
• Board를 중심으로 로직 처리를 하려고 의도
• Board가 혼자서 처리하는 것이 아니라 역할을 나누어주려 노력함
• Primitive type을 사용하기보다 커스텀 타입을 정의하도록 노력함(Pawn, Piece, Rank)
• 상위에서 하위로 로직을 구성 (Board부터)
• 추상(프로토콜) -> 구체(구현)
• private method 테스트하기 어려우니 RankManager와 같은 하위 타입으로 구분하여 역할을 위임 (제대로 이해한 것이 맞는지?)

받은 피드백

• MockBoard를 사용하면 의도한 동작을 테스트할 수 있을 것이라 피드백 받음
• pawn.color.description -> pawn.description
• Rank, File 타입으로 나누었으니 Position은 필요 없을 수 있다.

taemin Yun

• 합류가 늦어 PR을 하지 못함. 다음에 공유할 예정.

seungeon Kim

Command

사용자의 명령이 유효한지 확인하고, 위치의 이동을 위한 Position 모델을 반환해 줍니다.

Pawn

폰의 색상(Color)과 현재 위치(Position)를 나타내는 멤버 변수를 가집니다.

Position

File / Rank를 멤버변수로 가지고 있으며, 각 멤버 변수는 8x8 사이즈의 chessBoard의 범위를 초과하는 경우를 막기위해 enum 타입으로 정의되어있습니다.

ChessBoard

체스판 위에 올라가는 pawn들의 관리 / 생성 / 삭제 / 이동을 관리해줍니다.

ChessGame

체스 게임의 룰과 진행을 위한 관리를 해줍니다.

Error

상황에 따른 에러메세지와 코드를 관리하기 위한 모델입니다.

설계 구현 설명

• 인터페이스 구현은 안된 상태
• 요구사항을 구현하는 것에 집중함
• ChessBoard, ChessGame으로 구분. 하나로 합치기에는 역할이 너무 클 것으로 예상했었음.
• ChessGame: 게임 룰, 플레이어 관리
• display()는 단순 출력이므로 테스트를 작성하지 않아도 될 것으로 생각했으나 잘못 보여질 수도 있으므로 테스트를 추가하기로 함.
• 게임에서 Pawn을 생성하는 것이 옳을 것 같아 Game에서 체스말 생성을 해줌

받은 피드백

• String을 전달받는 팩토리 메서드를 구성하기보다 이니셜라이저를 정의해서 사용할 것을 피드백 받음
• 이동 로직 find, remove, add 순으로 진행하는데, ...
• black, white pawn 배열을 따로 정의 ->
• 커맨드 생성 시 에러가 발생하면 nil 보다 에러를 반환하는 것이 더 좋지 않을까

---

[RoadtoS7]

깃헙 브랜치 링크

• Ellie: https://github.com/RoadtoS7/swift-chess-app/tree/feature-step1
• Ray: https://github.com/sangjinKIM93/swift-chess-app/tree/feat/step-1
• 쑤: https://github.com/lenaios/swift-chess-app/tree/step-1

개인별 설계 의도 소개

• Ellie: 입력 → 검증 → 처리/계산 → 형식 → 출력 단계로 역할 분리에 신경씀.
• Ray: 작게 쪼갠다는 개념하에 객체를 나눠서 역할을 분담함.
• 쑤: 입출력을 제외하고 핵심 로직만 작성하는데 집중함

질의응답 항목과 의견들

• Ellie: 체스보드의 range를 enum으로 표현하신 것이 인상깊었습니다. 영상에서 배운 것 (ex. 개체 수 테스트)를 적용하신 것이 인상깊었습니다. 대칭적인 코드로 깔끔하게 작성하신 것을 보고 제 코드도 더 대칭적으로 만들기 위해 도전하려 합니다.
• Ray: Pawn에서 이동 로직을 일부 담당한 것. enum을 통해서 Rank, File을 관리한 것이 인상깊었습니다. Board의 매트릭을 관리할때 none 타입이 나온 부분이 공감되었고 저도 한번 더 고민해보게 되었습니다.
• 쑤: Factory 패턴 사용하신 것, bottom-up으로 설계하신 것이 인상깊었습니다!