1주차 수요일 그룹 2

김현준

고민 사항

• 과연 기물이 위치를 알고 있어야 할까에 대한 고민을 했어요.
  • 보드의 자료구조에 대한 고민을 먼저 했었는데 Map 구조가 적합하다고 생각했어요.
  • 따라서 자동으로 기물 위치를 보드가 알아야 했고, 중복으로 위치를 관리할 필요가 없다고 생각해서 보드에만 위치를 저장했어요.
  • Map 자료구조를 적극적으로 활용, Optional을 이용해서 null 값을 반환할 경우 Blank를 반환하도록 구현 했어요.
  • 근데 Board 클래스가 너무 큰거 같아서 고민이네요.
• Piece를 다룰 때 과연 추상화와 Type를 가져야 할까 고민했어요.
  • Piece가 Type으로 다루기 보단 하위 클래스로 구성했고 getType를 통해 각 타입을 반환할 수 있도록 했어요.
  • Type은 결국 표현과 관련된 것이였기 때문에 굳이 다뤄야할까 싶었어요.
  • 근데 create 팩토리 메서드가 중복되어서 이걸 추상화 메서드로 해결하고 싶었는데… 어렵네요.

공유 사항

• 클래스 마지막 괄호 닫히기 전 띄워쓰기 → 인텔리제이 옵션 !
• row와 col → rank와 file 왜 두 가지를 다루나요?
  • 체스가 익숙치 않아서 다룰 때 두 가지를 사용했어요.
• 팩토리 클래스의 생성자를 private로 막는 것이 좋을거 같아요 !

후기

• 다른 분 코드를 보면서 고민 사항에 대한 구현 방식의 차이를 보는게 좋았어요.
  • 아이디어를 많이 차용해서 구현할거 같아요.
• 내가 잊고 있던 고민에 대한 사항들을 들어볼 수 있어서 좋았아요.
  • 기록을 생활화 하자 !
• 좀더 열심히 해야겠네요,,!

이지표

진행사항

• while문을 돌때 명시적으로 사용하기 위해, 게임의 상태를 enum으로 관리했다. 또한, 사용자의 게임 명령어도 enum으로 묶어서 관리했다.
  • move명령의 경우 move명령 뿐만 아니라, 위치정보도 받아야 하는데 enum으로 관리하는 방식에 문제가 있다.
• Piece에 Color, Type, Position을 포함하는 형식으로 구현하였다.
  • Position의 경우 Piece끼리 같은지 비교를 할때, 필요하다 생각되어 포함하였다.
• 최대한 빠르게 예외 터트리기 vs 책임을 가지는 객체에서 터트리기
  • 최대한 그 객체를 생성할때, 적절한 값인지 검증하도록 하였고, 그 책임을 가지는 객체에서 예외를 터트리도록 설계하였다.

후기

처음 다른 팀 인원들과 모여서 코드리뷰를 진행해보았는데, 각자의 생각을 들을 수 있어서 다양한 관점에 대해 배울 수 있었습니다. 모여서 서로 얼굴보고 리뷰를 진행하니 정있고 좋습니다!

김현수

진행 사항

• 6단계 3번까지 진행했습니다.
• board를 2차원 리스트로 구현했습니다.
• Rank 와 File을 따로 구현하지 않고 row col를 두어서 구현했습니다.
• 제한된 개수의 위치 정보이기 때문에 cmd To position map을 만들어서 반복되는 계산을 제거했습니다.
• piece의 color 와 representation을 String 으로 구현하고 Color 와 Type enum은 생성을 위한 값으로 구현했습니다.
• board는 board 판의 역할만 하고 그 외 게임 규칙 등 진행에 필요한 요소들은 chessGame에 위임하려고 하는 중이다.

질문

• piece 에서 color 와 representation 을 Enum 으로 구현하지 않은 이유가 무엇인지?

→ 잘 기억이 안나는데, 구현이 복잡해져서 그랬던 걸로 기억한다.

후기

다른 사람의 코드를 볼 수 있어서 좋았고 좋아 보이는 코드나 방식을 참고하고 싶다는 생각이 들었다.

이경민

전반적인 구현 설명

• 6번 과제 리팩토링 진행중
• Piece를 보드에 저장하는 방식으로 Map을 활용했습니다. → Board는 DB의 역할을 하고 있지 않나? 라는 생각에 기반해서 Key로 위치정보 (Location VO)를 사용하고 Value를 Piece로 사용하고 있습니다.
• Piece Abstract Class 를 상속받은 하위 구현 클래스들을 사용하다보니 정적 팩토리 메서드로 하위 구현 클래스를 생성하는 과정이 복잡해보여서 declearConstruct를 활용하는 방식으로의 리팩토링을 진행했습니다.
• 책임의 구분이 명확히 필요할 것이라고 생각해서 책임 소재에 맞게 클래스를 분리하는 리팩토링을 진행하고 있습니다.

질문들~

• Q. 구현 방식에서의 고민이 깊은 것 같습니다!
• A. 생각과 다른 구현 예시에서 벗어나고자 계속 생각하고 적용하고 있습니다 :D
• Q. Type에서 Class.class의 isInstance() vs instanceOf
• A. 기존에는 instanceOf를 사용했는데 팩토리 메서드 리팩토링 과정에서 .isInstance()를 적용하게 되서 이를 반영하는 중입니다! 이런 경우가 아니면 instanceOf 사용할 것 같아요

후기

• 공통된 구현사항에 대한 다양한 접근이 흥미로웠습니다.
• 하나의 코드에 대해서 다양한 의견이 나올수 있고, 전반적으로 객체지향을 준수하고자 노력하는 포인트가 하나씩 존재하는 점이 인상 깊었습니다.

이호석

코드리뷰를 하며 공유했던 내가 고민했던 부분들!

지금까지 코드를 작성하면서 가장 시간을 많이 들이고, 애썼던건 기존 코드 베이스를 이해하는데에 있었습니다. 그래서 코드를 작성하면서 남이봐도 쉽게 이해할 수 있게끔 작성하기 위해 많은 노력을 했습니다!

최대한 메소드 컴팩트하게 만들기

• 메소드 네이밍과 메소드가 한 가지 기능을 하도록 만들기
  • 메소드 자체가 최대한 한 가지의 기능만 할 수 있도록 하여 변경하는 이유가 하나만 되도록 만들려 시도했습니다.

의미가 전달되기 어렵다면 테스트 코드를 통해 추가정보 제공하기

• 테스트 코드는 작성한 로직을 테스트를 하는 용도도 있지만, 테스트 하는 주제 자체가 비즈니스적인 결과를 나타내야 한다고 생각합니다. 따라서 테스트를 작성하거나 네이밍할때 세부 구현에 의존하기 보단 해당 코드가 어떤 동작을 하는지, 어떤 결과를 만들어주는지에 대한 비즈니스적인 결과를 표현하기 위해 노력했습니다.

내가 작성하는 코드는 나만의 주관을 담기

• 작성하는 코드 한 줄 한 줄에 대해 최대한 저만의 이유를 담기 위해 노력했습니다. 혼자서 작성하면서도 ``왜 이렇게 작성하는거야?` 하는 질문을 스스로에게 계속 던져가며 타당한 이유를 만들기 위해 노력했습니다!

코드리뷰 진행 후기

다 똑같은 미션이기에 동일한 코드를 가지지 않을까라는 생각이었지만, 동료들의 생각을 들어보면서 아 저런 관점도 생각해 볼 수 있구나! 하는 배움이 컸습니다~~

또한 코드리뷰를 진행하면서 동료들의 생각에서 공통점을 찾을 수 있었습니다. 객체가 어디까지 책임을 가져야 하는지, 어디까지 분리하고 어떻게 응집을 시켜야 할지에 대한 각기다른 고민을 보면서, 열정과 더 열심히 해야겠다는 자극도 받게 됐습니다~!~!

자신의 코드를 보여주는게 정말 부끄럽지만,, Group2팀 정말 고생 많으셨습니다!! 😁

유동근

구현 설명

핵심 객체 설명 요약

game : 체스 게임의 상태를 나타내는 책임을 가지는 클래스

board : 체스판의 상태를 나타내는 책임을 가지는 클래스

piece : 체스말을 나타내는 추상클래스로 color, rank, file과 같은 정보를 가지고 있습니다.

rule : 체스말의 이동 및 공격 규칙을 나타내는 클래스

NormalRule : 단순한 이동 규칙을 나타내는 클래스

유연한 구조를 만들기 위해서 부분적으로 tdd를 활용해서 개발을 진행하였습니다.

코드의 이해를 돕기 위해서 좋은 주석에 대해서 고민하면서 주석 작성에 신경을 써왔습니다.

질문

Q : Board에서 setPiece를 public으로 개방했지만 사용하는 부분이 테스트 코트와 보드로 제한적으로 사용하는데 /이렇게 한 의도가 있을까요?

A : 기물의 위치를 변경시킬 때, Game 과 같은 클래스에서 사용할 수 있어서 개방하여 사용하게 되었습니다.

→ setPiece 대신 update와 같은 단어를 사용하면 좀 더 의미가 잘 전달될 수 있을 것 같습니다.

후기

다른 분들의 코드를 보면서 동일한 요구사항을 어떻게 구현할 수 있어서 재미있었습니다. 좋은 아이디어를 적용하여 더 높은 퀄리티의 코드를 작성할 수 있어서 유익했던 시간이었습니다.