1. 우아한 테크코스 프리코스란

---

[우아한 테크코스]

---

우아한 테크코스란 우아한 형제들에서 제공하는 교육으로 교육 목표는 다음과 같다.
'일반 사용자용 서비스를 개발하는 회사가 필요로 하는 역량을 가진 개발자 양성'

모집 분야

웹 백엔드(Java), 웹 프론트엔드(Javascript)

지원자격

프로그래밍에 대한 기본 지식과 경험을 갖고 있는 누구나.

모집절차

1. 1차 심사(자기소개서, 온라인 코딩테스트(240분 7문제)
2. 프리코스(매주 미션이 공개되고 제출, 총 3주)
3. 오프라인(또는 온라인) 코딩테스트(300분 주어진 미션 구현)

[프리코스]

---

이후의 내용들은 프리코스 안내 메일을 인용하였다.

진행방식

3주 동안 공통 피드백만 있는 상태에서 여러분 주도적으로 학습하고, 미션을 진행하고, github을 통해 구현한 결과물을 제출해야 합니다.
3개의 미션을 모두 구현하고, 기한 내에 제출한 사람들에 한해 오프라인 코딩 테스트에 참가할 수 있는 기회를 부여합니다.

목적

1차적으로 서로를 탐색하기 위함이다. 우테코 입장에서는 지원자가 앞으로 교육 과정을 따라올 수 있는지 판단하고, 지원자 입장에서는 내가 교육을 받을 수 있는 수준인가를 체크해 볼 수 있다.
2차적으로는 프리코스를 진행하면서 지원자가 한 단계 성장할 수 있는 기회를 주고 싶다. 3주간 미션을 진행하면서 자바 기본문법과 프로그래밍 구현에 대한 다른 접근 방식을 경험할 수도 있을거라 기대합니다.

2. 미션 내용

[숫자 야구 게임]

---

수요일 3시에 이메일로 미션이 공지되었으며, 미션 저장소 github README에 자세한 미션 내용과 기능 요구사항, 프로그래밍 요구사항, 과제 진행 요구사항이 있다.

숫자 야구 게임이란

미션의 숫자 야구 게임은 프로그램이 1에서 9까지 서로 다른 임의의 수 3개를 정하고 이를 플레이어가 맞추는 게임이다.

기능 요구사항

자세한 내용은 공개할 수 없으나, 사용자의 입력에 따라 힌트를 제공하며 정답을 맞출 경우 게임을 종료하거나 다시 시작할 수 있다.

힌트
스트라이크: 같은 자리에 같은 숫자가 있는 경우
볼: 다른 자리에 숫자가 있는 경우
낫싱: 같은 숫자가 하나도 없는 경우

입출력 요구사항

Scanner 클래스를 이용해 입력을 받고, log로 결과를 출력한다.
입/출력 각 상황에 대한 안내와 프로그래밍 실행 결과 예시를 보여주신다.

프로그래밍 요구사항

• 기본적으로 Google Java Style Guide을 원칙으로 하며 들여쓰기는 '4 spaces'로 한다.
• indent(들여쓰기) depth를 3이 넘지 않도록 구현다.
  • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
• 3항 연산자를 쓰지 않는다.
• 함수(메소드)가 한 가지 일만 하도록 최대한 작게 만든다.
• System.exit 메소드를 사용하지 않는다.
• 비정상적인 입력에 대해서는 IllegalArgumentException을 발생시킨다.
• 주어진 클래스의 패키지 구조와 구현은 변경하지 않는다.
• RandomUtils 클래스를 활용해 랜덤 기능을 구현해야 한다.

진행 요구사항

• 기능을 구현하기 전에 README.md 파일에 구현할 기능 목록을 정리해 추가한다.
• git의 commit 단위는 앞 단계에서 README.md 파일에 정리한 기능 목록 단위로 추가한다.
  • AngularJs Commit Message Conventions 참고해 commit log를 남긴다.

3. 미션 후기

---

[미션 탐색]

---

처음 미션을 받고 README를 읽어 보았을 때는 설렘 반, 당황 반 이었다. 문제를 푸는 코딩 테스트가 아니라, 작지만 프로그램을 만들어 본다는 기대감과 함께, 생각보다 많은 요구사항에 당황했다. 특히, Google Java Style Guide와 AngularJs Commit Message Conventions는 읽기조차 싫게 어려워 보였다.

프리코스 이전에 Java 문법만 공부해 보았다. 그것도 우아한 테크코스 온라인 코딩테스트를 통과하기 위함이었다. 코딩테스트를 준비한 것도 프로그래머스 level1 수준만 풀어봤다. 그러니 모든 로직을 main 클래스 안에서 처리했고, 이마저도 50줄 이상 넘어갈 일이 없었다.

[미션 구현]

---

우선, README에 기능목록부터 작성했다. 게임의 규칙이 간단하고 친절한 요구사항과 예시 덕분에 생각보다 쉽게 구현할 기능 목록을 정리했다.

입출력 요구사항이 각자 존재하는 걸로 유추하여 입력과 출력 기능을 따로 분리하였고, 난수 생성과 힌트 및 승리 조건을 기준으로 정리했다.

이후 application.java에 모든 로직을 작성하고 기능을 분리하는 방법으로 진행했다. 기능을 분리하다 보니 200줄이 넘어가고 스스로도 어디에 무엇이 있는지 한참을 스크롤링하며 찾았다. '이래서 클래스를 분리하는구나' 싶었다. 나름 논리적으로 분리해보았다.

Application과 RadomUtils는 처음부터 주어진 파일.

• 입력의 예외처리를 담당하는 InputValidator클래스
• 임의의 수를 생성하는 Opponent(컴퓨터) 클래스
• 입력을 담당하는 Player 클래스
  - 지금 확인해 보니 InputValidator와 같은 내용
• 힌트와 승패 관련 로직을 담당하는 Service 클래스

보다시피 전혀 논리적이지 않다. 클래스 내부를 들여다 보면 정말 기능을 '분리'만 시켜 놓았다. 또한, 내가 작성한 클래스이지만, 클래스 간 중복된 맥락이 있으며, 기준도 애매모호하다.

그리고 미션 중반까지만 해도 왜 캡슐화를 해야하는지 몰랐다. 캡슐화는 '하면 좋고 안하면 말고' 정도의 개념이었다. 친구에게 설명을 듣기 전까지는..

캡슐화의 개념과 필요성에 대해 들은 후에 getter와 setter을 알게 되었으며 public만 쓰던 접근제어자도 private을 쓰기 시작했다. 이후 미션에서는 모두 캡슐화를 신경쓰며 진행했다.

[1주차 공통 피드백]

---

2주차 미션을 공개하는 메일에 1주차 공통 피드백이 첨부되었다. '공통' 피드백이 맞나 싶을 정도로 나는 모든 케이스에 해당되었다. 피드백 내용 중 절반 이상이 컨벤션에 관련된 내용이었다. 이 중 몇가지를 골라보자면

컨벤션 관련 피드백

• 개발 도구의 code format 기능을 활용해라
  코드 포맷 기능은 몰랐어도 나름 철저하게 컨벤션을 지켰다고 생각했기에 '바뀔게 없을 텐데..?'라며 단축키를 눌러보았다.
  

  짜잔! 음? ㅎ..
  공통 피드백 보다는 이것도 모르는 지원자(본인)를 위한 배려라고 느껴졌다. 오죽했으면 인텔리제이, 이클립스 맥 윈도우별 단축키까지 설명으로 피드백주셨다.

• space(공백)도 convention이다.

  'for, while, if문 사이의 space도 convention이다.'

  방금 전 코드 포맷기능으로 확인할 수 있었다.

• 의미없는 주석을 달지 않는다.

  '변수와 메소드에 주석을 달기보다는 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다 '

• 값을 하드코딩하지 마라

  '상수를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라'

숫자 1과 2가 무엇을 뜻하는지 한눈에 들어오지 않는다.

README 관련 피드백

• 기능 목록 업데이트

  'README.md 파일에 작성하는 기능 목록은 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 갖기 보다 기능을 구현하면서 문서를 계속 업데이트한다.
  죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.'

  정곡을 찌른 피드백이다. README를 완벽하게 작성해야 한다는 부담감에 미션 기간 일주일 중에서 절반 정도를 README 작성하는데 소요했다. 또한, 작성한 README는 미션을 제출할 때까지 다시 읽어보는 일이 없었다.

• README.md를 상세히 작성

  'README는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 소개하는 문서이다.
  해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술하기 위해 마크다운 문법을 학습해보고 적용해 본다.'

[느낀점]

---

사실 1주차 미션을 진행하면서 힘들었던 점 세 가지를 뽑자면 다음과 같다.
1. 기능과 클래스 분리
2. git commit 작성
3. README 작성

세 가지의 공통점은 '처음 시도한 것'이다. 앞서 말한 것과 같이 java 문법만 공부하며 클래스와 기능을 분리할 필요가 없었고, git은 데스크탑과 노트북의 저장소로만 썼었기에 commit log를 남길 필요가 없었다. 또한 머릿속에 떠오르던 대로 코딩하는게 습관이 들어, 코딩 전에 전체를 설계하고 이를 글로 정리하는 README를 작성하는데 많은 애를 먹었다.

하지만 힘들었던 만큼 빠르게 발전할 수 있었다. 적어도 내가 무엇이 부족한지를 알 수 있었다. 다음 미션에서는 이보다 더 발전할 것이다. 잘하고 싶다.