[우아한 테크코스 3기] LEVEL 1 회고 (4일차)

안녕하세요? 제이온입니다.

 

오늘은 어제 빡세게 해서 그런지 예상보다 일찍 끝났습니다. 오늘은 어떠한 활동을 하였는지 회고해 보겠습니다.

 

 

데일리 미팅

오늘은 워니의 다른 조 데일리 미팅이 조금 늦게 끝나서 기존보다 5분 늦은 오전 10시 5분부터 진행되었고, 오늘의 말하기 주제는 '레벨 1 동안 무엇을 할 것인가'였습니다. 크루들은 독서, 프로그래머스 문제 풀기, 블로그 포스팅 등등으로 목표를 설정하였고, 저는 블로그 포스팅으로 결정하였습니다. 그리고 자세한 목표는 공휴일과 주말을 제외한 모든 날동안 한 일을 회고 형식으로 블로그에 글을 쓰는 것입니다. 원래부터 할 생각이었는데, 누군가에게 말을 함으로써 꼭 지켜야할 것 같네요 ㅎㅎ

 

 

자바 기초 수업

오늘은 금요일이라서 제이슨이 자바 기초 수업을 해 주었습니다. 패키지, import, 클래스와 인스턴스에 대한 내용이었으며, 몇 가지 기억에 남는 부분을 기록해 두겠습니다.

 

첫 번째로, 모든 패키지명은 소문자로 작성하는 것이 컨벤션입니다. 특히, 구글 스타일에서는 이 컨벤션을 따르며, 우테코도 이것을 지키기때문에 모든 패키지명은 소문자로 작성해야합니다. 예를 들어, 두 단어가 합쳐져도 camel case를 사용하지 않고 쭉 소문자로 써야 합니다. 저와 나봄은 패키지명이 racingcar인 것이 불편해서 racingCar로 수정하였는데, 다시 원래대로 돌려놔야겠다고 생각하였습니다.

 

두 번째로, 가장 좋은 패키지는 10개 이상의 클래스를 가지지 않는다는 것입니다. 이것은 말 그대로 모듈화가 중요하다는 것을 의미하고, 하나의 패키지에 너무 많은 일을 담당하지 않아야 한다는 의미로 이해하였습니다.

 

마지막으로, 인스턴스 필드와 클래스 필드를 구분하는 기준은 static의 유무로 볼 수 있는데, 여기서 static은 주로 util 패키지에서 사용한다는 것을 알게 되었습니다. 하지만, 여전히 저는 static의 단점을 알고 있으나 어떠한 상황에서 쓰는 것이 좋은지는 잘 모르겠습니다. 개발을 하다 보면 깨닫는 점이 있지 않을까 생각합니다.

 

 

페어 프로그래밍 - 1

수업이 약 12시에 끝나서 밥을 먹고 오후 1시부터 2시까지 페어 프로그래밍을 진행하였습니다. 어제 작성한 코드를 가볍게 리팩토링하고, 입력과 출력 기능을 아직 구현하지 않았으므로 입력과 출력을 어떻게 구현할지 상의하였습니다. 그리고 논의 끝에 MVC패턴에 따라, InputView와 OutputView로 나누어서 입력과 출력 기능을 담당하도록 설계하였습니다. 

 

입력은 총 2가지로, 자동차의 이름과 시도할 횟수를 입력받아야 합니다. 이때, 자동차의 이름은 1글자에서 5글자 사이이어야하며, 시도할 횟수는 자연수이어야 합니다.

 

 

 

 

위와 같이 자동차의 이름을 입력받을 수 있고, 잘못된 입력일 때는 에러 메시지와 함께 재입력을 유도합니다. 저는 여기서 재입력을 할 때, 위 코드처럼 같은 메소드를 호출하는 것이 아니라 while()문을 이용하는 편입니다. 하지만, while()문과 try ~ catch 문을 동시에 사용하면 indent가 2단계가 되기때문에 사용하면 안 됩니다. 이 부분에서 한 가지 배울 수 있었습니다.

 

그 외에 시도할 횟수도 입력을 받는 로직을 세우고 구현을 하였는데, 오후 2시부터 포비와의 수다 타임 줄여서, '포수타'가 있기에 팀플은 중단하기로 하였습니다.

 

 

포수타

포수타는 격주로 1번씩 진행하며, 각종 궁금한 것들을 질문하면 포비가 답변하는 방식입니다. 저는 우테코에서 생활비를 지원해 준다는 이야기를 듣고, 자세한 지원 금액이 궁금해서 질문하였습니다.

 

저 뿐만아니라 많은 사람들이 이 사항에 대해 궁금해하였고, 포비가 3월달부터 50만원 정도 생활비를 지원하며 나머지 50만원은 근로 장학을 선발하여 지급한다고 답변해 주었습니다. 저는 편도로 약 2시간 정도 걸려서 교통비와 식비가 고민이었는데, 오프라인으로 교육받아도 문제가 없기에 안심하였습니다.

 

그리고 여러 질문이 있었는데, 너무 질문이 많아서 거의 기억은 안 나고 ㅋㅋㅋㅋ 경쟁률이 백엔드는 20대1, 프론트엔드는 18대1 정도 됐다는게 인상깊었네요. OT때 백엔드만 경쟁률 들었던 것 같은데 프론트엔드도 대단합니다. 그리고 이런 대단한 크루들과 제가 함께 한다는 것이 참 운이 좋은 것 같습니다.

 

 

페어 프로그래밍 - 2

포수타가 끝나자마자 바로 나봄과 연락하여 페어 프로그래밍을 마저 진행하였습니다. 처음에 시도할 횟수를 입력받을 때, 유효성 처리를 RacingManager 클래스에서 하려고 하였으나, 자동차 이름과 시도 횟수 입력 이후 RacingManager의 멤버 변수를 자동차 이름과 시도 횟수로 초기화해 주는 방식이었기때문에 시도할 횟수에서 익셉션이 발생하면 catch가 되지 않는 문제가 있었습니다. 그래서 InputView에서 시도 횟수 유효성 처리를 같이해 주었습니다.

 

 

 

 

위와 같이 예외 처리를 하였는데, catch()에서 여러 개의 익셉션을 다룰 때에는 '|' 기호를 사용한다는 것을 알게 되었습니다. 이것을 모를 때에는 catch() 여러 개 나열하였는데, 덕분에 코드의 길이를 줄일 수 있게 되었습니다.

 

 

출력 담당인 OutputView는 정말 출력만 하는 클래스라서 어렵지 않았습니다. 다만 우승자를 출력할 때 "~가 최종 우승했습니다." 라고 출력해야하는데 이를 name + "~가 최종 우승했습니다." 형식으로 출력하는 것이 아니라, System.out.pritf("%s가 최종 우승했습니다.", name) 방식으로 출력하였습니다.

 

 

 

 

그리고 마지막으로 메인 함수 역할을 하는 Application에서는 먼저 두 개의 입력을 받고, GasStation을 정의하여 RacingManager 객체를 만든 후, 게임을 시작하여 반환값으로 RacingResult를 받아왔습니다. 그리고 여기 저장된 log과 Winner를 이용하여 출력을 하였습니다.

 

 

그런데, 나봄과 상의를 해 보니 굳이 GasStation 클래스가 필요 없다는 결론을 내렸습니다. 우리가 자동차에 연료를 넣어주지만, 주유소를 여러 군데 경유를 하는 것도 아니기때문에 GasSation은 없애고 Supplier를 이용하기로 하였습니다. 그리고 Car에도 연료를 충전하는 메소드가 있어서 GasStation을 삭제해도 무방하였습니다.

 

 

 

 

GasStation 대신 Supplier<Integer> fuel을 정의하였고, 여기에 있는 get() 메소드를 사용하여 충전할 연료를 car에 넘겨주는 방식으로 바꿨습니다. 그리고 이 fuel은 () -> RandomUtils.nextInt()로 정의하여 사용하였습니다.

 

 

 

 

근데 메인 메소드를 보면, RandomUtils.nextInt()는 커녕 이상한 new RandomSupplier()가 있는 것을 알 수 있습니다. 이것은 nextInt()의 인자로 0과 9를 넘겨 주어야하는데, 상수 처리를 Application에서 처리하는 것은 좋지 않으므로 Supplier 역할과 상수를 처리할 수 있는 RandomSupplier 클래스를 정의해 주었습니다.

 

 

 

 

이렇게 표현할 수 있다는 점이 굉장히 인상적이었습니다. 저같으면 메인 메소드에 그냥 상수를 처리하였을 것 같은데, 각 클래스마다 적절한 성격을 고려하는 나봄이 대단하다고 느껴졌습니다.

 

 

마지막으로, 테스트를 파라미터형으로 바꿔보았습니다.

 

 

 

 

기존의 코드에서는 run이 성공할 경우와 실패할 경우로 나누었는데, CsvSource()를 이용하여 파라미터 테스트를 진행하면 하나의 테스트로 run의 성공과 실패 여부를 파악할 수 있습니다.

 

또한, 자동차의 이름이 유효한지 검사하는 테스트를 추가하였는데 예외가 2가지가 있기때문에 ValueSource()를 활용한 파라미터 테스트가 적합하다고 판단하였습니다.

 

그 외에 자잘한 변수명 변경, 들여쓰기 수정, 접근 제한자 추가 등의 리팩토링을 하였습니다.

 

 

페어 프로그래밍 종료

어제 빡세게 개발을 해서 그런지 오늘은 오후 5시 정도에 개발이 끝났습니다. 처음 느껴보는 나름 만족스러운 개발이었고, 페어 프로그래밍은 종료되었습니다. 이제, 페어에게 피드백을 해 주고, PR과 리뷰어에게 리뷰 요청을 해야 합니다. 저는 나봄에게 굉장히 많은 것을 배웠기에 피드백은 당연히 긍정적인 말만 남겼습니다 ㅎㅎ.

 

PR도 적당하게 메시지를 정리해서 날렸고, 미립이라는 리뷰어 분에게 리뷰를 요청하였습니다.

 

 

 

 

후후 참고로 백엔드 51명 중에서 3등으로 미션을 제출하였습니다.

 

 

정리

이렇게 첫 번째 미션을 성공적으로 제출하였습니다. 이제, 리뷰어 분에게 1차 피드백이 오면, 저는 적절하게 수정을 해야 합니다. 여러모로 객체지향프로그래밍의 느낌을 배울 수 있었고, 단위 테스트라는 것을 경험하는 좋은 기회였다고 생각합니다.

 

저는 이제 주말동안 AssertJ의 기초를 공부하고, 미뤄 두었던 객체지향의 사실과 오해를 드디어 읽어야겠습니다. 직접 개발하면서 부족함을 여실히 느끼다보니 개발 서적에 저절로 손이 가는 것 같습니다.

 

위 미션의 코드가 궁금하신 분은 이곳을 참고하시길 바랍니다.