2019년 우아한테크코스 프리코스까지의 후기

2019년 우연히 친구를 통해서 우아한테크코스를 진행한다는 것을 들었다.

처음에는 인턴도 아니고 8개월간 급여도 없이 교육시켜주는 활동이 어떤 도움이 될까 라는 생각을 하게 되었다.

 

하지만!! 우아한형제들 기술블로그에 기재되어있는 우아한 테크코스에 대한 글을 읽고나서는

'아! 내 8개월을 충분히 할애할 가치가 있는 코스이다!'라는 생각이 들었다

 

우아한 테크코스에 대한 자세한 설명은 -> http://woowabros.github.io/woowabros/2019/02/08/woowacourse.html

'우아한테크코스 - 웹 백엔드' 과정에 참여할 사람을 모집합니다. - 우아한형제들 기술 블로그

 

첫번째 관문 - 온라인 코딩 테스트

본 과정은 서류 접수를 한 모든 대상에 대해 온라인 코딩 테스트를 진행하였다.

4시간 동안 알고리즘 문제들을 해결하는 것이였으며, 기본적인 자바 지식을 묻는 문제 위주로 구성이 되었다.

그 결과..

온라인 코딩 테스트 합격을 하게 되었다!!!!!!!!!!!!!!!!!!!!

 

두번째 관문 - 3주간의 프리코스

온라인 코딩 테스트 합격자에 한해 3주간의 온라인 프리코스를 진행하게 되었으며,

프리코스는 매 주 과제를 github을 통해 제출하는 방식으로 진행되었다.

첫번째 과제 - 숫자야구게임

첫번째 과제로 학창시절 많이 하는 숫자야구게임을 구현하는 과제를 받게 되었다.

숫자야구게임은 다음과 같은 조건이 있었다.

기능요구사항   숫자야구게임 - 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임   1. 컴퓨터는 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 만든다. 2. 사용자는 3자리의 숫자를 입력하고, 컴퓨터의 숫자와 비교하여 같은 수가 같은 자리에 있으면 스트라이크, 다른자리에 있으면 볼, 같은 수가 전혀 없으면 포볼(낫싱)을 출력해준다. 3. 사용자가 숫자를 맞출때까지 해당 기능을 반복한다. 4. 사용자가 숫자를 맞췄을 시 게임을 다시 시작하거나, 완전히 종료할 수 있다.     프로그래밍 요구 사항   1. 자바 코드 컨벤션을 지키면서 프로그래밍한다.(3주차인 지금도 정말 어려운 요구사항이다...) https://myeonguni.tistory.com/1596 2. indent(들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지 허용한다.  예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다. 3. 함수(또는 메소드)가 한 가지 일만 하도록 최대한 작게 만들어라.

위의 요구 사항을 지키며 과제를 작성하다 보니 다음과 같은 사항들에 대해 많은 고민이 생겼었다.

 

1. 자바 코드 컨벤션(코딩 규칙) 준수

 - Naming부터 조건문 사이에 띄어쓰기 등 평소에 무심코 지나쳤던 부분이 자바 코드 컨벤션이였던 것이였다ㅠㅠㅠㅠ

   그래서 commit을 하기전 작성한 내용에 대해 위의 코딩 규칙 블로그를 보면서 잘 준수하였는지 확인을 하고 commit하였다.

2. git 사용

 - 기능 단위 commit이 많이 어려웠었다. 처음엔 구현이 됐다 판단되면 바로 commit을 진행하였는데 불필요한 commit이 많아져서 이를 합치는 작업을 진행하게 되었다.

 - git 사용하면서 엄청난 실수(?)를 하게 되는데 로컬 git에 잘못된 이메일 주소를 입력해서 Author가 정상적으로 인식되지 않았다ㅠㅠ -> 이 때문에 모든 commit에 대해 rebase를 실행하는 작업이 있었다..하하하

 

결과물 : https://github.com/vsh123/java-baseball/tree/van

vsh123/java-baseball

확실히 첫번째 과제는 어려운 내용은 아니였지만 기능 구현 외적으로 생각해야할 것들(코드 컨벤션, git 사용 등)을 생각하면서 작업하는 경험을 쌓을 수 있었던 것 같다.

 

----------------------------------------------------------------------------------------------------------------------------------

두번째 과제 - 자동차 경주게임

두번째 과제는 자동차경주게임을 받게 되었는데, 과제와 함께 첫번째 주에 대한 피드백도 같이 받았다.

첫번째 주 과제 피드백   1. 이름을 통해 의도를 드러내라 - 변수, 메소드, 클래스 이름을 짓는데 시간을 투자하고 주석이 없이 이름만 보고 판단할 수 있을 정도로 만들어라. 2. 이름을 축약하지 마라 3. 개발 도구의 code format 기능을 활용하라 4. space(공백)도 convention이다. 5. 불필요한 공백 라인을 만들지 않는다. 6. 반복하지 마라 7. space와 tab을 혼용하지 마라 8. 의미없는 주석을 달지 않는다. 9. 값을 하드 코딩하지 마라 - 상수(static final)을 만들어라 10. git commit 메세지를 의미있게 작성해라 11. README.md에 작성하는 기능 목록은 언제든지 변경될 수 있다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다. 12. README.md를 상세히 작성해라 기능요구사항   1. 주어진 횟수 동안 n대의 자동차는 전진 또는 멈출 수 있다. 2. 각 자동차에 이름을 부여할 수 있다. 전진하는 자동차를 출력할 때 자동차 이름을 같이 출력한다. 3. 자동차 이름은 쉼표(,)를 기준으로 구분하여 이름은 5자 이하만 가능하다. 4. 사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다. 5. 사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다. 6. 전진하는 조건은 0에서 9사이에서 random값을 구한 후 random값이 4이상일 경우 전진하고, 3이하의 값이면 멈춘다. 7. 자동차 경주 게임을 완료한 후 누가 우승했는지를 알려준다. 우승자는 한 명 이상일 수 있다.     프로그래밍 요구사항   1. 1주차의 프로그래밍 요구사항은 기본적으로 가져간다. 2. 저장소에서 제공하는 Car객체를 활용하여 구현해야한다. 3. else 예약어를 쓰지 않는다. 4. 함수(또는 메소드)의 길이가 15라인을 넘어가지 않도록 구현한다.

2주차에는 다음과 같은 사항들에 대해 많은 고민이 생겼었다

 

1. README.md 작성

 - 1주차에는 README.md를 완벽하게 작성하고 개발을 하려고 시작자체가 어려웠었다. 하지만 이번 피드백을 통해서 '필요시 수정을 하자!'라는 마음가짐으로 진행하다보니 피드백에서 이야기한 살아있는 문서가 무었인지 조금은 깨닫게 되었다.

2. Naming(명명)

 - README.md에 구현해야할 메소드의 이름을 작성하였다. 최대한 다른사람들이 이름만 보고도 무슨 기능인지 알아볼 수 있게 작성하려고 노력하였고, 메소드 명을 친구에게 보여주면서 어떤 역할을 하는 건지 맞춰보라고 문제를 내면서 명명을 진행하였다. 이 결과 불필요한 주석이 줄었으며, 다른 사람들이 메소드를 보고 쉽게 판단할 수 있는 이점이 생겼다.

3. git commit 메세지 작성

 - 최초 개발은(feat), 수정사항은(refactor)를 앞에 붙여 commit들을 보고서 어떤 작업을 했는지 알아볼 수 있게 진행하였다. 또한 commit 내용에는 구현 기능이나 수정한 내용에 대해 자세하게 기술하여 다른 사람들이 해당 commit의 변경된 부분을 보고 어떤 것이 추가, 수정 됐는지 쉽게 알 수 있게끔 하였다. 이러한 작업을 진행하면서 여러명이서 하는 프로젝트에서는다른사람들이 변경부분을 쉽게 이해할 수 있게 만드는 것도 뛰어난 기술이라는 것을 알게 되는 계기가 되었다.

 

결과물 : https://github.com/vsh123/java-racingcar/tree/van

vsh123/java-racingcar

2주차 과제는 1주차 과제에서 적용하였던 내용들에 대해서 조금 더 이해하고 알아가는 과정이 됐던 것 같다.

 

----------------------------------------------------------------------------------------------------------------------------------

세번째 과제 - 로또

로또 과제는 이전 과제들 보다 더욱 더 극단적인 요구사항이 있었다........

두번째 주 과제 피드백   1. 기능 목록 구현을 재검토한다 - 예외적인 상황에 대해 기재하여라 2. 값을 하드코딩하지 마라(2주차와 동일) 3. 축약하지마라(2주차와 동일) 4. 구현 순서도 convention이다. 구현순서도 convention이다   5. java api를 적극 활용한다. 6. 배열대신 java collection을 사용하라 7. 객체에 메시지를 보내라 8. 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다. 9. utf-8 인코딩 10. commit 메세지에 "#번호"를 추가하지 않는다. 11. 발생할 수 있는 예외케이스에 대해 고민한다. 12. 주석은 꼭 필요한 경우만 남긴다. 13. PR을 보내기전 브랜치를 확인한다. 기능요구사항   1. 로또 게임 기능을 구현해야 한다. 규칙을 모르면 검색해 로또 규칙을 찾아본다. 2. 로또 구입 금액을 입력하면 구입 금액에 해당하는 로또를 발급해야 한다. 3. 로또 1장의 가격은 1000원 이다. 4. 로또 당첨 금액은 고정되어 있는 것으로 가정한다. 5. 수익률을 계산해 출력해야 한다.  프로그래밍 요구사항   1. 1, 2주차의 요구사항은 기본으로 가져간다. 2. 함수(또는 메소드)의 길이가 10라인을 넘어가지 않도록 구현한다.(?) 3. indent(들여쓰기) depth를 2가 넘지 않도록 구현한다. 1까지만 허용한다.(?????????????????????????????????????????????) 4. 함수(또는 메소드)의 인자 수를 3개가지만 허용한다. 4개 이상은 허용하지 않는다.

일단 고려했던 내용을 얘기하기 전에 머리속에 멘붕이 왔다......

메소드 10라인, depth 1..... 하하하하ㅏ하하하하하ㅏ하하하하하하핳ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ하ㅏ하ㅏㅏㅏㅏㅏㅏㅏㅏ

그래도 구현은 해야 했기에 친구의 조언도 구하고 해서 다음과 같은 내용을 고려하면서 구현하였다.

 

1. 프로그래밍 요구사항 준수

 - 사용자가 입력한 6개의 당첨 숫자를 검사하는 메소드를 만들어야하는데 내 머리속으로는 for,if를 사용한 검사밖에 생각이 나지 않았다... 그래서 친구한테 조언을 구했고 친구가 stream을 이용해 보라고 해서 stream api를 이용해 구현했더니 아니 이게 왠걸? 다음과 같이 return 하나로 구현이 가능했다..

stream api를 이용해 구현한 당첨 숫자 확인 메소드

 이러한 경험을 java api를 이용하라는 박재성님의 말씀이 더욱 더 와 닿았다.

 - 함수의 길이를 10라인을 넘기지 않게 구현하려고 하니 한 메소드가 한가지 기능을 하게 만들어지는 신기한(?) 경험을 하게 되었다. 

2. 예외 처리

 - 발생할 수 있는 모든 예외 상황을 생각해 보았다. 대부분의 예외는 사용자 입력에서 발생하는 것을 발견 하였다. 

   예를 들어 구입금액을 입력받았을 때는 다음과 같은 예외 처리가 필요하다.

   (1) 숫자가 아닌 경우

   (2) 티켓 가격(1000원) 보다 작은 금액이 입력되었을 경우

   (3) 티켓 구매 가능 금액(1000원)의 배수가 입력이 안됐을 경우 -> 이 경우 1000으로 나눈 나머지를 무시 / 1000의 배수만 입력하게끔 설정의 두가지 방법으로 예외 처리가 가능하다.

   이처럼 다양한 예외처리목록들을 구현 기능 목록에 작성하고 구현을 하는 진행하여 개발자가 원하지 않는 경우가 발생할 경우를 대비하였다.

3. 필드(인스턴스 변수) 미사용

 - 새로 구현한 LottoGame 클래스에 인스턴스 변수를 사용하지 않고 인자로 넘기어 처리하는 작업을 진행하였다. 이는 2주차 피드백의 내용이였으며 이를 통해 복잡도를 줄이고, 버그 발생 가능성을 줄이기 위해 노력하였다.

-> 과제 제출하고 생각난 점인데 Rank 객체에 message 인스턴스 변수를 새로 생성하지 않았어도 printMessage 메소드를 구현하는데는 큰 문제가 없었을것이라는 생각이 든다ㅠㅠㅠ 아쉽다..

 

결과물 : https://github.com/vsh123/java-lotto/tree/van

vsh123/java-lotto

3주차는 1,2주차에서 다졌던 기초들을 바탕으로 뭔가 자바다운(?) 프로젝트를 만들어 낸 경험을 얻을 수 있었다.

 

 

세번째 주 과제 피드백 1. 상황(context)에 맞는 설계와 구현 방법을 찾아라  - 프로그래밍 설계와 구현에 정답은 없다. 정답을 찾기보다 요구사항에 적합한 최선의 설계와 구현 코들를 찾기 위해 노력한다.   2. 반복문 대신 재귀 함수로도 구현할 수도 있다. ex) 정말 상상도 못한 방법........   3. 원시 타입과 문자열을 포장하라  - 구입 금액을 Money 객체로 포장  - 로또 숫자 하나를 LottoNumber 객체로 포장   4. 적절한 Collection(자료구조)를 활용하라  - List, Set, Map을 적절하게 활용한다.  - 적절한 자료구조가 없다면 나만의 자료구조(나만의 클래스)를 구현한다. List 대신 Set으로 변경해서 구현해도 문제가 없었다. Collection변경에 대한 제한이 없었으니까   5. 객체에 메시지를 보내라  - 상태 데이터를 가지는 객체에서 데이터를 꺼내려(get)하지 말고 객체에 메시지를 보내라

 

 

3주간의 프리코스를 진행하며..

프리코스를 진행하면서 git 사용에 대해 조금 더 능숙해졌다. 매 주 진행되는 과제는 github에 PR(Pull Request)을 하는 방식으로 제출했었는데, 이 과정에서 기능단위 commit과 메세지를 작성하는 것에 대해 많은 고민을 하기도 했었고 commit을 잘못 찍어 rebase를 하는 등 많은 우여곡절이 있었다. 하지만 이렇게 부딪혀 나가면서 git의 다양한 기능을 직접 실행해 볼 수 있었고 3주차에는 제법 능숙하게 git을 다뤘던 것 같다.(아직 멀었지만..)

 

가장 좋았던 점은 매주 과제에 대한 피드백이 이루어 졌다는 것이다. 물론 많은 인원이 진행되는 과정이 였기 때문에 개인별 피드백은 아니였지만, 참가자들의 과제를 리뷰하시면서 많은 사람들이 어려워하거나 알았으면 하는 점을 모아 전달해주는 점이 무엇보다 좋았다. 피드백을 통해 느끼는 점이 정말 많았으며 이로 인해 정말 많은 도움이 됐다.(언제 이렇게 뛰어난 개발자분께 피드백을 받아보겠는가..!!)

 

마지막으로 과제 제출 후 다른사람들의 코드를 볼 수 있는 것이 너무나도 좋았다! 다른 사람들의 PR도 보면서 '아.. 이 분은 이렇게 짰구나', '정말 생각지도 못한 방법이다.'라는 생각을 많이 했었다. 이번 과제를 진행하면서 같은 기능을 구현하더라도 사람마다 구현하는 방식이 다르다는 것을 느꼈고, 이를 통해 새로운 생각이나 발상을 가질 수도 있다는 것이 확실하게 와닿았다. 너무 잘하는 사람들이 많아 오프라인 코딩테스트에 합격할 수 있을까 하는 걱정도 되었지만 합격하여 오프라인 과정을 진행하게 되면 이런 분들이랑 같이 발전해 나갈 수 있다는 것이 정말 기대가 된다.

 

그리고 무엇보다 스스로 성장한 내 자신을 보며 오프라인 테스트도 통과해 꼭 우아한 테크코스 과정을 수료하고 싶다는 의지가 생기는 3주가 되었다. 오프라인 테스트를 통과해 테크코스 과정을 모두 마친 후 후기를 올릴날을 기대해 본다.