프리코스를 진행하며 고민한 내용들을 대략적으로 작성하였습니다.
더 자세한 내용들은 제출한 Github 리포지토리 README 및 커밋메시지를 확인해주세요.

참가한 이유

이런저런 면접을 탈락하며, 내가 아직 많이 부족한 프로그래머라는 걸 알게 되었다. 어쩌면 내가 그토록 피하려던 코더의 길을 좇고있던 건 아닐까 싶었다.

탄탄한 개발자로서 다른 사람들을 웃게 만들어 주겠다던 호언장담과 달리, 난 굉장히 급급하게 개발해왔다. 기초가 아닌 기능을 바랐으며, 막상 내 프로젝트들의 내부 상태나 동작원리 등에 대해 설명할 수 없었다.

탄탄하고 안정적인 서비스를 개발할 수 있는 사람은 어떠한 인재들이며, 어떠한 방향성과 신념을 지닌 채 맡은 일을 수행할까.
내 모든 경험들을 무너뜨리더라도, 다시 올바른 방향으로 쌓아올리고 싶었다.
그렇게 우테코를 신청하고, 프리코스를 시작하게 되었다.

알고리즘 문제, 그러나

이걸 원하는 게 맞을까?

1주차는 총 7문제로, 그동안 겪어왔던 알고리즘 문제들과 대동소이했다. 평소 푸는 것처럼, 빠른 시간 안에 결과를 내려는 코드를 작성했다면 금방 해결했을 것이다.
하지만 일주일이라는 시간이 주어졌기에, 이 과정에서 무엇을 도전해보면 좋을 것인가라는 생각으로 이틀정도를 고민했다. Slack에 나와 같은 생각을 하신 분들이 보였고, 주로 4기의 프리코스 룰을 따라가려 하시는 듯 했다.
1주차 이후부터는 해당 룰이 적용될 것이라 예상했고, 그렇다면 미리 작성해보며 익숙해지는 게 좋을 것 같았다.

생각보다 어려운 규칙

잘 할 수 있을 거라 생각했지만, 만만치 않았다.
들여쓰기는 1 제한, 하나의 메서드는 하나의 기능을 담당하여야 한다는 부분이 굉장히 지키기 힘들었고, 많은 고민을 하게끔 했다.

우선 기능을 쪼개는 것 자체가 쉽지 않았다. 문제를 보며 이런 흐름을 가져가면 되겠지는 읽을 수 있어도, 하나씩 정의를 내리자니 어디부터 어디까지를 쪼개야 하며, 어떻게 구성해야 할지 상당히 헷갈렸다.

이게 맞나?

어색함을 무릅쓰고 조금씩 조금씩 구현해보았는데, Java에 대해 익숙치 않아서 그런지 Problem 클래스 안에 static 메서드만 죄다 추가하는 방향으로 진행하게 되었다.
그러다 보니 해당 메서드명을 아무리 이쁘게 지었어도 문제를 해결한다는 느낌이 들지 않았다. 그저 인풋값을 함수에 넣어 정제하는 과정이 반복되는 듯 했다.
메서드명도 굉장히 애매하게 작성한 부분이 많았다. 적절한 영단어를 찾지 못 해 번역기를 여러번 돌려보기도 하고, 메서드 내부 로직과 반환값 중 어떤 걸 기준으로 메서드명을 지어야 할 지 혼란스러웠다.

그러나 6번 문제를 푸는 도중 조금씩 감이 잡혔던 것 같다. 메서드명이 전체적인 로직을 포괄할 수 있도록 하되, 다른 메서드의 입장 혹은 다른 프로그래머의 입장에서 봤을 때 결과적인 내용을 내포해야 한다면 해당하는 이름으로 작성했다.
특정값의 제곱을 거쳐 사용자의 점수를 반환하는 메서드를 가정한다면, 내부 로직은 특정값의 제곱이지만 결국 사용자의 점수를 반환하는 행동이기에 getScore의 이름을 정의하였다.
그렇다고 특정값의 제곱을 버려서는 안됐다. 이는 결과를 얻기 위한 로직이기에, 따로 메서드로 빼내어 작성하고 메서드명을 해당 로직에 맞게 작성하는 방식을 채택하였다.

클래스로 작성해 보자

7번 문제를 풀다 클래스를 사용하면 좋을 것 같다란 생각이 들었다. 영한님의 강의를 듣다 알게 된 것이었는데, playGame(), stopGame(), resetGame() 등 무언가의 행동을 정의하는 함수들은 Game이라는 객체를 만든 후 내부 메서드로 play(), stop(), reset()을 정의하면 Game.play(), Game.stop(), Game.reset() 등 가독성 향상 및 손쉬운 관리를 할 수 있다고 말씀하신 게 기억났다.

따라서 7번 문제는 두 클래스를 선언한 후 solution에 정의하여 코드를 돌릴 수 있게끔 하였다. 끝내고 보니 이해하기에 나쁘지 않았던 것 같아 이후 다른 문제들 모두에 클래스를 선언하여 코드를 구성할 수 있도록 리팩터링했다. 해당 과정에서 메서드명을 조금 더 명확하게 가져갈 수 있었다.

그렇게 한바퀴 돌고 나니, 세상 이뻐보였던 7번 문제도 매우 불편했다. 두 개의 클래스로 나뉘었지만 하나의 클래스가 다른 하나에 종속된 형태였기에, 하나의 클래스로 만들고 좀 더 자연스런 메서드명을 가져갈 수 있게끔 했다.

물론 어떤 방식이 더 올바른지 아직까진 모르겠지만, 적어도 내 불편함을 계속 줄여나갈 수 있는 방법을 찾았다.

느낀 점

기존에 많은 고민 없이 구조를 구성하고, 메서드를 작성했다는 걸 깨달을 수 있었다. 가장 최근 프로젝트를 살짝만 열어봐도, 기능 분리는 고사하고 메서드명도 통일되지 않은 채 제멋대로 작성된 걸 확인할 수 있다. 코드 재사용이 아닌 복붙이 대부분이고, 내 자신에게도 혼란함을 주는 형태이다.. 리팩터링을 정말 제대로 수행하여 깔끔하고 가독성있는 코드를 지니게끔 해야겠다.

또한 Java를 제대로 다루지 못 하는 것 같다고 느껴졌다. 하긴 다 어깨 너머로 보고 따라친거니.. 여자친구에게 빌려온 Java의 정석을 적극 활용하여 2주차에는 이번보다 더 퀄리티있게 작성하고 싶다.

고작 한 주 했을 뿐인데, 벌써 많은 것들을 얻은 것 같다. 자꾸 욕심이 난다. 정말 제대로 해보자..!