1주차 - 숫자 야구 게임 만들기

미션 구현

https://github.com/injoon2019/java-baseball-precourse/tree/injoon2019

사실 숫자 야구를 구현하는 것 자체는 그리 어렵지 않다. 단순히 구현을 하고 끝낸다면 내가 배울 수 있는 것은 작을 것이다. 하지만 여기서 과하게 다른 것들을 적용하여 첫 주차에서 꼭 학습하고 가야할 것을 놓치는 것 역시 주의해야 한다고 생각했다.

그래서 우선은 이번주의 메인 목표인 메서드를 분리하는 것 위주로 집중 해보기로 했다. 또한 자바 코드 컨벤션을 지키기 위해 문서를 읽어보고 인텔리제이에서 세팅 을 해주었다.

재밌는 것은 작년 이맘때쯤 인텔리제이에서 구글 자바 스타일을 적용하는 방법 을 찾아보고 글을 썼었다. 당시 처음 블로그를 시작할 때 많이 망설였다. 아는 것도 없는데 할까말까. 1년이 된 지금은 굉장히 잘한 선택이었다고 확신한다. 블로그에 정리를 하면서 나도 학습이 많이되고 내가 생각하던 것보다 다른 사람들에게 도움을 주고 있는 것 같다.

인덴트의 depth가 2까지만 허용된다는 구체적인 지침은 메서드를 나누는데 좋은 기준이 되었다.

예를 들어 공들을 비교하는 함수에서 공들이 ArrayList로 있으니 for문을 통해 반복문을 한번 돌고 if 문이 있으니 벌써 인덴트의 depth가 2이다. 만약 이러한 제약 조건이 없었다면 비교 결과의 스트라이크나 볼을 증감하는 논리까지 한번에 다 들어가 있어 함수가 더욱 커졌을 것이다.

사실 이와는 별개로 지금보면 잘 만든 메서드 같지가 않다. compare라는 이름답게 인자로 받은 데이터들을 말 그대로 비교해서 결과를 반환해주는 코드가 더욱 좋을 것 같다.

미션 피드백

• 이름을 통해 의도를 드러내라
• 축약하지마라
• 공백도 코딩 컨벤션이다.
• 공백 라인을 의미 있게 사용해라
• 반복하지 마라
• space vs tab 혼용
• 의미 없는 주석을 달지 않는다.
• 커밋 메시지를 의미 있게 작성하라
• 기능 목록을 업데이트하라
• 기능 목록을 재검토하라
• README.md를 상세히 작성하라
• IDE의 코드 자동 정렬 기능을 활용해라
• 매직 넘버를 사용하지마라
• 구현 순서도 코딩 컨벤션이다.

이것이 1주차 피드백이다. 이중에서는 지킨 것도 있지만 지키지 못한 것들도 있다.

이름을 통해 의도를 드러내라

위에서 나온 코드이지만 compare를 뜻 그대로 풀이하자면 비교하다이다. A와 B를 비교할꺼면 A와 B를 인자로 받아 비교 결과를 돌려주면된다. 하지만 이것은 메서드의 이름보다 더 많은 일들을 하고 있다.

공백 라인을 의미 있게 사용하라

사실 여기서 if문 밑에 특별히 띄울 필요는 없었다고 생각한다. 아마 당시에는 그저 보기에 너무 다닥다닥 붙어있었다고 생각한 듯하다. 하지만 앞으로는 의미 단위로 띄우도록 해야 한다.

기능 목록을 업데이트하라

실제 커밋 기록을 보면 처음 docs를 작성하고 나서는 그 후에 수정이 없다. 물론 수정을 위한 수정을 할 필요는 없지만 어떻게 보면 '문서'를 잘 활용하지 못했다. 문서를 잘 활용하려면 문서를 통해 코드를 어떻게 짤지 생각이 정리되고, 코드를 짜면서 놓친 문서를 업데이트하며 서로 상호작용을 해야한다.

매직 넘버를 사용하지마라

만약 이 프로그램에 대한 전혀 모르는 사람이 코드를 본다면 1과 9가 뭐를 뜻하는지 모를 수 있다.

Ball newBall = new Ball(Randoms.pickNumberInRange(RANDOM_MIN, RANDOM_MAX));

이런식으로 수정하면 조금 더 읽는 사람이 이해하기 쉬울 것이다.

느낀 점

과제를 하면서 혼자 공부하면서 자바에 예전보다 더 익숙해졌다라고 느껴서 뿌듯했다. 다만 혼자서 객체지향적인 코드를 짜고, 클린 코드를 짜려고 노력했지만 생각보다 많이 성장하지 않은 부분도 있어서 아쉬웠다. 우테코 과정을 진행하게 된다면 다른 사람들과 피드백을 주고 받으며 더 많이 성장할 수 있지 않을까 생각한다.

다른 사람들의 PR을 보니 실력도 뛰어나고 열정이 많으신 분이 많다. 항상 이렇게 성장하고 싶어하는 사람들과 같이 공부를 해보고 싶었다. 그래서 남은 프리코스 기간이 많이 기대된다.

2주차 - 자동차 경주 게임 만들기

미션 구현

https://github.com/injoon2019/java-racingcar-precourse/tree/injoon2019

2주차 미션의 핵심은 클래스의 분리라고 생각했다. 메서드의 분리보다 조금 더 발전한 것이라고 생각하는데 본질은 같다고 생각했다. 결국 한 클래스가 하나의 책임을 지게하는 것이 핵심이라고 생각했다.

미리 결론부터 말하자면 2주차 피드백을 받았을 때 내가 나눈 클래스는 하나의 책임을 지지 않았다.

또한 1주차 피드백을 반영하고, 1주차 미션에서 아쉬웠던 문서를 제대로 활용하지 못한 점도 보완하기로 했다.

내가 생각했을 때 잘했다고 생각한 부분이다. 기능 요구 사항에 시도횟수를 입력 받아서 그 횟수만큼 전진시키는 것인데, 그 횟수를 단순히 int와 같은 기본 자료형이 아닌 하나의 객체로 만들었다.

하나의 객체로 분리를 했기 때문에, 값의 검증을 PlayTime 객체가 책임을 질 수 있다. 또한 PlayTime이 만약 10이하여야 한다라는 조건이 있었다면, 이러한 비즈니스 로직을 PlayTime이 갖게되는 것이니 보다 객체지향적이라고 말할 수 있다.

미션 피드백

기능 목록 구현을 재검토한다.

이번에는 처음 작성한 문서를 기반으로 코드를 작성하되, 놓친 것이 있으면 문서를 수정하기도하고, 그 문서를 바탕으로 코드를 또 작성하였다.

값을 하드 코딩하지 마라

문자열에 이렇게 상수화를 해주면 나중에 변경이 용이하다는 장점도 있지만, 읽는 사람의 입장에서 어떤 것을 의미하는지 보다 명확히 알 수 있다.

축약하지 마라

함수(메서드) 라인에 대한 기준

이번에도 마찬가지로 함수가 15라인이 넘어가지 않도록 하였다. 이러한 기준 덕분에 메서드가 지나치게 커지는 것을 일차적으로 막아주는 기준이 되었다.

commit 메시지에 "#번호"를 추가하지 않는다.

발생할 수 있는 예외케이스에 대해 고민한다.

이 부분은 그리 잘한 것 같지 않다. 시도 횟수를 입력 받을 때 숫자가 아닌 경우, 음수인 경우 등을 고려하였지만, 자동차 이름을 입력 받을 때 빈 값인 경우, 쉼표를 이름으로 넣는 경우 등등 보다 다양한 경우가 있다.

주석은 꼭 필요한 경우만 남긴다.

git을 통해 관리할 자원에 대해서도 고려한다.

Pull Request를 보내기 전 브랜치를 확인한다.

실제로 푸시를 하고 나니 탭의 간격이 맞지 않아 당황하였다. 기존의 구글의 자바 양식이 아닌 네이버 양식으로 수정을 하며 발생한 문제였다.

java에서 제공하는 api를 적극 활용한다.

배열 대신 java collection을 사용하라.

자바 컬렉션을 이용하면 보다 다양한 기능들을 사용할 수 있다.

객체에 메시지를 보내라.

아직 실제 코드 구현을 하는데 적용하기가 쉽지는 않다. get을 사용하기 전에 메시지를 보낼 수는 없는지 한번 더 생각을 해봐야겠다.

필드(인스턴스 변수)의 수를 줄이기 위해 노력한다.

비즈니스 로직과 UI 로직을 분리해라

Car 객체에 있는 메서드다. 비즈니스 로직과 ui 로직을 분리하지 않으니 중간 중간 입력을 받고, 출력을 하는 기능들이 섞여있다.

3주차 - 자판기

미션 구현

https://github.com/injoon2019/java-vendingmachine-precourse/tree/injoon2019

이번 미션에서 테마는 2주차 미션 후 받은 피드백인 비즈니스 로직과 UI 로직을 분리하는데 초점을 두기로 하였다. 또한 스트림과 옵셔널을 쓰는 것에 익숙하지 않은데, 의식적으로 사용을 해보기로 하였다.

전체적으로 MVC 패턴을 이용해보았다. 프레임워크 없는 콘솔 프로그램에서 어떻게 MVC 패턴을 적용해야할지 고민이 많이 되었지만, view 클래스에서 입력과 출력을 담당하게 만들었다. 또한 웹 프로그램에서는 서비스 클래스를 보통 만들지만, 불필요한 복잡성을 줄이기 위해 서비스 클래스는 생성하지 않았다.

InputView의 경우에는 단순히 입력값을 반환하는 것이 아닌 객체를 컨트롤러에 반환하도록 하였다. 웹 프로그래밍을 할 때는 ObjectMapper 같은 것을 사용하였었는데, 이번 기회로 ObjectMapper는 컨트롤러 쪽에 가까운지 뷰 쪽에 가까운지 생각해보는 계기가 되었다.

3주간 느낀 점

3주간의 프리코스가 정말 빠르게 지나갔다. 나는 이번 프리코스가 최종 시험의 결과에 상관없이 앞으로의 개발 인생에 유의미하기를 바랬다. 그래서 단순히 구현에 집중하기보다 매주 작은 것이라도 배우는 것을 남기려하였고, 고민하는 시간을 가지려했다.

실제 프로그래밍을 하다보면 생각보다 고민을 할 시간이 없는 경우가 있다. 일정에 쫓겨일 수도 있고, 구현 자체가 너무 힘들어 좋은 코드에 대해 서는 생각할 여력이 안되는 것이다. 3주간 진행된 프리코스 미션은 구현 자체가 아주 어렵다고는 말할 수 없다. 아니 사실 1,2주차의 미션은 알고리즘 코딩 테스트에 익숙한 사람이라면 1시간도 걸리지 않을 난이도다.

하지만 프리코스는 그렇게 진행되지 않았다. 좋은 책을 볼 때 한 문장 한 문장 의미를 느끼며 천천히 읽으면 새롭게 책을 보는 바로 그 기분이었다.

좋은 코드를 작성하기 위해 읽어야 한다는 클린코드 책을 사놓고 한동안 열어보지도 않았었다. 하지만 이번 프리코스는 좋은 코드의 의미와 방법에 대해 생각해보게 만들었고, 저절로 책을 찾게 되었다. 아직 진행 중이지만, 책을 정리 해보며 느끼는 것은 좋은 코드를 작성하기 위해서는 이론과 연습이 반드시 밸런스가 맞아야 한다는 점이다.

클린 코드 책만 아무리 읽는다고 해서 좋은 코드가 술술 나올 수는 없다. 이는 책의 저자도 이야기하는 부분이다. 그렇다고 해서 좋은 코드에 대한 지향점 없이 코드만 작성한다고 해서 저절로 터득될 수 있는 것도 아니다.

이러한 점을 알게되니 우테코 본과정이 더 궁금해진다.

---

결과

정말 감사하게도 합격했다. 3기 때 떨어진 경험이 있는 사람으로서 나는 절대 실력이 월등하거나 합격할 당위성이 있어서 합격했다고 생각하지 않는다. 운이 조금 더 좋았다. 내가 알게되는 것들을 최대한 공유하고, 또 한번 열심히 달려볼 계획이다.