1단계
1단계 PR
1단계는 페어 프로그래밍으로 진행을 했다. 이전 미션 자동차경주 미션에서는 온보딩 팀 내에서 페어가 배정되었는데, 이번 미션에는 정말 쌩랜덤으로 배정이 된 듯하다. 내 페어는 코코닥이었다. 여기 저기 돌아 댕기면서 여러사람과 인사를 나눴다고 생각했었는데, 처음 보는 크루였다.
의견을 거리낌 없이 주고받기 위해 말을 놓고 편하게 지내자는 제안을 했다. 흔쾌히 승낙을 해준 코코닥과 의견을 나누며 기능구현을 시작했다.
새로만난 페어와 나는 코딩스타일이 많이 다른 편인듯 했다. 페어는 설계 부터 꼼꼼히 차근차근 진행하는 편이었고, 나는 머릿속으로 대충 그림을 그려놓고 코드부터 작성하는 편이다. 이제껏 내 방식에 의문을 품은 적이 없었는데, 페어프로그래밍을 진행하며 설계의 중요성을 깨닫게 되었다. 다음 미션 부터는 설계 단계에 조금 더 품을 들이려고 한다.
1단계에서 페어프로그래밍을 하며 스스로에게 반성할 점을 많이 느끼게 되었다.
가장 크게 의견이 갈렸던 부분은 출력을 위해 View에다가 어떠한 방식으로 데이터를 전달해 줄 것인가였다. 페어의 의견은 "DTO를 만들어서, 객체의 정보를 전달하자" 였고, 나의 의견은 "DTO는 과한것 같다. 객체내부에 필요한 정보가 있으니가 메세지를 전달하고 출력형식에 맞게 변환하여 View에다가 던져주자." 였다.
나는 사실 내 의견을 굽힐 생각이 1도 없었다. 미친놈인거 같다. 속으로 '어떻게 설득시키지...' 라는 생각 밖에 안하고 있었다. 그런데 페어가 "합의점을 찾아보자." 라는 제안을 했다. 그때를 생각하면 얼굴이 화끈 거린다. 내 의견이 맞다는 편협한 사고에 사로잡혀 어떻게든 페어를 구슬려 보려는 내 스스로가 부끄러웠다. 페어덕에 서로가 만족 할만한 합의점을 찾아 기능구현을 했다.
이것 외에도 반성할 점이 한가지 더 있다. 비즈니스 로직을 구성하는 걸 좋아하는 편이다 보니, 한번 흐름을 타면 무아지경으로 코드를 작성하는 경우가 종종 생긴다. 이번에 페어프로그래밍을 하면서도 나도 모르게 너무 빠른 속도로 코드를 작성했었나 보다. 후일 페어와 회고를 진행하면서, 내가 작성하는 속도를 따라가지 못해 힘들었다는 피드백을 받았다. 앞으로는 내가 어떤 작업을 하며, 왜 이런식으로 하는지에 대한 것을 페어와 공유하며 코드를 작성해야겠다.
1단계 PR을 통해 궁금했던 점들에 대해 리뷰어에게 질문을 남겼다. 리뷰어는 정답을 알려주기 보단 이러한 부분에서 고민을 해보면 좋을 것 같다. 라는 방향성을 제시해 주었다. 그 중에서 가장 오랫동안 고민했던 getter 의 사용범위에 대한 고민은 따로 포스팅을 하였다. 스스로의 생각을 정리 할 수 있어서, 앞으로도 미션을 진행하며 고민하고 그것에 대한 스스로의 의견을 정리해보려고 한다.
2단계
1단계 미션은 사다리를 만들고 출력하는게 전부였다. 그리고 2단계 미션은 그렇게 만들어진 사다리를 게임을 진행하고 결과까지 출력하는 기능을 구현해야했다.
이전에 코테를 준비하며 사다리게임과 비슷한 문제를 푼적이 있다. 덕분에 사다리 게임에 대한 결과를 가져오는 것은 그리 어렵지 않았다. 다만, 기존에 알던 풀이를 어떻게 객체지향적으로 적용하는가가 문제였다.
나는 사다리에게 시작점을 알려주면 끝나는 지점을 알려주는 책임을 부여했다. 이 부분에 대해 다른 크루들과 얘기를 나눠보았는데, 플레이어가 사다리를 타고 이동한다라는 느낌으로 구현한 크루들이 제법 많았다. 현실세계와 비교해보면 당연한것 처럼 여겨진다.
객체지향을 처음 공부할 때 흔히 접하게 되는 문장이 있다.
객체지향이란 현실세계를 객체라는 관점으로 소프트웨어로 옮겨오는 패러다임
나 역시 객체지향을 처음 공부할 때는 위와 같이 생각했다. 그리고 객체지향 프로그래밍을 하면서 날 가장 힘들게 했던 것도 위의 문장이었다.
(특히 프리코스)
사다리게임을 예로 들어보자. 현실세계에선 당연하게도 사람이 사다리를 타고 이동한다. 사다리에게 시작점을 알려준다고 해서 사다리가 스스로 끝나는 지점을 알려주는 일 따윈 결코 일어나지 않는다. 이러한 관점에서는 플레이어가 사다리를 타고 이동하는 방식으로 구현하는 게 너무나도 당연해 보인다.
하지만 나는 사다리에게 책임을 부여했다. 최근에 객체지향의 사실과 오해(a.k.a 토끼책)를 재밌게 읽고 있는데, 이 책의 초반부를 읽으며 내가 객체지향을 오해하고 있었구나 라는 걸 깨달았다. 이 책의 내용에 의하면, 객체지향은 현실세계의 모방이 아니다. 현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다. 이러한 시각으로 보자면, 사다리게임의 사다리 역시 시작점을 알려주면 끝점을 알려주는 일 정도는 능동적으로 할 수 있지 않을까? (반박시 니말이 맞음;;) 무튼 나는 이러한 관점에서 전체적인 흐름을 잡았다.
기존의 코드(1단계)는 2단계를 전혀 고려하지 않고 만들어진 상태였기 때문에 전체적인 구조를 조금 수정해야했다. 그래도 뇌내코딩이 되어있던 상태다 보니 그렇게 오래 걸리지는 않았던거 같다. 수요일 오후 늦게 PR을 날릴 수 있었고, 툐요일 오후에 리뷰를 받았다.
리뷰를 통해 utils 패키지 또는 클래스의 역할과 equals와 hashcode 를 재정의하여 동등성을 부여하는 방법에 대해 알게 되었다. 위의 내용을 블로그를 통해 내용을 한번 정리해볼까 한다. ..언젠가는 미래의 내가 할거다..아마도..
List 구현
사다리게임 미션 도중 ArrayList와 LinkedList를 직접 구현해보는 미니미션이 추가되었다. 이름만 미니미션이지 별로 미니하지 않았다. ArrayList는 진짜 숨쉬듯이 쓰니까, 그닥 고민이 없었다. 반면, LinkedList는 거의 초면인 상태라 구현하는데 조금 애를 먹었는데, 이를 통해 새롭게 배운 내용이 있어서 제법 값진 시간이 된 듯하다.
우테코 믿지말라더니 믿음직하다 아주.
댓글