[우아한테크코스] 4주차 체스 회고

3인 페어

 

이번 체스 미션에서는 3인 페어를 하게 됐습니다.

 

항상 3인 페어 얘기가 나올 때, "난 안 걸렸으면 좋겠다"라는 생각을 했습니다.

왜냐하면 의견이 많아지면서 더 힘들어질 것 같기 때문이었죠. 하지만 이번 미션은 저의 이러한 생각을 바꾸게 된 계기가 됐습니다.

 

3인 페어가 더 힘들지 않고 재밌습니다. 다양한 의견을 들을 수 있어서 재밌었고, 2명이 얘기할 때 쉴 수도 있습니다,, ㅋㅋㅋ

그리고 한 명 더 있기 때문에 아이디어가 +1 됨으로써 접근방법이 1개 늘어나게 됩니다.

 

운이 좋게도 이번에 같이 한 페어들이 모두 좋았습니다. 한 분은 항상 밝아서 긍정 에너지를 뿜었던 분이었고, 다른 한 분은 아이디어 뱅크였습니다. 그래서 그런지 이번 체스 1, 2단계 미션은 빠스 탔던 것 같기도 하고,,?

 

다만 힘든 점은 체스 미션 난이도가 이전 미션들에 비해 급상승된 느낌이었습니다,, 벨붕 + 멘붕

그래서 "구현 실력이 아직 많이 부족하구나"를 느낄 수 있었습니다,, 나중에 다시 한번 체스 미션을 해봐야겠습니다.

 

아무튼 나중에 "너 3인 페이할래? 2인 페어할래?"라고 물어본다면 고민하지 않고 3인 페어라고 당당히 말할 수 있습니다.

그만큼 너어어ㅓㅓㅓㅓ무 재밌었고, 좋은 경험이었습니다.

 

설계에서의 실패

 

체스 미션을 하면서 '오브젝트'를 읽었습니다. 그리고 시간이 지날수록 저의 객체지향 세계가 완공되진 않더라도 어느 정도 감은 잡았다(?) 정도였습니다.

 

블랙잭 회고에서 적었듯이 '객체지향의 사실과 오해(이하 객사오)' 책을 다 읽고서부터 미션을 진행할 때 객체지향적인 설계를 하기 위해 노력하고 있습니다.

 

그래서 바로 미션에 들어가기 전에 설계를 했죠,, 블랙잭 미션에서 자신감이 차있던 탓인지 설계가 빠릿빠릿하게 됐습니다. 그만큼 더 정확히 더 자세히 작성하면서 설계에 시간을 많이 쏟았습니다.

그러고 나서, "와 설계 잘했다. 절대 바꾸지 말자"라는 하지 말아야 할 생각을 했습니다.

구현을 시작하는데 "어, 이게 아닌데? 왜 이렇게 조건이 많지?" 등 많은 벽들을 부딪혔습니다.

 

근데 일단 "설계는 맞으니까 구현에 문제가 있을 것이다"라는 아주 버릇없는 오만한 생각을 하게 됩니다.

이때부터 시그널이었는지 점점 구현의 구렁텅이에 빠지면서, 처음 설계에 머리가 굳어지게 됐습니다.

결국 네오가 시간을 늘려주지 않았다면 제시간에 완성하지 못한 일이 벌어졌죠,,

 

 

반성

 

미션을 제출하고 "왜 시간 내에 구현하지 못했을까?"에 대해 반성했습니다.

 

일단 첫 번째 원인으로는 절대 가지지 말아야 할 생각을 가졌습니다. 그 오만함과 자신감이 화를 불러일으켰죠,, 

그래서 초심을 찾기 위해 다시 객린이로 돌아갔습니다.

 

두 번째는 설계에 너무 많은 시간을 쏟았다는 것입니다.

도메인의 이해가 빠삭하면 설계가 더 자세하게 되고, 객체지향적인 설계에 도움이 된다고 했습니다.

하지만 그 반대라면 일단 먼저 구현을 해보고, 거기서 다시 설계를 고치고, 왔다 갔다 하는 식으로 진행하는 게 괜찮다고 느꼈습니다.

 

이번 체스 미션에서는 이 부분을 간과했죠,, 체스 구현은 많이 복잡하고 어렵기 때문에 아무리 설계를 잘했다 하더라도 그건 잘한 게 아니었습니다. 그래서 설계를 하고 구현을 좀 하다가 벽에 부딪히면 다시 설계하는 방식으로 진행했어야 했습니다.

 

아직 훈련이 덜 됐기 때문에, 설계 == 코드로 이어지지 않았습니다. 아무리 설계가 중요하더라도 구현을 통해서 직접적으로 얻을 수 있는 부분도 있기 때문에 도메인의 이해가 부족하다 생각 들면 구현 <-> 설계를 왔다 갔다 해보는 것도 좋은 방법이라 생각합니다.

 

그래서 3,4단계 미션이나 레벨 2에서 "무조건 설계 제대로 하고, 구현 들어가야 해!!"라는 의견을 접어보려고 합니다,,

처음 설계를 '정확'과 '대충'이라는 경계에서 아슬아슬하게 왔다 갔다 하며 구현을 통해 단단한 설계를 해보려고 합니다.

 

실패를 발판 삼으며 성장

 

체스 3단계는 점수를 계산하고, 4단계는 체스 게임을 저장하기 위해 DB 연결을 하는 미션이었습니다.

1, 2단계에서 반성했기 때문에, 이번 미션을 진행할 때는 구현 <-> 설계를 왔다 갔다 했습니다.

 

처음엔 전과 같이 요구사항을 정확하게 했습니다.

하지만 설계에서 변화가 있습니다.

처음에는 메시지 위주로 큰 단위로 설계했습니다. 그리고 간단하게 구현했죠.

당연히 실패했습니다. "왜 실패했을까? 뭐가 부족했을까?"라며 설계를 다시 고쳤습니다.

 

한두 번 설계와 구현을 왔다 갔다 하니 아래의 사진과 같이 깔끔한 최종 설계가 나왔습니다.

객사오 책에서는 '구현과 퍼블릭 인터페이스를 분리하라'라고 나옵니다.

처음에는 "설계에서는 구현을 생각하지 마!"라고 이해했지만 이러한 뜻이 아니었습니다.

 

당연히 메시지를 먼저 생각하는 건 맞습니다. 메시지를 생각하면서 구현을 아예 생각하지 말라는 게 아닌, "구현 == 메시지라는 오해를 하지 말아라"는 뜻인 것 같습니다. 그래서 메시지를 통해서 객체에게 적절한 책임을 할당할 수 있고, 진정 객체가 자율적으로 판단하고 행동하는 '객체지향'이 됩니다.

 

 

일급 컬렉션의 힘

 

3단계 미션의 요구 사항은 체스 점수를 합산해야 합니다. 그리고 미션을 진행하면서 일급 컬렉션의 힘을 한번 더 느낄 수 있었습니다.

 

체스 점수를 합산하는 데에 있어서 Pawn의 특별한 요구사항이 있습니다. 그래서 저는 '열'을 기준으로 하나의 일급 컬렉션을 만들고, 그 일급 컬렉션들을 가지고 있는 점수 계산하는 객체가 있습니다.

 

public class ColumnPiece {

    private final List<Piece> pieces;

		//...
}

public class BoardScore {

    private final List<ColumnPiece> columnPieces;

		//...
}

 

이렇게 일급 컬렉션을 통해 행위를 한 곳에서 관리하기 때문에

'BoardScore'에게 "점수를 계산해 줘"라는 메시지를 보내고,

'ColumnPiece'에게 "열마다 점수를 계산해 줘"라는 메시지를 보낼 수 있습니다.

 

이로써, 객체들에게 최소한의 책임이 할당되고, 나중에 점수를 구하는 요구사항이 변경된다면 주저 없이 ColumnPiece로 찾아서 수정할 수 있습니다.

또한, '열' 단위로 행위를 하게 된다면 ColumnPiece에서 또 하나의 메시지를 받을 수 있게 할 수 있습니다.

 

처음에 일급 컬렉션에 대해서 학습했을 때, 많은 장점들을 느끼지 못했습니다.

하지만 우테코에서 미션 진행하면서 장점들을 하나씩 배울 수 있어서 기분이 좋습니다.

항상 학습할 때 몸으로 느끼지 못하면 와닿지 않았는데, 미션을 통해서 몸소 느낄 수 있기 때문에 왜 중요한지, 왜 사용하는지 정확하게 이해할 수 있었습니다.

 

 

객체지향 세계가 무너지는 느낌

 

4단계 미션에서는 Database 도입을 해야 합니다.

Repository가 생기고, Repository에 접근하기 위해 Service가 생기며, Controller에서 Service를 사용합니다. 그리고 최대한 Service는 Domain을 의존하게 되죠.

 

이런 규격화된 구조가 생기고부터 레벨 1 때 쌓았던 객체지향 세계가 무너지는 듯한 느낌을 받았습니다.

기존에는 Controller가 있고, domain들과의 상호작용을 통해서 비즈니스 로직이 이뤄졌지만 controller -> service -> repository로 가면서 절차지향 느낌이 강해졌습니다.

 

이러한 고민들을 꽤 오래 했습니다. "나중에 JPA를 도입하게 되면, 이보다 더 객체지향 세계가 무너지게 되고, 데이터 중심적인 설계로 변하지 않을까?"

 

이 부분을 리뷰어님에게 여쭤보면서 많은 얘기를 나눴습니다.

 

"과연 객체지향 세계가 무너지는 게 맞을까?"라는 결론이 나왔습니다. controller, service, repository는 그런 역할을 하는 얘들이고, "Domain 안에서만 우리가 훈련했던 객체지향 세계를 만들면 되지 않을까?"라고 생각했습니다. 또한, 3 계층에 의해 도메인이 변경됐다면 설계에서부터 문제가 있지 않을까라는 의심을 할 수 있습니다. 왜냐하면 도메인은 최대한 변하지 않는 것으로 의존성이 도메인으로 향해있어야 하기 때문이죠.

 

그래서 결론은 "상관없다, 무너지지 않는다, 이러한 생각을 통해 나만의 정의를 잘 내리며 코딩하면 된다"를 느낄 수 있었던 좋은 고민거리였습니다.