[우아한테크코스 3기] 프리코스 회고

우테코 1차를 합격하고 20.11.25일을 시작으로 3주간의 프리코스가 진행되었다.

3주가 이렇게 빠른가 싶을정도로 매주 미션에 집중하고 또 집중한듯싶다.

이번 글은 이전 글에 연장선으로 3주간의 프리코스에서 배운 점, 느낀 점 그리고 부족한 점에 대해서 회고하는 시간을 갖고자 한다.

 

프리코스란?

프리코스는 우테코 1차(지원서, 코테) 합격자 대상으로 매주 미션이 주어지고 요구사항에 따라 구현하여 제출하는 과정이다.

우테코는 강의식으로 진행하는 주입식 교육이 아니기 때문에 교육과정을 미리 경험해보는 시간이라 보면 된다.

( 물론 이과정이 끝나고 오프라인 코딩테스트를 통해 탈락자가 나오기 때문에 경쟁이라 볼 수 있다. )

 

---

미션 1. 숫자 야구 게임

제가 구현한 코드는 여기서 확인할 수 있습니다.

첫번째 미션은 간단한 숫자 야구 게임이었다.

게임은 프로그램이 1에서 9까지 서로 다른 임의의 수 3개를 정하고 이를 플레이어가 맞추는 간단한 게임이었다.

실행 결과를 보면 프로그램을 구현시키는 것은 어려워보이지 않지만, 프로그래밍 요구사항이 따로 존재했다.

• Google Java Style Guide (자바 코드 컨벤션)과 AngularJS Commit Message Convention을 지키면서 프로그래밍 해야한다.
• indent depth가 3이 넘지 않도록 구현해야한다. 2까지만 허용된다.
• 함수 (또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
• 3항 연산자를 사용하지 않는다.
• 먼저 기능을 목록화하고 기능별 commit

 

함수(메서드) 분리

요구사항중 하나가 바로 "함수가 한 가지 일만 하도록 최대한 작게 만들어라"였다.

하나의 메서드가 너무 많은 일을 한다. (가독성도 꽝..)

당시에 난 열심히 분리하려고 했지만, 위 코드를 보면 하나의 메서드가 많은 일을 수행한다.

지금 생각해보면 다른 객체에 메시지 요청을 통해 책임을 좀더 나눴어야 했던 것 같다.

그래도 이전엔 하나의 함수에 모든 코드가 모여 있었는데 많은 발전을 했다.

확실히 함수를 분리하니 코드 가독성도 높아지고, 리팩토링하기에도 굉장히 좋았다.

앞으로 지속적인 연습해야될 부분인 듯 싶다.

 

기능 목록화(문서화)하고 기능별 commit

프리코스를 참여하기 전, 나는 프로그램을 구현하면서 모든 기능을 나열만하고 머릿속으로만 생각하고 구현에 돌입했었고,

commit도 사실 막 구현하다가 백업용으로만 했었기 때문에 기능별 commit 요구사항은 낯설게 다가왔다.

그래도 열심히 요구사항을 맞춰 구현하는데 필요한 기능을 고민하고 완벽히 객체 설계와 기능 목록을 작성하였다.

이렇게 하면서 느낀 점은 어떤 순서로 코드를 작성해야할 지 큰그림이 그려졌고, 코드 구현시간도 많이 단축시켜줬던 것 같다.

또한, commit도 추후에 기능별 브랜치를 내서 기능 구현을 하면 협업할 때 도움이 많이 될 것이라고 느꼈다.

 

죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력하라

1주차가 끝나고 뼈를 맞은 듯한 피드백이 하나 있었다. 바로"죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력하라"다.

처음부터 완벽하게 README를 작성하려고 시간을 허비했기 때문에 고쳐야될 습관이라 생각들었다.

 

Convention

평소 여러 프레임워크의 코드를 보면서 '어떻게 이렇게 가독성이 좋고 일정하지?'란 궁금증이 있었는데, 이렇게 세세하게 규칙이 정해져 있는지 몰랐다.

처음 알게된 내용들이라 엄청 세밀하게 봤고, Google Java Style Guide - 번역본도 만들게 되었다.

( 하지만 제출한 코드를 보니 Convention을 준수하지 않는 부분들이 있다.. 앞으론 더 확인하는 습관을 들여야겠다. )

확실히 Convention을 지키며 코드를 작성하니 코드들이 일정하고 보기 좋은 코드가 나오는 것 같다.

 

---

미션 2. 자동차 경주 게임

제가 구현한 코드는 여기서 확인할 수 있습니다.

두 번재 미션은 자동차 경주 게임을 구현하는 것이었다.

자동차의 이름과 이동 횟수를 입력하고, 각 자동차는 랜덤하게 전진하여 최종 우승자를 뽑아내는 게임이다.

1주차 미션보다 로직이 조금은 복잡해졌다. 그리고 프로그래밍 요구사항이 더 추가되었다.

 

else를 사용하지 않는다

처음엔 else를 사용하지 않고 구현하기 힘들지 않을까 싶었다.

모든 프로그래밍 언어에서 존재하는 else를 왜 사용하지 않는 것인지 처음엔 의문이었지만, 객체지향 책 (토끼책)을 보고 구현해보면서 그 이유를 알 수 있었다.

우선 else나 switch를 사용한다는 것은 컴파일 시점에 로직을 결정하므로, 변경이나 확장 그리고 유지보수에 취약하다.

// 만약 새로운 status값을 추가해야 된다면 모든 클래스에서 else문을 추가해줘야한다. (변경에 취약)
if (status == 1) {
    ...
} else if (status == 2) {
    ...
} else if (status == 3) {
    ...
}

그리고 함수는 한 가지일만 해야하는데 if ... else ...는 문법적으로도 두 가지의 일을 처리한다는 의미가 된다는 것을 깨닫게 되었다.

 

클래스 분리

프리코스를 진행하며 객체지향 설계에 대한 중요성을 느끼게되어 몇달전에 봤던 토끼책을 다시 펼쳤다.

하지만 너무나도 많은 내용과 지켜야 하는 사항들이 있어서 개념은 다 알겠지만, 막상 설계하려니 어렵게 느껴졌다.

그래서 이번 미션을 진행하며 "꼭 지켜야지"하는 규칙을 세워 가능한 지키려고 노력했다.

 

 

처음 객체를 설계할 때 책임을 중심으로 설계하려고 노력하였고, 객체들간의 메시지 요청을 통해 협력을 하도록 노력했다.

 

클래스를 분리하니 이전보다 각자 역할을 담당하고 협력하는 구조를 만들 수 있었다.

( 지금보니 더 분리할 수 있지 않았을까 싶다. )

또한, 클래스를 분리하니 단위 테스트가 용이해져 리팩토링하기가 수월했다.

객체지향을 공부만 해봤지 제대로 설계해본 경험이 없었는데 프리코스를 하며 연습할 수 있어 좋은 경험이었다.

 

이해하기 좋은 코드

프리코스를 진행하며 나에게 가장 큰 수확중 하나는 '좋은 코드'의 중요성을 알게 된 것이다.

이전에 클린 코드의 중요성을 익히 들었지만, 나에게 크게 다가오진 않았었다.

변수, 메서드, 클래스 이름을 짓는데 시간을 많이 투자하지 않았는데 정말 크게 반성하게 된 계기가 되었다.

이번 미션을 진행하면서는 내가 작성한 코드가 많은 참여자들이 본다는 생각에 나의 의도를 드러내기 위해 노력을 많이 했다.

우선 클린 코드책을 사서 열심히 읽었고, 네이밍에 시간을 많이 투자했다.

아래 가장 종아하는 글귀를 가져와봤다.

깨끗한 코드는 '보기에 즐거운' 코드다. - 비야네 스트롭스트룹 -

깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. - 그대리 부치 -

나의 코드를 누군가 보면서 우아하다고 생각하거나 소설처럼 재밌게 읽혀졌으면 좋겠다는 생각을 하게되었다.

그리고 좋은 코드를 작성하는 노력이 코딩을 재밌게 해주었다. ( 마치 내가 재밌는 소설책을 작성한다는 느낌이랄까?? )

 

주석

평소엔 코드 작성보단 주석 작성에 더 의미를 많이 두었던 것 같다.

1주차가 끝나고 "의미 없는 주석은 쓰지 않는 것이 좋다"라는 피드백을 받고 한방 얻어 맞은 기분이었다..ㅎ

미션을 진행하며 주석 쓸 시간에 코드를 더 의미있게 작성하자고 다짐하게 된 계기가 되었다.

 

---

미션 3. 지하철 노선도 미션

제가 구현한 코드는 여기서 확인할 수 있습니다.

세 번째 미션은 지하철 역과 노선을 관리하는 지하철 노선도 관리 프로그램을 구현하는 것이었다.

크게 추가된 요구사항은 없었지만, 설계나 구현이나 1, 2주차 미션보다 난이도가 확 올라갔다.

미션의 자세한 요구사항은 여기에서 확인할 수 있다.

 

UI 로직과 비즈니스 로직 분리

3주차 미션에서도 함수 분리 + 클래스 분리 + 클래스 협력에 많은 노력을 기울였다.

특히, 2주차 피드백에 따라 UI 로직과 비즈니스 로직을 분리하고자 노력했다.

우선 UI 로직과 비즈니스 로직을 분리하는 기준을 알아보았다. 

여기서 깨닫은 점은 두 객체는 '주문서'라는 DTO 객체를 통해 협력을 하고, 두 객체는 오로지 자신의 역할만 한다는 것이다.

나도 비즈니스 로직은 UI 로직에 상관없이 요청에 따른 처리만 하고 결과만 반환하면 되는 구조로 설계하려고 노력했다.

이렇게 함으로써 UI 로직과 비즈니스 로직을 따로 개발할 수 있어 이전보다 유연하고 테스트에 용이한 코드가 나온 것 같다

맞다. 눈치 채셨을 분들이 계셨겠지만, "클라이언트 - 서버" 구조와 유사하다.

스프링MVC의 Controller - Service - Repository (3-tier) 방식을 응용하여 구현하였다.

확실히 UI 로직과 비즈니스 로직을 분리하니 로직을 따로 구현할 수 있었고, 단위 테스트하기에도 용이했다.

처음엔 MVC 패턴으로 설계하다가 자연스럽게 이렇게 바뀐것 같다.

( 피드백에는 한 클래스에 두 로직을 같이 사용하지 말라는 것이었는데, 혼자 이런 저런 고민하다가 이렇게 생각이 커진듯하다..)

 

상속

이번 미션의 요구사항을 지키기 위해선 중복이 많이 발생하였고, 중복을 제거하기 위한 첫번째 방법으로 상속을 사용하였다.

우선 View들의 공통 책임은 View 인터페이스로 선언하고, 이를 구현한 추상 클래스 (AbstractView)를 만들어 모든 View의 중복을 제거하였다.

그리고 또 다시 2가지의 뷰로 나눠 중복을 한층 더 제거하였다. (메뉴 선택 뷰, 일반적인 출력 뷰)

중복 제거와 다형성 측면에서 인터페이스와 추상 클래스를 상속하는 것이 효과적이라고 느끼게 되었다.

한편으론, 상속의 깊이가 너무 깊게되면 비효율적이라 느끼기도 했다. 왜냐하면 하위 클래스에선 상위 클래스의 의존성과 메서드들이 감춰지기 때문에 코드를 이해하기가 힘들어지기 때문이다.

(스프링에서 코드 여행(ctrl + 클릭)을 떠나보신 분들은 이해하시리라..)

또한, 하위 클래스가 상위 클래스에 강하게 의존적이므로 조심해서 사용해야겠단 생각이 들었다.

 

함수형 - Stream, 람다

프리코스 참여전에는 함수형의 중요성을 많이 느끼지 못했다. 왜냐하면 같은 로직인데 뭐하러 저렇게 하나 싶었다..

하지만 2주차가 끝나고 java api를 적극 활용하라는 피드백이 있어 Stream과 람다를 이번 기회에 써보고자 노력했다.

Stream과 람다를 적극 활용하니 코드가 더 간결해지고 depth를 줄어들어 코드의 의도를 더 명확히 표현할 수 있었다.

그리고 코드를 레고 조립하듯이 작성이 가능해 중복을 제거하는데에도 굉장히 효과적이었다.

불변식과 일급 객체를 바탕으로 구현하는 함수형 프로그래밍에 대해 더 공부해야겠단 생각도 들었다.

Stream 정리한 자료

---

프리코스 느낀 점

3주동안 진행하며 프리코스에 대한 전반적인 느낌 점은 아래와 같다.

 

정답을 알려주지 않고 방향을 알려준다

우선 정답을 알려주지 않고 방향만을 알려주고 자기주도적으로 공부하는 방식이다.

그래서 우테코는 강의장에서 주입식교육을 하는 곳이 아니란 느낌을 받았다.

개인적으론 여러 지식을 내것으로 만드는데 아주 좋은 방법이라 생각든다.

또한, 정답이 없으므로 다른 참여자들의 코드를 보면서 새로운 인사이트도 많이 얻었던 것 같다.

 

나는 우물 안 개구리였다

자바의 정석을 시작으로 자바를 공부하기 시작하여 비행기 게임과 채팅 프로그램을 구현해보고, 스프링도 공부하며 내가 잘한다고 느낀 적이 많았다. (몇몇 사람들이 칭찬해주니 진짜 잘하는 줄..)

완전한 착각이었다.. 다른 참여자들의 코드를 보면서 정말 아직 갈 길이 멀다고 느끼게 되었다.

그야말로 우물안 개구리다.. 우테코를 하며 바다가 있다는 것을 알게되어 정말 감사하다.

앞으론 우물 안을 떨쳐 나와 바다를 아우를 수 있도록 나 자신을 되돌아보고 치열하게 자기 학습을 해야겠다는 다짐을 하게되었다.

 

 

마무리

프리코스가 끝나고 이렇게 블로그에 글을 쓰면서 지난 3주를 되돌아보았다.

3주동안 정말 많은 것을 고민하고, 배우고, 경험한 것 같다.

무엇보다 앞으로 더 성장하고싶다는 욕심이 많이 생기게 되었다.

마지막으로 좋은 자극을 준 참여자분들과 프리코스를 진행해주신 관계자분들에게 감사하다고 전하고싶다.

 

 

ps. 글쓰기 연습을 많이 해야겠다... 지금보니 글에 기승전결도 없고... 앞으로 더 연습하여 양질의 글을 쓸 수 있도록 노력해야겠다.