우테코 프리코스 백엔드 6기 (2023) 1주차 회고 (숫자야구)

서론

예.. 어쩌다보니 우테코를 하게 되었습니다.

원래는 재직 경험이 있는 사람은 안 뽑는 거로 알고 있었는데, 이번에 보니까 재직 경험이 있는 사람도 뽑기는 하더라구요.

 

아직 3학년이니 졸업까지는 1년 남기는 했지만, 동기 분께서 올해도 내년도 안 될 수도 있는데 매년 도전해봐야지 라고 하셔서 저도 그 말에 확신을 얻고 지원했습니다.

 

좀 뭐하긴 하지만 우테코 분들이 짜시는 코드를 요새 많이 참고를 하고 있습니다.

우테코에선 이런 식으로 프로젝트를 진행하는데, 그 프로젝트의 코드들이 굉장히 수준급이더라구요.

https://github.com/woowacourse-teams/2023-team-by-team/tree/develop

GitHub - woowacourse-teams/2023-team-by-team: ✨쉽고 간단한 팀플 플랫폼, 팀바팀✨

 

그래서 코딩하다가 막힐 때마다 이 분들은 어떻게 짜셨나~ 하고 참고를 많이 하고 있습니다.

 

암튼 그랬어서 우테코는 고수만 뽑는 줄 알았는데, 과정을 준비하면서 보니 그런것 만은 아니더라구요.

 

우테코 프리코스 1주차 미션

우테코의 프리코스 1주차는 너무 유명한, 숫자 야구입니다.

전 개인적으로 예에전에 next step에서 '자바 플레이그라운드 with TDD, 클린코드'라는 강의를 수강(하다 만) 적이 있어서요. 사실 한 번 경험해본 적 있는 코스입니다.. 만

https://edu.nextstep.camp/c/9WPRB0ys/

플레이그라운드

 

그래도 이전에 해봤을 때보다 실력이 많이 늘었기 때문에 그 때보단 훨씬 나은 코드를 작성해야겠다는 마음과 함께 도전을 시작했습니다.

 

시도해본 것

요구사항 정리

역시 가장 어려운 건 요구사항을 작성하는 부분인 것 같습니다.

원래는 사실 코딩할 때마다 그냥 생각나는 대로 짐승의 본능을 믿고 마구 짰었는데, 새로운 마음으로다가 우테코를 신청한 거니 열심히 작성해봤습니다.

 

확실히.. 확실히 "이제 뭐 짜지?" 하고 막히는 부분이 좀 적었던 것 같습니다.

 

 

TDD

책은 이전에 봤지만 정작 적용은 못 해봤던 TDD도, 요구사항 명세가 있으니 큰 맘먹고 도전해봤습니다.

 

하지만 역시 뭔가 뭔가 손에 안 익습니다. 그래도 확실히 TDD를 하는 것이 좋기는 하다고 느낀 것이, 내가 무슨 클래스를 만들어야 하는지에 대해 계속 고민하게 됩니다.

 

생성자 파라미터로 뭘 넣어야하지? 함수의 결과로 뭘 반환해야 하지? 이런 생각을 꾸준히 하게 된달까요.

 

VO에 record 쓰기

VO인 클래스를 record로 구성해봤습니다. 확실히 편하긴 합니다 record.

 

사이드 프로젝트 하고 있는 것에도 DTO로 레코드를 아주 야무지게 쓰고 있습니다.

하지만 VO로 써보는 건 처음인데요. 할만한데요?

 

헉..!

근데 또 나중에 찾아보니 아까 위에 적어뒀던 '팀바팀' 형누나들은 코딩 컨벤션으로다가 레코드는 dto에서만 사용하자고 적어놓으셨더라구요.

왜지? 이유가 있을까? 고민을 아주 살짝 해봤습니다.

VO는 멤버 변수의 getter를 꼭 전부 만들 필요가 없어서 그런걸까요? 뭐 그런 이유가 있었겠지 싶어서 넘어갈라고 합니다.

 

스프링 아키텍처 따라하기

스프링이 워낙 잘 만들어진 프레임워크이고, 이 숫자야구 게임에서도 MVC 패턴을 적용하면 좋겠다 싶었습니다.

그래서 스프링의 아키텍처를 좀 따라해보려고 했습니다.

 

근데 또 뭐 굳이 빈 만들고 이런 정도까지 따라할 건 없을 것 같아서, 그냥 디렉토리 구조랑 코드 생김새만 따라했습니다.

사람이 역시 익숙한게 손에 익더라구요

 

 

아쉬운 점

input / output에 테스트 적용하기가 어렵다

이거 테스트 어케 함?

스프링 MVC는 컨트롤러로 http request가 들어오고, http response를 주는 식으로 Input/output이 일어납니다.

그래서 @MockMvc같은 걸로 입출력에 대한 테스트가 가능합니다.

 

하지만 숫자야구는 순수 자바에 콘솔로다가 조작하는 게임이다보니, Scanner와 System.out으로 입출력을 합니다.

이런건 테스트를 어떻게 작성해야할지 조금 곤란하더라구요.

 

지금 생각나는 건 이 클래스가 입력도 받고 valid도 체크하니 SRP 위반이라서 그런건가 싶긴 하네요. 암튼 입출력 테스트는 어렵습니다.

 

 

랜덤에 대한 테스트가 어렵다

랜덤은 역시 '제어할 수 없는 코드'에 속한다. (참고: https://jojoldu.tistory.com/674 )

 

실행하면 1~9 사이의 숫자를 뽑는 코드가 있다고 할 때, 어떻게 테스트 해야 할까?

사실은 이 코드가 1~10의 숫자를 뽑는 코드였다고 하면, 여러번 실행을 해도 어떨 때에만 테스트가 실패할 것이다.

 

이런 함수는 어쩔 수 없이 정말 무결한 테스트는 포기하는 것이 옳은 것일까.. 하는 생각을 조금 했다.

 

 

들여쓰기 depth를 최대 1로 줄이기가 어려웠다

객체지향 생활체조 원칙에 따르면, 들여쓰기 depth를 최대 1로 할 수 있다면 좋다고 한다.

그리고 이는 메소드와 클래스를 분리함으로써 얻을 수 있다..

 

하지만 이렇게 반복문과 그 안의 '해당 함수에서만 유효한' 조건문을 처리해야 좋을지 모르겠다.

이 코드는 if문 부분만 따로 메소드 추출할 시 문제가 발생할 것이다. 그렇다면 어떻게 해야하는 걸까?

 

또 이런 식으로 해당 반복문에 종속적인 코드가 들어있을 경우도 좀 곤란하다.

if문을 다른 메소드로 추출하면 저 break는 생명력을 완전히 잃게 된다.

 

흠.. 어떻게 했어야 하는걸까

 

정리하며

결국 일단 많이 코딩 실력이 늘었다고 생각했지만 아직도 부족한 점이 많은 것 같다.

일단 이번 프리코스에서는 TDD, 테스트 코드 작성과 요구사항 먼저 적기에 대해 많은 노력을 해보는 시간으로 가져가 보고 싶다.

 

2주차 미션이 기대된다.