프리코스를 진행하며 고민한 내용들을 작성하였습니다.
작성한 README에 더 자세한 설명이 있으니 참고해주세요.

요구사항

진행한 사항

작성 전

이번 과제는 무려 오징어게임..! 원작은 한번도 본 적은 없지만 꽤나 유명하기에 곧바로 알 수 있었다.

그와 함께 지난 과제 피드백이 주어졌는데, 내가 생각하고 지켰던 것들도 있었으나 차마 알아차리지 못 한 점들이 많았다. 특히 객체를 객체답게 써야 한다는 점에 대해 많은 생각을 하게 되었고, '그동안 과제를 진행하며 느꼈던 많은 고민들이 객체를 객체답지 않게 사용했어서 그랬구나'라고 깨닫게 되었다.

또한 지난 과제에서 클래스를 분리하긴 했었으나 MVC 패턴을 지키진 않았다. 단지 분리하고 나서 MVC패턴 기준으로 나눌 수 있었기에 패키지만 분리했었는데, 해당 사항에 대해 많은 생각이 있었다. MVC 패턴은 왜 그리 유명하고, 다들 지키려 노력하는가? 너무나도 궁금하여 우테코 깃헙의 아고라 Discussion을 통해 패턴을 지킨 이유를 물었다.
개인적으로도 MVC에 대해 공부했었는데, 결론은 객체지향을 제대로 지키기 위해서였다. MVC의 구조를 지키며 코드를 작성하다보면, 객체를 객체답게 사용하게 되며 이로 인해 객체지향을 이룰 수 있던 것이다.

모든 것은 객체지향으로 귀결됐고, 이번 과제의 방향성은 당연히 객체지향을 구성해 보는 것이었다.

따라서 코드의 구성을 오랜 시간 고민했고, 지난 번보다 더 차분하게 코드를 작성했다.

코드를 작성하며

요구사항

이번엔 유독 요구사항이 많았다. 메서드 10줄 제한, 파라미터 개수 3개 제한 등.. '몸 비틀어서 코드 작성하지 말 것'으로 느껴졌다.
물론 if문, 반복문 공백 등을 최대한 제거하면서 진행할 수도 있었으나 그걸 바라는 게 아닌 것 같아 최대한 로직 자체를 단순하고 가볍게 가져갔다.

그리고 특정 클래스의 요구사항도 있었다. 일부 클래스는 패키지 변경, 메서드 추가 가능 등의 사항이 적혀있었으나 해당 사항이 없는 클래스도 있었다. 무서워서 아무것도 안건드리는 쪽으로 했다..

MVC 패턴

MVC 패턴을 사용하여 객체지향을 제대로 지켜보기로 했다. 패키지를 나눠놨으며, Model에서 Controller와 View를 참조하지 않게 매우 조심했다.
View에서도 최대한 로직을 구성하지 않게끔 했으며, Controller에서 제어할 수 있도록 노력했다.

일급 컬렉션

객체를 객체답게 사용하는 법 중, 일급 컬렉션을 만들어 사용하는 게 있었다. 게임을 진행하며 로그를 작성하고 출력하는 게 있었는데, 해당 로그를 Map과 List로 구축했다. 밖에서 접근할 수 없도록 일급 컬렉션으로 만들었고, get을 통해 데이터를 받아갈 때도 unmodifiableMap으로 변경 불가할 수 없도록 만들었다.

메서드를 나누는 기준

메서드 10줄 제한을 지키는 게 의외로 많이 어렵진 않았다. 다만 메서드를 나눌 때 어떤 기준으로 나눠야 할 지 확신이 없었는데(물론 기능을 기준으로 나누긴 했지만, 깔끔한 코드를 구성하기 위한 나만의 기준은 없었다), 이번에 코드를 만지며 조금 기준이 생긴 것 같다.

해당 메서드의 로직을 요약하되, 매끄럽게 이어지지 않으면 나누기로 했다.
예를 들어, 해당 메서드의 작동이 다른 메서드와 메시지를 나누는 부분, 스스로 동작하는 부분으로 나뉜다면 해당 메서드는 2가지의 기능을 맡는 것처럼 느껴질 수 있으니, 스스로 동작하는 부분을 하나의 메서드로 분리하여 작성하면 메시징 메서드, 로직 메서드 2개로 나눌 수 있으므로 훨씬 깔끔한 구성이 되는 듯 했다.

느낀 점

MVC 패턴을 적용하고 코드를 작성하다 보니, 해당 로직은 어떤 객체의 책임일까 등의 고민이 생기지 않았다. 객체를 객체답게 사용하면서 로직 -> 객체의 흐름이 아닌 객체 -> 로직의 흐름이 생성되었고, 그러한 방향을 지키려 노력하니 알아서 구조가 딱딱 맞춰지는 느낌이었다.

확실히 코드를 알고리즘 짜듯 마~구 작성한 후 리팩터링하는 것보단, 처음부터 좋은 구조를 지키며 작성하는 게 전체적인 시간으로 보자면 훨씬 이득인 듯 하다.
전자는 잘못 짠 로직에 대한 우왕좌왕 코드 핸들링 + 리팩터링하며 쏟을 시간까지 생각하면.. 정말 손실이 막대하니까.
그러나 처음부터 좋은 구조를 가져가려 하며 코드를 작성하다 보면, 잘못된 로직도 금방 잡아내게 되고 리팩터링도 보다 짧은 시간으로 끝낼 수 있는 듯 하다. 누군가에게 코드를 설명할 때도 의도를 명확히 얘기할 수 있게 되고 말이다.

물론 그렇다 해서 처음부터 너무나 빡쎈 구조를 잡아 동작하지 않는 코드를 만들면 안되겠지만.. 적어도 생각의 흐름을 잘 표현할 수 있게 구조를 잡고 진행하는 게 좋은 듯 하다.