서론

페어 블랙캣과 함께 블랙잭 미션을 시작했다.

미션을 진행할 수록 도메인의 범위가 커지고있어 설계에 투자하는 시간이 많아졌다.
블랙캣은 설계가 매우 꼼꼼하고, 노션 사용도 매우 능숙해서 설계를 하는 시간이 즐거웠다.

블랙잭 미션을 수행하며 좋았던점, 아쉬웠던점을 정리해보자.

소프트스킬

이번 미션을 통해 블랙캣에게 여유로움을 배울 수 있었다.

💡 소프트스킬?
소프트 스킬이란 다른 사람과 함께 일하고 상호작용하는 방식을 나타내는 대인관계 스킬을 의미한다.

좋았던 점

😎 친해지기

페어프로그래밍을 진행할 때 지키고 싶었던 체크리스트를 수행해봤다.

• 페어와 같이 밥먹기!
• 페어와 처음 만나고 10분동안은 미션 이야기 하지않기!
• TDD를 진행한다면 네비게이터는 의식의 흐름을 경계한다!
• 궁금하거나 의견차이로 인한 토론이 필요한 경우 시간을 멈추고 토론하기
• 8번 교체마다(한사람이 4번 드라이빙하면) 5~10분 휴식하기
• 5분마다 드라이버-네비게이터 교체하기

페어와 같이 밥을 먹으며 친해지고, 페어와 처음 만났을 때 미션이야기를 하지 않으면서 서로에 대해 알아가는 시간을 먼저 가졌다.
서로가 생각하는 방식에 대해 미리 알아둘 수 있어서 토론할 때 많은 도움이 되었다.

🖊️ 설계 과정

노션을 이용하여 설계를 진행했는데, 이 과정에서 이모지를 적극 활용하여 한 눈에 알아보기 편했다. 👍

또한 클래스 단위까지 들어가지 않는 적절한 선에서 설계가 진행된 것 같아 코드 작성간 설계가 크게 틀어지지 않았던 부분이 인상깊었다.
시각적인 의미를 두는 것만으로도 문서를 봤을 때 의미 전달력을 높여줄 수 있다는 것을 배웠다.

✅ TDD

페어와 TDD에 대한 경계를 계속 하면서 설계가 보다 탄탄해졌다는 생각이 들었다.

이 과정에서 서로가 생각하는 관점을 명확히 드러내는 연습도 할 수 있어서 좋았다.
지난 사다리 미션에서 유지하고 싶었던 장점을 그대로 가져올 수 있었던 것 같다.

기술부채

페어와 미션을 진행하면서 기술부채를 계속해서 쌓아나갔는데 혼자서 고민하던 것 보다 더 심도있는 고민거리를 가져갈 수 있는 것 같아 너무 좋은 경험 중 하나였다.

사소한 내용이여도 생각하고 고민하는 과정에서 바로 기술 부채에 기록해두는 습관을 배울 수 있었다.
바로 해결은 못하더라도 나중에 봤을 때 고민내용을 복기하는 데 가장 효율적인 방법이라고 생각했다.

아쉬웠던 점

👀 도메인을 바라보는 관점

도메인을 설계할 때 너무 현실세계의 관점에 맞춰 설계했던 부분이 아쉬웠다.

실제 카드를 가지고 블랙잭 게임을 수행하는 모습을 토대로 객체에 역할과 책임을 부여하다보니 코드로 나타냈을 때 어색한 부분이 몇군데 존재했다.

예를들면 현실에서 카드팩을 구매했을 때 카드가 순서대로 정렬되어있다는 부분을 반영했던 부분이 있다.
구현이 진행되고 난 뒤에 과연 블랙잭 게임을 수행하는데 필요한 상태였을까? 라는 의문을 뒤늦게 가졌던 점으로부터 도메인 설계 간 현실 세계에 너무 몰입했었다는 점이 약간 아쉬웠다.

동시에 프로그래밍적으로 객체가 어떤 책임을 가져야할지 경계할 수 있는 관점을 얻은 좋은 기회이기도 했다.

하드스킬

하드스킬에 대한 부분도 빼먹을 수 없다 🔥

💡 하드스킬?
하드 스킬은 특정 훈련을 통해 개발할 수 있는 스킬을 의미한다.

좋았던 점

⚒️ 부모 클래스 생성자

PlayerName이라는 객체에서 validationName(name) 메소드를 먼저 수행한 뒤 super(name) 을 통해 생성자 주입을 하려고 했다.

super() 메소드는 부모 클래스의 생성자를 호출할 때 사용된다.

하지만 부모 클래스의 생성자를 가장 먼저 호출하지 않으면 컴파일 단계에서 오류가 발생한다.
왜 이럴까? 를 페어와 고민해본 결과 다음과 같은 결론을 도출할 수 있었다.

validationName(name)을 수행한 뒤로는 name이 변질될 수도 있기 때문에 데이터의 정합성이 유지되지 않아 반드시 super()를 생성자 가장 위에 올려야한다.

가만히 생각해보면 위 이유가 아니여도 초기화되지 않은 부모의 필드를 참조하는 경우가 있다면 큰 문제가 될 것 같기도 하다.
때문에 super()는 생성자의 가장 위에 올려주는것으로!

✅ CSV 공백값 테스트

ParameterizedTest를 수행할 때 공백만 들어있는 값을 테스트하고 싶었다.

CsvSource에서는 작은따옴표 ' 로 감싸줘야한다는 점을 알게되었다.

🔋 HashMap initialCapacity

HashMap을 사용할 때 인자로 정수를 넣어줘서 초기 용량을 지정해줄 수 있다.

📝 EnumMap

성능상 이점을 취하기 위해 EnumMap을 사용했다.

EnumMap을 사용하면서 간단하지만 왜인지 궁금했던 내용이 있었다.
EnumMap으로 생성하면 모든 key값이 Enum으로 생성되는건가..?

ex) 
ENUM1, 0,
ENUM2, 0,
ENUM3, 0,
ENUM4, 0,
ENUM5, 0, ...

정답은 아니다. 키를 한정하는 것이지 키를 알아서 생성해주는 게 아니다.
생각해보면 당연할 수도 있는것이 그 뒤에 있는 Integer라는 값을 어떤 Default 값으로 초기화해준다는 보장을 할 수 없다.

따라서 EnumMap은 Key를 한정해주는 것이지 init까지는 해주지 않는다.
(당연한건데 막상 처음봤던 내용이라 생각이상으로 만능인줄 알았다 😂)

📝 stream의 flatMap

페어가 마침 stream에 대해 학습하고 있던 시점이라 flatMap에 대해 배울 수 있었다.

flatMap은 중복 구조로 들어가는 stream에서 다른 stream의 요소를 함께 참조하면서 마치 하나의 stream으로 사용할 수 있도록 도와주는 기능이다.

Arrays.stream(CardShape.values())
                .flatMap(cardShape -> Arrays.stream(CardNumber.values())
                        .map(cardNumber -> new Card(cardNumber, cardShape)))
                .forEach(cards::add);

위와같이 CardShape와 CardNumber를 가지는 Card라는 객체를 만들기 위해 두 값들을 모두 순회하며 조합하는 stream 구문을 작성해볼 수 있었다.

아쉬웠던 점

🔥 기술부채 해소

기술부채가 쌓이는 속도에 비해 해소하는 속도가 느려 아쉬움이 많았다.
페어와 함께 해소하는 부분 외적으로 스스로 학습하며 성장하는 시간을 많이 확보하지 못한것이 아쉬웠다.

🔥 구현의 조급함

Controller와 View단을 구성하면서 마감시간이 다가오자 조급함이 몰려오면서 구조에 신경쓰지 못한 코드를 계속해서 작성했었다.

스스로의 실력에 대한 불확실함이 이러한 조급함을 가져왔다고 생각한다.
보다 빠르고 유연한 사고를 위해 하드스킬을 쌓아두는것도 중요하다고 생각했다.

정리

페어의 꼼꼼한 성격으로부터 많은 점을 배울 수 있는 블랙잭 미션이였다.
또한 stream의 다양한 활용방법과 도메인을 이해하는데 어떤 관점을 가져야할 지 고민해볼 수 있었다.
모던자바 인 액션을 열심히 공부하고있는 페어의 모습에서 본받을 점도 많았다.

결과보다는 과정에 몰입하는 사람이 되고자 노력할 것이다.

상대방의 의견을 수렴하기만 하는것이 아니라 반대되는 의견을 설득하는 과정에 집중해볼 것이라는 다짐을 했다.
만약 페어와 의견이 같다면 한 번 쯤은 자신이 고수하고 있던 방식이 옳은 지에 대해 의문을 가져보는 것도 좋을 것 같다.

이번 미션의 마지막 쯤 나의 모습처럼 결과 구현에 조급한 페어를 만나게 된다면 의견 차이가 생길 수도 있을텐데 이 때 어떻게 서로의 합의점을 찾아갈 수 있을지에 대한 고민도 하게 되었다.

여러모로 많은 방면으로 얻은게 많은 블랙잭 미션이었다 🃏