1주차 수요일 그룹 3

그룹 리뷰

| Group 3 | 김규원, 고동훤, 김민주, 박혜성, 박정제, 강승훈 |

김규원

1. 과제에서는 Piece 를 VO 로 관리하라는 조건이 의문이 들었습니다. 
(컬러, 타입) 두 가지 속성이 같으면 같은 객체로 보는 것이 VO 의 의의인데 하얀색 폰이 이미 8개 존재하는 것부터 VO 의 의의가 깨지는 느낌이었다.
그래서 일단은 Piece(Color, Type) VO 으로 두고 PieceOnBoard(Color, Type, Position) 두 개로 두어 Piece 가 Board 위에 존재할 때는 다른 클래스로 생각하게 뒀습니다.

2. Rank 클래스가 Piece 와 중복되는 메서드가 있어서 고민을 했었습니다. 
예를 들면, Piece와 Rank 모두 getRepresentation() 라는 메소드가 존재하는데 같이 논의해보니, 오히려 각자 존재하여 각자의 상태값을 내놓는 것이 객체지향적이라고 판단하였습니다.

리뷰어(박혜성): showBoard()의 개행을 조금 더 줄여도 좋을 것 같습니다!

고동훤

기존의 테스트 코드가 깨질 때 어떻게 하면 좋을까?
 - 기존의 구현사항을 변경할 일이 발생했을 때 테스트 코드 또한 수정은 불가피하다. 
 그런데 기존의 테스트 코드가 전혀 필요없어졌을 때 과감하게 모두 걷어내고 제로에서 다시 시작하는 것도 좋은 방법인 것 같다.
 
"Swing"을 사용법을 한번 찾아보자.
	 - "Swing"을 사용할 때 동시성 문제가 발생할 것 인가?

리뷰어(박혜성): 더 이상 필요하지 않은 테스트 코드를 삭제하신 과감함이 좋은 것 같습니다.

김규원 : 저는 이미 존재하는 테스트 코드 통과를 위해 오버로딩을 하며 진행했었습니다. 스탭을 진행하면서 달라지는 요구사항에 맞춰 테스트 코드를 과감히 삭제하는 것도 좋은 방법인거 같습니다.

김민주

궁금한거
static import?
-> 답: assertThat같은 건 써도 상관없지만, 도메인 로직이면 static import 안 하는 게 낫지않을까??

count 변수를 없애고, Comparator는 Enum으로 빼든지 해서 외부에서 접근 못 하게 하는 게 맞다는 생각이 드네요!!!

리뷰하면서 배운 점:

다양한 구현체를 찾을 때, Class와 제네릭을 이용하는 방법도 있다는 걸 느낌
record는 기본 생성자가 X, (이유를 생각해보면 record는 불변 객체니깐?)

리뷰어(박혜성): 필요하지 않은 인스턴스 변수 발견! 성능상 큰 문제가 없다면 중복되거나 메서드로 구할 수 있는 값을 변수로 가지고 있을 필요는 없을 것 같습니다.

박정제 : IntStream 활용과, toList()의 불변성 객체 생성도 배웠습니다!

고동훤 : 확장성을 고려해서 구현하신 부분이 인상깊었습니다.

김규원 : 제 프로젝트 파일에 List 를 수정한 메소드가 있어서 toList 가 반환하는게 왜 불변이었는지 다시 찾아봤습니다. 찾아보니 stream에서의 toList() 는 불변 객체를 반환하더군요! 자바 버젼이 업데이트 되면서 불변 객체를 반환하기 위한 toList() 가 생겼다는 점을 알게 되었습니다.

박혜성

요구사항을 따라가면서 구현했습니다.
각 체스 구성원의 책임을 고려하였습니다.

스트림 api 리뷰를 받았습니다. 리스트에서 사용하고 있는 값의 합을 `reduce()`를 이용해 구현하고 있었습니다.
`mapToInt()`, `mapToDouble()`을 이용해서 `sum()`을 이용하면 좀 더 명시적이어서 좋을 것 같습니다.

김규원 : Piece 를 추상 클래스로 두고 클래스를 따로 두고 각 구체적인 피스에 대해 상속받는 클래스를 만드신 점이 인상깊었습니다! 저도 지금은 Enum으로 타입 관리를 하고있는데 class 상속에 대해 한번 고민해봐야될거 같아요!

박정제

이동규칙

• 공통 이동규칙을 만들자
• 특수 규칙이 있다면 따로 상속받아 만들어보자

Class 매개변수

• type enum 을 사용하지 않고, class를 매개변수를 사용해서 사용
• 제네릭을 사용해서 Piece 를 상속받은 객체만 받을 수 있도록함

private <T extends Piece> List<T> findAllPieces(Class<T> type) {
    return filterPiecesByType(type)
            .collect(Collectors.toList());
}

record

• 보드를 표현하는 Map의 키로 활용
• 불변성 객체를 만들때 좋음
• 생성자는 반드시 public이어야 한다
• 따라서, 검증이 필요하다면 생성자를 private로 제약할 수 없으니 생성자를 정의해 내부에서 검증하도록 하자

리뷰어(박혜성): 제네릭을 사용해서 기물의 반환 타입을 지정한 것에서 인상적이었습니다. 체스 보드의 인스턴스 변수가 Map과 List 중복해서 관리되는 것 같다는 느낌을 받았습니다.

고동훤 : UpperBoundedWildCard를 사용해서 예상치못한 문제를 사전에 방지한 점이 좋았습니다. 코드를 보면서 Board와 Piece 가 어떤 책임과 역할을 가지고 있어야하는지 고민해볼 수 있었던 것 같아요! bb

김규원 : 저 또한 제네릭을 이용하여 받아낸 것이 인상적이었습니다. 제네릭이랑 enum 중에 무엇이 더 좋을까에 대한 이야기를 했었던거 같은데, 제네릭이라면 프레임워크 reflection 처럼 가져올 수 있다는 장점이, enum 이라면 타입 캐스팅 없이 동작한다는 장점이 있는걸 알게되었습니다!

강승훈

• 페어프로그래밍 진행
• 요구사항을 정확히 따라가기 보다는 페어와 상의하며 방향성 결정
• 책임 분리를 다들 어떻게 하는지, Stream, Generic 등을 다양하게 활용할 수 있다는 것을 배웠습니다.

리뷰어(박혜성): 페어 프로그래밍을 통해 과제를 해결한 부분이 인상적입니다.

고동훤 : 페어 프로그래밍을 하면 오히려 생산성이 떨어지는 경우도 더러 봤는데, 진행속도가 빠른 것을 보고 되게 효율적으로 진행하고 계신다는 느낌을 받았습니다.

김규원 : 저도 페어프로그래밍이 이상적이지만 지키기 정말 어렵다고 들었는데, 같이 고민하시면서 해결해나간 모습이 인상적이었습니다!