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

[godrm]

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

• 개인별 설계나 구현 개선사항
• 그 밖의 질의응답 항목과 의견들
• 지난 2주동안 설계, 구현, 개선 과정에 대한 소감

[korJAEYOUNGYUN]

4그룹 2주차

개인별 브랜치

호종
Jake
윤재영
김척척

개인별 설계 의도

• 호종
  • 야근 ㅠ
• 윤재영
  • 1주차 때 체스판의 rank와 file을 다루는 부분이 Int(체스판의 index)를 직접 사용하게 설계하여 범위 제한 검증과 이동 로직이 복잡하여 이를 개선하고자 하였습니다.
  • rank와 file을 타입으로 추상화하여 복잡한 로직을 분리하고자 하였습니다.
• Jake
  • Game과 Player를 구분하여, Game이 생성되면 두 플레이어(black, white)가 생성된다.
  • Game이 생성됨과 동시에 Board가 새로 초기화되어 플레이를 진행할 수 있다.
  • 기존에 enum으로 처리되던 Piece를 protocol과 struct 구현체로 구분하여 각 Piece 종류별로 대응한다.
• 김척척
  • x

개인별 구현 방식

• 호종
  • 야근 ㅠ
• 윤재영
  • Rank와 File을 enum 타입으로 정의하여 Int로 계산하던 복잡한 구현을 숨기고자 하였습니다.
  • Rank와 File을 가지는 Position 객체를 정의해 체스말의 위치에 대한 로직을 Position에서 담당하게 하였습니다.
  • Piece 프로토콜을 구현하는 다른 체스말 타입들을 정의하였습니다.
• Jake
  • 신규
    • Game의 역할: player에게 턴을 넘겨주며, input string 을 받는다.
    • Player의 역할: board에서 자신의 말을 이동한다.
  • 개선
    • Board가 이중배열이 아닌 포지션을 키로 갖는 딕셔너리 형태로 변경되어 위치에 바로 접근이 용이하도록 변경
  • 확장
    • Piece를 enum 에서 protocol과 struct로 구현하여 각 구체인스턴스에 맞는 액션을 취하도록 수정하고, King을 제외한 Piece들 정의
• 김척척
  • x

질의 응답 항목과 시간들

• Move에 대한 프로토콜을 나눈 이유
• 이동 연산을 어떻게 처리하였는가?
• WhitePlayer와 BlackPlayer를 나눈 이유
• 체스판 초기화에 대한 하드코딩 해결 방법
• 다형성을 하려면 어떻게 해야 하는가
• 지난 주차와 달라진 점은 어떤 부분인가
• 테스트는 어떤 식으로 작성하는가(화이트 박스/ 블랙 박스)
• 재영 - 장애물이 있을 경우를 대비하지 못하여 이 부분 처리에 대한 논의
• Jake - 플레이어의 역할 확장
• Jake - Piece가 위치를 알아야 움직일 수 있는 위치를 계산하는데 이 위치가 Board에 종속되어 있어 이를 어떻게 분리할 수 있을까?

[zzisun]

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

개인별 설계나 구현 개선사항

• summer:
  프로퍼티 래퍼로 Int와 String을 빠르게 변환
  piece protocol, pawn, bishop이 piece를 채택
  optional 대신 empty를 하나 더 선언
  2D 배열을 사용하지 않고 square로 접근하도록 변경됨

• 스티븐:
  ChessPiece를 enum으로 했었는데 확장성을 생각해 protocol로 변경
  Piece에는 이동가능한지 여부를 확인하는 함수가 있음.
  static으로 되어있음. 현위치, 목표위치, 보드를 넣다보니 그렇게 됨. JK가 안좋은 구조라고 공유해주심.(인스턴스 정보를 전혀 활용하지 못함)
  프로토콜의 extension에 처음위치, 이동할 위치 다 접근 가능한지 확인하기때문에 변화량(Delta)만 확인하도록 작성.
  Chessboard가 Equtable을 채택하도록 했는데 swift문법상으로 하위 구체타입이 Equtable을 따르도록 해야하기때문에 비교가 어려울 수 있음. 한번도 안썼어서 지울 예정.
  Position에 Delta를 비교해 이름만 바꿈
  Postion에 Delta더하면 이동한 위치 나오도록
  인스턴스 메소드가 아닌 타입 메소드라 테스트 시 어색함이 있음.

• 민이:
  Piece protocol에서 색상, 생성위치, 이동가능 여부, 출력String을 가지고 Pawn, Bishop 등 체스말을 구현.
  Piece 종류마다 생성위치를 return하는 함수를 사용하여 보드 초기화.
  white, black을
  PieceColor에서 turn을 가지고 있는 걸 수정할 예정.

• 필비:
  체스말을 중점적으로 구현.
  Rank, File을 선언해서 입력받은 "A"->0 과 같이 변경.
  Board를 [[ChessPieceProtocol]]로 변경하면서 EmptySpace 생성. empty가 pieceProtocol을 만족하는게 네이밍이 어색한 것 같다.
  Rook, Bishop등이 이동할 수 있는 위치를 배열로 return

그 밖의 질의응답 항목과 의견들

• 테스트를 작성할 때 경우의 수를 따로 설계하거나 기록하기도 하시나요? 모든 경우의 수를 따져보고 빠짐없이 다루기 위한 방법은 뭐가 있을까요?
  대표적인 케이스
  ex) 배열 nil, 1, 여러개
  성공, 실패 케이스
  테스트케이스를 기록하는게 귀찮다.

• 특정한 체스말의 표시(유니코드)가 바뀌어야 한다면 영향을 받는 곳은 타입은 어디인가요? 예를 들어 BlackPawn 코드만 바뀌는데 WhitePawn 관련 코드도 변경이 생기지 않나요?
  체스말에서 유니코드를 관리
  chessType에서 전체적으로 관리
  -> BlackPawn, WhitePawn 나누는게 좋겠다

• PawnProtocol, BishopProtocol을 나누면 뭐가 좋을까?
  Pawn을 여러개 만드는 경우에 PawnProtocol이 확장성에 더 좋다.
  작은 타입들도 확장성있게 구현할 수 있다.

• 특정 위치에 말이 있거나 위치 이동을 위해서 비교할 때 File, Rank, Position, Location 타입 자체를 비교하나요? 아니면 상위에서 from.rank == to.rank 처럼 값을 가져와서 비교하나요?
  타입자체를 비교하는 게 더 좋다. 상위에서 접근하는 것보다 좋을 것 같다.

[dochoi-bot]

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

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

Lin

ㅠㅠ

데미안

• Piece가 여러가지가 추가되면서 다형성이 필요할 것 같아서 프로토콜을 사용했습니다

Freddy

기존 구조에서 크게 변화한 점은 없으나, 지난 주차의 Pawn의 단일 체스말을 구현했을 때 보다 새로운 체스말이 많이 생겼고 체스말에 따라 이동 가능한 Position 및 체크해야할 조건이 복잡해 지면서 어떻게 나눠서 처리할 것인가에 대한 고민이 생겼었어요. 새로운 체스말에서 다양한 Direction 및 Position을 다루게 되는 상황이 많아지다 보니 이와 관련한 구현이 많이 추가되었습니다.

루이

• Piece를 서브 클래싱하여 Pawn, Rook, Knight.. 등을 구현하였습니다.

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

Lin

데미안

• Pawn의 경우 User에 따라 이동 방향과 아이콘이 바뀌어서 이를 User에 책임으로 줬지만 조금 오버엔지니어링 된 감이 있습니다

Freddy

• 새로운 요구사항에 맞춰서 어떻게 구조화하면 좋을지, 객체별로 각자 처리해야할 일을 보다 더 분명하게 나누려고 했었습니다.

루이

• Piece 들이 움직일 수 있는 포지션을 구하기 위한 메서드인 movablePoints에 신경을 써서 구현했습니다.

---

궁금했던 사항

Lin

데미안

• 없습니다

Freddy

루이

• 없습니다

---

개인별 브랜치 링크

Lin

데미안

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

Freddy

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

루이

• https://github.com/haeseoklee/swift-chess-app/tree/feature-week2
  질의응답 항목과 의견들

[Seungeon-Kim]

Week 2

다음과 같은 내용을 포함하며 형식은 자유롭게 작성하세요

개인별 브랜치 링크

개인별 설계나 구현 개선사항

그 밖의 질의응답 항목과 의견들

지난 2주동안 설계, 구현, 개선 과정에 대한 소감

Ryan Son
Mason
taemin Yun
seungeon Kim

Ryan Son

• Taemin: 객체에 테스트를 위한 init이 있군요?!
  • 추상화하여 Mock 타입을 만들어 테스트를 위한 체스말을 세팅하는 형식으로 변경해보겠습니다.
• Taemin: 테스트를 위한 클로저?!
  • 타입 자체가
• Taemin: 저도 맨 윗줄이 rank 1로 했어요.
• seungeon: 이렇게 메모 남기는것도 좋네요!

Mason

Mason님은 금일 배포날이라 직접적인 참석을 못했습니다!
무사 배포 기원합니다. 🙏

taemin Yun

uml -> test -> comments

• Taemin: 다들 목 객체 어떻게 만드십니까들?!
• Ryan: 순서대로 설명해주셔서 쉽게 이해할 수 있었습니다!
• Ryan: 테스트 명세는 어떻게 나누셨나요?
• Ryan: isBlocked(from:to:board:) 로직을 설명해주실 수 있으실까요?

Seungeon-Kim

• Ryan: class와 sturct를 사용하는 기준은 무엇인가요?
  • 속성들의 Semantic type?(value / reference) 여부
  • mutating 빈도
    위 내용 정도로 구분합니다.
• Ryan: 방향과 재귀를 이용한 MovablePosition 계산 방법이 인상적이었습니다.
  • Taemin: 맞아요
    감사합니다!
• Taemin: Board가 아니라 Game에서 실제 게임이 이루어지는 거군요?
  • 넵, Board는 단순히 piece에 대한 CRUD?정도만 관리하고 체스 게임의 진행은 Game에서 이루어집니다
• Taemin: Position { get } 이렇게 가능하지 않나요?
  • get-only property라서 position의 변경이 불가능해집니다.