1주차 금요일 그룹 3

그룹3: 최세민, 이호석, 박혜성, 이지표, 김규원, 최현식

😎 박혜성

호석님

• 예외 메시지가 개발자에게 충분한 정보를 줄 수 있도록 잘 설정한 것 같습니다.
• 테스트 메서드 이름을 한글로 하여 명확성을 확보한 것 같습니다.

세민님

• 스테이트 패턴을 통해서 문제 해결을 시도한 것이 인상적이었습니다.

지표님

• 기물의 움직임을 표현하기 위해 다형성을 잘 활용하신 것 같습니다.
• 체크 메이트까지 복잡한 규칙을 깔끔하게 구현하셨습니다.

현식님

• 코드를 깔끔하고 가독성있게 잘 짜신 것 같습니다.

규현님

• 메서드 추출을 통해 좀 더 코드를 깔끔하게 정리할 수 있을 것 같습니다.

배운 점

• instanceof에 대해 어떻게 생각하는지 그룹에게 물었습니다. 리팩토리으로 인해 자식이 삭제되는 상황에서 자식에 대한 의존이 될 수 있다는 답을 들었습니다.
• 저의 경우 팩토리 메서드를 자식 클래스에 다 만들어주었는데, 아예 별도의 클래스로 분리하는 것도 깔끔하고 좋아보입니다.
• 테스트 작성 시 별도로 @DisplayName을 사용하지 않고 메서드 이름을 한글로 지으신 분들이 많습니다. 코드를 읽을 사람이 모두 한국인이라는 데에서 한국어만으로 해도 문제 없고, 관리해야 할 것도 줄어드는 점에서 한국어로 해도 좋은 것 같습니다.
• GUI까지 진행하신 분들이 많습니다. 고민하는 시간을 줄이기 위해 자신만의 원칙을 세워 빠르게 문제를 해결할 수 있어야 할 것 같습니다.

😎 최세민

나의 코드 리뷰

• Pawn의 경우 도메인지식 부족으로 인해 이동제약조건을 잘못 구현했습니다. 도메인 지식을 더 중요하게 생각해야겠습니다.
• State 패턴을 사용해서 게임의 상태를 관리하려고 했습니다. State 패턴은 하나의 메소드로 객체의 상태를 전이하는 형식으로 구현해야하는데 상태마다 필요한 파라미터에 차이가 있어서 올바르지 않다고 생각했습니다. 다음부터 패턴을 적용할 때에는 좀 더 신중하게 구조를 생각해야겠습니다.

배운점

• canJump를 추상메서드로 사용하였는데 Type에 필드로 설정하는 것도 좋은 방법이라고 생각했습니다.
• validation 관련 메서드를 boolean으로 할 지, throw로 던질지 고민했는데, throw로 예외를 던지는 것이 더 많은 정보를 외부에 전달할 수 있는 것 같다고 생각했습니다.
• 호석님이 문서화까지 고려한 테스트코드를 작성한 것이 좋다고 느꼈습니다. Nested 클래스로 테스트를 계층적으로 작성한 부분이 인상깊었습니다. 테스트코드를 더 중요하게 생각하고 다른 사람이 테스트코드만을 통해 비즈니스로직을 이해할수있도록 노력해야겠습니다.
• Comparator의 api를 잘 알고 있으면 도움이 될 것 같습니다.
• Piece가 Position을 가지도록 구현하는 것도 궁금했던 코드였는데 현식님의 코드를 통해서 확인할 수 있어서 좋았습니다. Piece의 책임을 조금 넘어서는 부분일 수도 있지만, 상위 모듈과 어차피 의존이 많은 경우라면 더 비즈니스로직을 구현하기에 적절한 선택을 하는 것도 좋은 방법인 것 같습니다.

😎 이호석

코드리뷰를 하며 공유 (or 고민 or 배웠던 or 등) 했던 부분들

• 테스트 코드의 작성 순서에 대한 고민

  보통 가장 작은 단위의 객체부터 만들기 시작하는데 해당 객체의 테스트가 완전하게 되어 있다면 그보다 상위 계층의 테스트는 해당 계층의 테스트를 어떻게 할 수 있을까

• 책임의 분리는 어떤 기준으로 하는가?

  일단 메소드가 하나의 책임을 가지고 있는지 살펴보고 분리한다.

지난 코드리뷰와 달리 완성된 서로 다른 애플리케이션을 보면서 공통된 고민들을 어떻게 해결하려 했는지 많이 배울 수 있었습니다.

가장 뜨거운 논의가 됐던건 Position이라는 위치를 Piece(기물)이 가져야 하는지, Board(체스판)이 가져야 하는지에 대한 논의였는데 같이 리뷰했던 동류분들이 골고루 구현했어서 비교해보면서 재밌게 리뷰할 수 있었습니다!

저는 오늘도 열심히 테스트 코드를 팔았습니다(?)

미션을 작성하면서 정말 이 코드는 테스트하기 싫다 하는 부분들이 있었는데 해당 코드를 왜 테스트 해야 하는지, 안했을때의 사이드 이펙트가 무엇이 있을지 고민해보고 나누기도 했던것 같아요~~

코드리뷰를 하면서

모든 코드가 저마다의 이유가 있고, 그 본질을 따라가다 보면 항상 책임으로 결론이 났습니다. 내 코드에만 빠져있지 않고 다른 사람들의 코드도 보고, 옆에 있는 동료분들과 고민해보고 이야기를 나눠보며 생각을 확장해보는 경험을 앞으로도 쭉 해보고 싶네요 ㅎㅎ

😎 이지표

기물아 부탁해~

다른 분들과 다른 점은 기물들에게 위치를 이동 명령을 받으면, 기물이 스스로 움직이는 위치를 점검하고, 자신이 자신의 위치를 바꾸게 했다. 나의 코드에서는 기물이 위치 정보를 가지고 있기 때문에, 위치를 직접 이동시키는 것은 기물의 책임이라 생각했다. 이러한 코드는 새로운 기물을 추가하더라도, 체스 게임은 기물의 정보를 자세하게 알지 않아도 되고, 그저 이동 명령만 내리면 된다.

체크… 체크 메이트…

그룹원분이 가장 코드를 작성할 때 어느 부분이 힘들었는지 물어보았었다. 나는 망설이지 않고, 체.. 체크요! 체크와 체크 메이트 구현이 가장 어려웠다. 우선 기물이 움직여서 킹을 잡을 수 있는지 확인하는 체크 과정이 필요하고, 체크 상태이면 킹이 움직여도 잡히는 상황인지 확인하는 체크 메이트 상황이 필요하다. 이를 확인하기 위해 모든 기물들을 이동 가능한 위치로 이동시켜야 한다. 이 과정에서 버그가 굉장히 많이 터졌는데, 문제는 다시 undo할때이다. 기물에게 다시 move 명령을 내렸더니, Pawn같은 경우 뒤로가기가 안되기에 에러가 계속 발생한 것이다. 이 부분을 수정하기 위해 엄청 해맸다.

뛰어나신 동료들!

동료분들의 코드를 직접 설명을 들으면서 보았는데, 내가 놓친 부분들도 섬세히 진행한 하신 것 같다. 이 번주는 경주마처럼 작성한 코드를 다시 살펴보기 보다는, 기능 구현에 급급 했던것 같았다. 이번 미션을 마무리하고, 다시 한번 나의 코드를 살펴보면서 가독성이 떨어진 부분, 불변으로 만들 수 있는 부분, 테스트 코드를 의미있게 작성하는 부분 등등 살펴봐야겠다. 이번주도 다들 고생하셨습니다!! 다음주도 화이팅!!

😎 김규원

동료 리뷰 코드 안에서 위치를 Position index 로 관리할까? 아님 String 으로 관리할까?

• 저는 input string 를 받자마자 Position 으로 변환해서 코드 안에서는 string 이 돌아다니지 않도록 구현을 했습니다. Position 을 생성하는 과정에서부터 validate 를 해줄 수 있다는 장점이 있는거 같습니다.

해당 클래스가 캡슐화를 잘 지키고 있는지 확인해보기

• 저는 Board 는 piece 를 알고 piece 는 board 를 알지 않도록 구현을 해두었습니다. 그렇다면 piece 가 board 를 참조하지 않음을 확인하는 방법은 import 문을 확인하는 것이라는 피드백을 받았습니다.

Position 를 piece에서 관리해야 하는지, board 에서 관리해야 하는지?

• 처음부터 끝까지 이 점에 대한 고민이 많았습니다. 처음에는 과제 조건에서 piece 를 VO 로 관리하라는 조건 때문에 가변적인 position 를 Piece 에서 빼고, Board 에 넣었습니다. 지금 돌이켜보니 한번 생성된 piece 객체에 대한 불변성을 보장하기 위함이었던거 같습니다. Piece 에서는 Position 를 가지지 않기 때문에 board 가 복잡해지긴 했지만 그럼에도 VO 로 관리하는 장점이 있는거 같습니다.

Factory 클래스는 언제 필요할까?

• 생성자로도 가능한 팩토리 클래스를 언제 쓰는지 좋은지에 대한 고민이 있었습니다. 논의해본 결과, 객체를 감추고 싶을 때 쓰면 좋은거 같습니다.

인터페이스 쓸 만한 곳?

• 저는 구현을 못했지만 console input/GUI input 인터페이스를 만들어 생성자에 자유롭게 주입하는 방식을 쓰신 것을 보니 좋아보였습니다.

😎 최현식

고민되었던 것들

• Piece를 추상화하는 것이 맞을까?
  • 결국 추상화하긴 했지만.. ^^ Piece를 추상화하기 직전에 관련한 모든 정보를 정리한 Enum 상수가 있었습니다. 이동 등 각 기물마다의 특수한 상황들도 함수로 정의할 수 있을 것 같았지만 시간상 익숙한 방식으로 빠르게 구현하기 위해 시도는 못해봤습니다.
• Piece에서 Position값을 가지고 있는게 맞을까?
  • 최초에 ValueObject였던 Piece에 위치 등에 변경가능한 상태값을 추가하는 것이 맞을까 생각이 들었습니다.
  • copyWith 등의 메서드를 통해 분리하는 것도 하나의 방법일 것 같다는 의견을 주셔서 앞으로는 관련한 쪽으로 생각해 볼 수 있도록 공부를 해봐야겠습니다! (코드 복잡도를 고려하자!)

배운점!

• Piece가 포지션을 가지게 되면서 발생하는 문제가 있지 않을까? 라는 생각이 있었는데
• 다른 분들의 코드를 보고 설계한 과정과 구조를 보고 들으면서 객체지향적인 관점, 도메인적인 관점에서 더 깊게 생각해야 겠다고 느꼈습니다.
• 특히 다른 분들의 테스트코드를 보면서 시간이 없어서 못짜는건 핑계다! 오히려 테스트코드가 시간을 줄여줄 수 있지 않았을까? 하는 생각이 들었습니다.
• 앞으로 불변, 변경가능성, 책임에 대해 많이 고민해봐야겠다는 생각!!