개요

객체지향에 대해서 알게된지 1달밖에 안된 나... 🥲 드디어 프리코스 1주차 미션을 제출했다!
가르치는 사람이 있는 것도 아니었는데 1주일만에 정말 많은 걸 배웠다는 느낌이 들었던 1주차, 어떤 점을 고민하며 미션을 진행했는지 정리해보려고 한다!

📌 PR 링크

https://github.com/woowacourse-precourse/java-baseball-6/pull/1662

📌 이번주 목표 달성 확인

• ✅ READ.ME, ApplicationTest 코드 정독하고 시작하기
• READ.ME 공들여 써보고 기능별 commit 놓치지 말기
• TDD 기반으로 구현해보기, 테스트 어려운 코드는 테스트 가능한 코드로 바꾸는 데 시간 들이기!
• ✅ 나올 수 있다고 생각하는 모든 예외 경우 처리하기
• ✅ get 최대한 지양해 View에서만 get 쓰기
• ✅ 메소드 완성마다 이 클래스의 책임이 맞는지 고민하기
• ✅ 스트림의 여러가지 활용으로 코드 가독성 높이기!

📌 공부한 것

미션을 하면서의 구체적인 고민 과정과 땅끝까지 파고들어 공부한 내용은 여기를 봐주시길!

• [우테코 6기 프리코스] 1주차 고민 해결 과정
  
• [우테코 6기 프리코스] 우테코 제공 NsTest 들여다보기 - 2편
  
• [공부한 것] 테스트 코드 완전 써먹기!
  
• [외부글] 함수 파라미터의 final 키워드
  

🧐 한 달 전의 내가 구현했던 코드...

지금으로부터 딱 한달 전, 객체지향을 알게된지 1주일째에 동일한 숫자 야구 미션을 구현해봤었다.

• 당시 pr 링크: https://github.com/skylar1220/java-baseball/pull/1
  

불과 한 달 전 코드인데, 지금 저 코드를 보면 '내가 왜 저렇게 짰지...?'싶은 부분이 많다😂

그렇게 한 달이라는 짧은 시간동안 나름 객체지향에 대해 스터디도 해보고 혼자 공부해보면서 조금씩 알아가는 중이라고 느끼는데, 과연 나의 코드는 어떻게 달라졌을지!

🧐 도메인에서 getter를 쓰지 않기위한 발버둥

기능을 구현하기 위해 의식의 흐름으로 생각하면 자연스럽게 getter를 쓰는 구현 흐름이 떠오른다.
하지만, get 최대한 지양해 View에서만 get 쓰기기 이번주 나의 목표였기 때문에 getter를 쓰지 않으면서, 똑같이 동작하는 코드를 위해 머리를 싸맸다.

그 과정에서 시행착오도 많았다.

1. get을 최대한 지양하려고 하다보니 메시지를 보내는 방식으로 진행하게 되고,
2. 그러다 보니 메시지를 보내는 과정에서 필요한 메소드들을 만들다보니 이렇게 메소드가 늘어나게 되었다.
3. 그렇게하면 get을 쓰지 않겠다는 목적은 달성하나, 메소드들로 클래스가 복잡해지게 되는 현상 발생...😂

이 과정에서 혼자 공부를 할 때 가장 많이 드는 생각인 이 방식이 맞나라는 생각이 많이 들었다. 하지만 검색으로도 한계가 있었기에 내가 할 수 있는 건
일단 이렇게 구현해보고 마저 진행해보며 객체 분리 등으로 해결할 수 있는 시점을 찾아보자였다.

그러면서 후반부를 마저 구현하며 결국 getter를 안쓰고 메시지를 보내는 메소드들이 객체 책임에 따라 이동되고 분리되는 과정에서 메소드들의 복잡성이 낮아지게 되었고 결과적으로는 getter를 쓰지 않으면서 간략한 코드가 나름(?) 완성이 되었다.

결과적으로 생각해보니 이 모든 게 '객체지향'이라는 한가지 줄기로 닿아있다는 느낌을 받았다.

결론

getter를 안쓰려다보니, 그리고 메소드를 책임에 따라 이동하려다보니,
결국에는 자연스럽게 getter를 쓰지않고 책임이 있는 객체에서 처리가 되는 구조가 만들어졌다!

객체지향에 충실하다보니 여러 문제들이 함께 풀리는 경험! 와우!

🧐 이 기능이 이 객체의 책임이 맞을까?

'이 기능이 이 객체의 책임이 맞을까?'

이번주 구현하면서 가장 많이 고민했던 지점 중에 하나는 이것이었다.

그리고 이 고민이 시작되는 시점은 보통 이 두가지 타이밍이었다.

1. 클래스가 너무 많은 메소드를 갖고 있거나
2. (의외로) 커밋메시지를 적을 때

2번 커밋메시지를 적으면서가 의외로 객체의 역할에 대해 돌아볼 수 있는 시간이었는데 예를 들면 이렇다.

feat(GameController): 컨트롤러에 게임 승리 확인 기능 구현... 끄적끄적...
잠시만 컨트롤러에 게임 승리 확인 기능을 구현했다고?? 이게 맞아??

그러면 이제 객체의 책임을 다시 생각해보고, 분리할 수 있는 경우에는 분리하는 과정을 반복하면서 코드를 구현했던 것 같다!

🧐 궁금한 하나를 충분히 파고 들었던 시간

이번 미션을 하면서, 평소에는 '대충 이런 로직이겠거니' 하고 넘어갔던 것들에 대해 궁금한 하나를 충분히 파고드는데 시간을 투자해보자!라는 생각으로 임했다.

물론, 그렇기 때문에 금방 끝날 과정이 질문하고, 찾아보고, 이해한 과정을 글로 정리하며 몇 배가 더 걸리기도 하였다.

하지만 거기서의 얻는 점은 걸린 시간 그 이상이었다.
머릿 속에서 명확하지 않았던 것이 비로소 자리를 잡고, 앞으로도 다시는 흐릿하지 않고 명확하게 자리잡고 있을 것이라는 것이 굉장히 큰 성취감을 주었다!

대표적으로 테스트 코드 구조 분석 같은 것이 대표적으로 그러했다.
Mock과 execute등 모르는 용어들이 가득해 들춰보고 싶지 않았던 NsTest 클래스...ㅎ
하지만 3~4시간 정도를 투자해 말그대로 코드의 끝까지 파고들고, 그에 필요한 지식들을 이해하면서 정리까지 해놓아보니 완전히 내 것이 된 것 같다는 기분이 이제는 든다!

🧐 우테코 프리코스 커뮤니티

디스코드에서 프리코스 커뮤니티가 진행 중인데, 독학러인 나에겐 신세계였다!

3000여명이 들어와있는 커뮤니티라 산발적인 느낌이 있지 않을까 했지만 생각보다 질문에 대한 답도 잘 일어나고 적절한 논의가 이루어지고 있다는 느낌!

고수들이 지식을 나누는 공방전처럼 보이는 곳에는 참여할 엄두가 나지는 않지만...ㅎ
그래도 토론하기, 함께 나누기 채널도 조금씩 댓글을 남겨보면서 배워보려고했던 1주차였다!

+) 여담으로 내가 좋아하는 모먼트는 아침에 추천곡을 추천하면서 의지를 다지는 순간들🎵

📌 2주차에는?

이번주 TDD를 최대한 지키면서 해보려고 했지만 잘 안풀릴 때는 일단 구현해놓고 나중에 테스트를 몰아서했던 것 같다.. 기능별 commit도 마찬가지😂

다음주 미션이 조금 더 복잡할 것이기때문에 TDD를 지키면서 하기 더 어렵지 않을까하는 지레 걱정이 들긴하지만, 그만큼 시간을 더 들이면 뭐든 되지 않을까? 하는 생각을 한다!