프리코스를 진행하며 고민한 내용들을 작성하였습니다.
자세한 코드는 해당 리포지토리를 참조해주세요.

요구사항

진행한 사항

코드 작성 전

이번에도 역시 요구사항을 읽고 기능 별로 체크리스트를 작성하였다. 단, 앞선 과정과 달리 어떤 클래스가 해당 메서드들의 책임을 질 것인가를 생각하며 진행했다.
기능들을 담당할 역할을 생각하고, 해당 객체가 역할을 잘 맡을 수 있는지를 생각하며 코드를 구체화했다.
물론 처음 계획한 구조대로 흘러가지만은 않았다. 역할이 너무 몰려있다고 생각하여 재분배를 하기도 했고, 아예 삭제하기도 했다.
그러나 지금까지는 빠른 코드 구성 -> 방대한 리팩터링으로 진행됐다면, 이번 미션은 차분한 코드 구성 -> 작은 단위의 리팩터링이 이루어졌다.
코드를 갈아엎는 정도의 리팩터링이 아닌, 일정 부분에 대해 고심하고 조금씩 바꿔나아가니 코드 작성 시간은 줄어들었으나 고민하는 시간이 많이 늘었다.

물론 고민한 것 치고는 변화가 많이 없네.. 아웃풋이 남지 않은 느낌이야라는 생각이 들기도 하고, 그만큼 아쉬움도 좀 많은 것 같지만 전체적인 그림으로 보자면 오히려 해당 방향성이 더 나은 게 아닐까 싶다. 프로그래머가 코드 작성하는 사람은 아니니까. 문제 해결이 먼저지.

코드를 작성하며

Enum

이번 요구 사항으로 Java Enum을 적용하라는 부분이 있었다. 2주차때 Enum에 대해 엄청 고민하다가 적용했었는데, 되게 반가웠다. 진짜 나올 줄 몰랐었고, 그저 다른 분들 리뷰 보다가 공부하게 된 거였는데..!
신나는 마음에 Enum을 마구 쓰다가, 이번엔 오히려 Enum에게 너무 큰 역할을 부여해버려서 추후 따로 쪼개기도 했다.
또한 Enum 내에서 검색용 Map을 만들다가 Enum 클래스의 코드 동작 순서도 알아보게 되었다. (해당 글 중후반부)

테스트 코드

또 도메인 로직에 단위 테스트를 구현해야 한다는 조건도 있었다. 도메인 로직과 비즈니스 로직에 대해 구분 기준을 잘 몰랐었는데, 찾아보다가 조금 알게 되었다. (근데 막상 돌이키니 제대로 구분을 두지 못 한 것 같아 아쉽다.)
단위 테스트를 작성하다가 테스트만을 위한 public 메서드를 만드는 게 좋은 걸까? 라는 고민이 생겨 골똘히 생각해보고, 오픈카톡방의 다른 개발자분들께도 좀 여쭤봤다. 개발자마다 다르다곤 하지만 그렇게 좋은 방향은 아닌 것 같다고 말씀해주셨고, 나도 그 의견에 동의했다.
그리고 어디까지나 작은 개발자의 견해긴 하지만, 그런 메서드를 따로 만들 정도면 제대로 기능 분리가 되지 않았거나 혹은 잘못된 방향성을 지닌 건 아닐까 생각이 들었다. 물론 내가 더 깊고 넓게 개발을 하다 보면 언제든 생각은 바뀔 수 있는 거긴 하지만, 적어도 이번 과제를 진행하며 내 자신을 돌아보니.. 그랬던 것 같다.

Exception

예외처리에 대한 것도 좀 복병이었다. 코드를 다 구성한 뒤에 테스트코드를 돌려보니, 분명 조건에서는 예외를 던져야 한다고 했으나.. 테스트 코드에서는 예외 없이 정상종료되는 상태를 가정했다.
뭔가 이상하다 싶었는데, 그 이전에 우테코에서 메일이 왔었다. 찬찬히 읽어보니 예외 발생 시 해당 메시지를 호출하고 프로그램은 정상적으로 종료되어야 한다는 뜻이 아닐까 싶었다. 즉 예외가 발생했을 때 프로그램이 터지는 게 아닌, 예외에 대한 정보를 알려주되 그에 따른 종료가 이루어져야 한다는 것이다.
따라서 Exception에 대해 알아보며, throw와 throws가 어떤 역할인지, 그리고 어떻게 하면 해결할 수 있을지 생각했다. try catch를 이용하여 프로그램에 예외가 생겼을 때 예외메시지를 출력하고 종료될 수 있도록 작업하긴 했는데.. 내 해석이 틀리면 어쩌나 하는 걱정이 있다 ㅎ..

보너스 번호로 인한 로또 2등과 3등 구분

로또 결과 중 2등과 3등을 나누는 기준에도 많은 고민을 했다.
로또는 보너스 번호를 맞췄냐, 아니냐에 따라 2등과 3등이 나뉜다. 6개의 번호 중 5개를 맞춘 상황에서 보너스 번호를 맞추면 2등, 못맞추면 3등인 것이다.
이것을 따로 분기처리만 해서 로또 순위 Enum Class 내에 맞춘 번호 갯수만 들고 있게 할건지, 보너스 번호를 맞춘 것까지 둘건지.. 굉장히 많은 고민을 했다.
헌데 Enum 클래스만을 봤을 때, 맞춘 번호 갯수만 구현하면 2등과 3등을 어떻게 구분할 지 아무도 모를 것 같았다. 기존 로또에 대한 지식이 있는 사람이야 알겠지만, 만약 내가 따로 만드는 게임이거나 혹은 로또에 대해 잘 모르는 사람이 봤을 땐 코드만 보고 이해할 수 없을 것 같았다. 또한, 검색용 Map을 만드는 데에도 제약이 있다고 느껴져서 보너스 번호에 대한 정보도 추가하였다.
어떤 게 옳은 방식인지는 아직까지는 모르겠다. 헌데 만약 로또에 등수가 추가되고, 보너스번호에 대한 등수 판별 규칙등이 따로 제정된다면 지금과 같은 구조가 훨씬 유연하게 대처할 수 있을 것이다.

Lotto 클래스와 로또 번호

기존 제공된 Lotto 클래스 때문에 혼란도 겪었다.
로또 번호들과 보너스 번호는 모두 로또의 규칙 내에서 선택되어야 한다. 1부터 45까지의 숫자며, 서로 중복이 없어야 한다.
그렇다면 로또 번호 객체를 만들고, Lotto 클래스와 당첨 로또 클래스에서 로또 번호 클래스를 이용하는게 더 낫지 않을까? 싶었으나.. 괜히 Lotto 클래스를 건드렸다가 요구 조건에서 벗어날까봐 전전긍긍했다.
결국 로또 번호를 검증하는 역할을 로또 규칙 Enum 클래스에 선언했고, Lotto 클래스와 당첨 로또 클래스에서 가져다 쓰는 방식으로 해결했다. 잘 한 건지는 모르겠다.
헌데 로컬 브랜치로 자료구조를 직접 변경하는 방식으로 했더니, 이것저것 신경 쓸 게 많아졌다. 기존 테스트 코드에서 벗어나지 않아야 하고, 다른 자료 구조들도 해당 형식에 맞게 변경해줘야 했다. 음.. 그렇다고 명확성이 증가된 느낌은 딱히 들진 않아서 우선 건드리지 않고 구현하는 방향으로 했다. 오히려 몸을 비틀며 코드를 작성하는 느낌..

아쉽지만 적용하지 못 한 MVC

MVC 구조를 적용해볼까 했으나, 해당 기준으로 패키지만 구분해뒀다. Enum같은 경우는 깊은 고민을 바탕으로 선택하게 된 적절한 이유가 있었으나, MVC를 무턱대고 도입했다간 해당 패턴의 장점과 사용 이유에 대해 설명하지 못 할 것 같았다. 전처럼 머리 비우고 코드를 작성하게 될 것 같아서 이런저런 글을 보며 고심만 했다.. 결국엔 이거다! 하는 느낌을 받지 못 했다 ㅠ.. 다음 번 과제가 많이 어렵다면, 고민을 기반으로 적용하게 되지 않을까 하는 기대가 있다. 우선은 이번 코드에 대한 피어 리뷰를 나누며, 다른 분들과 많이 대화하고 배워보려 한다.

느낀 점

역시, 글 양으로도 지난 주차보다 적은 것 같다. 진짜 고민 많이 했는데.. 제일 많이 반복한 코드가 git reset --hard일 것 같은데.. 이거 적어보고 저거 적어보고 되돌리고 리드미에 고민 써내려가고..
코드에서 그 고민이 좀 보였으면 싶다 ㅠ..

그래도 뭔가 성장하고 있는 것 같다. 전에는 코드만 와다다다 쳤다면.. 지금은 코드가 좀 무거워진 느낌? 고민하고 작성하는 과정의 반복이다 보니, 왜 이런 구조를 선택했어요? 하면 어느 정도는 얘기할 수 있을 것 같다.

피어 리뷰가 좀 떨린다. 다른 분들은 어떻게 했을지 궁금하고.. 내 코드의 부족함을 많이 알고 싶기도 하다.

계속 해서 성장할 수 있기를..!