이번 주에도 어김없이 페어 협업미션이 시작됐다.
나의 팀원은 누구일까 설렘반 긴장반으로 결과를 확인해보았다.
한번도 해보지 않은 3인 페어로 미션을 진행하게 되었다!
좋은건지 안좋은건지 예상이 되지 않아 조금 걱정도 됐지만,
페어들과 오프라인 일정을 잡으면서 서로 배려해주는 느낌을 받아 이번 미션도 크게 걱정없이 진행할 수 있겠다는 생각이 들었다 :)
3인페어의 장단점
3인 페어의 장점으론 보다 재밌게 소통하면서 개발할 수 있다는 점!
서로 얘기할 거리도 많고, 팀원들이 누구였는지, 자소서를 어떻게 썼는지, 평소에 어떤 개발을 해왔는지 수다떨면서 더 친해질 수 있었다.
3인페어다 보니 서로 주제가 끊임없이 많이 나오고, 대화가 끊기지 않아 더 친해질 수 있었던 듯 하다 :)
협업 마지막 날에는 파랑 크루 집에 가서 떡순튀와 심술 한병 먹기도 했다.
이날 4기-잡담방에 인증샷을 남겼는데, 루키가 술을 그렇게 좋아한다는 소문이 ㅎㅎ
알고보니 루키가 술꾼으로 유명한 엄청난 인싸였고,
파랑은 홍대, 신촌, 대흥역 근처 맛집들을 모조리 다 알고 있는 엄청난 인싸였다.
인싸페어들과 함께 잠깐 인싸체험을 할 수 있었던 기회 :)
또한, 3인페어로 진행하면 장점이라 하기엔 애매하지만, 의견 조율이 조금 더 빨리 되는 느낌도 있었다.
2인페어일 경우 의견대립이 1:1로 발생하기 때문에 충돌이 끝이 나지 않을 수도 있는데,
3인페어일 경우 의견대립이 2:1 또는 1:2로 이루어지기 때문에 정답이 없는 문제(변수명 정하기, 가독성 등)의 경우 다수결의 원칙에 따르는 경우도 존재했다.
단점을 뽑자면, 3인 페어인 만큼 서로 의견이 다른 점이 많아 시간이 좀 더 오래 걸린다는 점이다.
의견 제시가 2인페어일 때보다 1.5배 더 많이 이루어진다고 생각하면 될 듯하다.
아무래도 서로 각자의 코딩 스타일이 있고, 각자의 구조설계가 있기 때문일 듯하다.
다행히 루키, 파랑 모두 서로의 의견을 잘 조율하려는 모습이 보여 의견조율하는데에 거의 문제가 없었다.
개인적으로 이번 미션에서 페어들과 진행하면서 정말 좋았던 점은,
의견충돌이 발생했을 때 결론이 나지 않을 경우,
각자 생각을 정리하는 시간을 15분 정도 가져보고 발표하는 시간을 가져본 것이었다.
생각을 정리하면서 보다 설득력있는 구조 설계를 준비할 수 있었기 때문이다.
미션을 통해 배운 점
이번 미션은 지난 미션과 유사하게 상속, 인터페이스를 이용한 다형성이 주제였기 때문에,
추가로 특이하게 배운 점은 없었지만,
요구사항이 지난 미션에 비해 빡세고, 구현량이 많다보니 클린코드를 만들기는 더 빡세게 느껴졌다.
일급 컬렉션을 가지는 객체를 만들어 책임을 줄이자
게임을 진행하는 도메인인 BlackJackGame 클래스에슨 세 개의 인스턴스 변수를 가지고 있었다.
Deck, Dealer, List<Player>.
그런데 아래와 같은 요구사항이 존재했다.
특히 3개 이상의 인스턴스 변수를 가진 클래스를 사용하지 말라는 것이 어려웠다.
아무래도 구현량이 많은 미션이다보니, 의존성을 2개 이하로 줄이는 것이 꽤나 어려웠다.
따라서 Dealer와 List<Player>를 함께 가지고 있는 Participants 클래스를 만들어주었으며,
이를 통해 엔티티를 더 작게 만들어 SRP(단일 책임 원칙)를 보다 잘 지킬 수 있게 해주었고, 이를 통해 인스턴스 변수도 Deck, Participants로 2개를 가지게 만들어주었다.
추상 클래스로 중복을 줄이자
이번 블랙잭 미션에서 Dealer, Player의 중복로직이 많이 발생하는데,
추가 요구사항에 딜러와 플레이어의 중복 코드를 제거하라는 것이 있었기 때문에 인터페이스, 추상클래스와 같은 다형성 사용이 필수적이었다.
인터페이스를 이용할지, 추상클래스를 이용할지 고민을 많이 했다.
결론부터 얘기하자면, 우리는 추상 클래스를 이용했다.
인터페이스는 선언부만 가지며, 이러한 점을 이용해 자식 클래스와 부모 클래스 사이의 의존성을 줄일 수 있다.
따라서 인터페이스는 has-a 관계일 때 주로 사용한다.
그런데, 이번 미션에서는 중복 코드를 제거해야 했고,
Dealer Is-a Participants, Player Is-a Participants의 Is-a 관계도 성립했으며,
추상 클래스는 완전히 동일한 메소드를 중복을 줄이기 위해 추상클래스 내에 직접 구현할 수 있다는 장점도 존재했기 때문에 추상 클래스를 이용하게 됐다.
딜러, 플레이어 모두 중복된 코드는 abstract 클래스에서 작성해주었고,
둘의 차이점이 존재하는 코드는 abstract 메서드로 작성해주었다.
다만, 추상클래스는 추상클래스만의 단점 (불필요한 클래스 생성 가능성, 의존성 존재)가 있기 때문에 추상 클래스가 정답이기 때문에 사용한 느낌이라기보단, trade-off 느낌으로 선택을 한 느낌에 더 가까웠다.
이렇게 이번 미션도 페어들과 함께 열심히 달려 PR을 제출할 수 있었다!
물론, 아직 완벽한 코드가 아닌 것은 물론이고,
문제점들이 많이 보이는 코드들도 당연히 존재한다.
test도 모든 경우를 검사한다고 보기 어려운 듯하다.
이러한 문제점들은 이번 포스팅에 작성하지 않고, 다음에 리뷰어의 피드백을 받으면서 추가로 포스팅해볼 예정이다~
처음엔 3인페어를 해본적이 없어 긴장도 좀 했었는데,
좋은 분들을 만난 덕에 재밌게 미션을 진행할 수 있었다.
다음에는 파랑 말처럼 코딩 외에도 신나게 놀기 위해 만나는 것도 좋을 듯 하다 :)
'JAVA > 우아한테크코스 4기' 카테고리의 다른 글
| [220323] 블랙잭 미션 피드백을 통해 배운 점 (2) | 2022.03.23 |
|---|---|
| [220320] 우아한테크코스 4기 6주차 후기 (6) | 2022.03.21 |
| [220305][JAVA] 로또 미션 리뷰 피드백을 통해 배운 점 (2) | 2022.03.05 |
| [220225] 우아한테크코스 4기 3주차 활동 후기 (6) | 2022.02.26 |
| [220225][JAVA] 크리스와 페어 협업미션을 통해 배운 점 (로또(자동) 미션) (6) | 2022.02.25 |