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

1차 코딩테스트 이후에 진행했던 프리코스 후기입니다.

 

---

 

프리코스는 3주동안 과제가 주어지며 이 과제를 요구사항에 맞게 구현을 하고 제출해야 하는

우아한 테크코스 선발 과정 중 하나입니다.

 

 

 

1주차: 숫자 야구 게임

 

1주차는 숫자 야구 게임이 나왔습니다.

 

비교적 간단해 보였지만 막상 구현을 해보니 각종 요구사항이 있어서 실제론 간단하지 않았습니다...

 

저는 1주차는 최대한 요구사항을 지키는 것에 중점을 두어 기능을 구현하자라고 생각했습니다.

그래서 컨벤션 준수, 기능 단위 커밋, 하나의 메소드에는 하나의 기능만 구현

이 세 가지에 초점을 두고 코드를 만들었습니다. 

 

 

각종 요구사항들

 

 

 

1주차 때는 무엇을 배웠는가?

 

• 자바 컨벤션과 커밋 로그 컨벤션을 배웠습니다.
  
  프로젝트를 진행할 때나 특히, 알고리즘 공부를 할 때 네이밍에 크게 신경을 쓰지 않고 진행해왔습니다.
  그동안 오로지 나만 이해가 가능한 변수, 메소드명을 사용해왔고 커밋 로그도 아무 생각없이 적어왔습니다.
  이러한 행위들은 팀 프로젝트에 해가 되는 좋지 않은 습관이라는 것을 알게되었고 고치게 되었습니다.
  
  
• 기능 구현 전 기능 목록을 정리하고 기능 단위 커밋 하는 것을 배웠습니다.
  
  기능 목록을 정리하고 그에 따라 기능 단위로 커밋 하면서 중구난방으로 코드를 구현했던 예전과는 달리
  하나씩 집중하여 기능 구현을 하였습니다. 그러다 보니 효율적으로 작업이 진행되었습니다.
   

 

 

 

 

 

 

 

 

2주차: 자동차 경주 게임

 

2주차는 자동차 경주 게임이 나왔습니다.

 

 

n대의 자동차 이름을 입력하고 시도 횟수를 입력받아 횟수만큼 이동을 시도하여 최종 우승을 한 자동차를 가려내는 게임이었습니다.

 

 

 

 

1주차 때도 프로그래밍 요구사항에 지키면서 코드를 만드는게 힘들었는데 2주차는 그것보다 더 힘든 요구사항이 추가되었습니다.

 

2주차 때 저는 1주차 때 많이 적용해보지 못했던 객체지향 관점에서 코드를 구현해보자라고 생각했습니다.

그래서 객체지향에 대해 많이 찾아보게 되었고 그 중 객체지향 생활체조 원칙을 지켜보기로 했습니다.

 

 

 

 

2주차 때는 무엇을 배웠는가?

 

 

• 왜 원시값과 문자열을 포장하고 일급 컬렉션을 사용하는지 알게 되었습니다.
  
  
  객체지향 생활체조 원칙에는 원시값과 문자열을 포장하고 일급 컬렉션 사용하라고 적혀있습니다.
  그 이유에 대해 찾아보고 공부를 하였지만 머리로는 이해해도 뭔가 크게 와닿지 않았습니다.
  그러나 이번에 제가 직접 사용을 해보면서 이렇게 사용하면 어떤 점이 좋은지를 깨닫게 되었습니다.
  
  
  
  1. 유효성 검증에 대한 로직을 나누어서 관리를 할 수 있습니다.
  
  1주차 때 저는 입력에 대한 유효성 검증을 InputValidator라는 유틸 클래스를 만들고 그곳에서만 관리하였습니다.
  
  숫자 야구 게임의 경우 검증하는 로직이 그렇게 많지 않아 괜찮았지만
  만약 프로그램의 크기가 커지고 입력을 하는 곳이 많아질수록 코드량은 더 늘어나고 클래스가 무거워질 것입니다.
  
  그러나 자동차 경주 게임의 경우 저는 Car 클래스와 Cars 클래스를 만들고 그 안에 유효성 검증에 대한 메소드를 추가하여 해당 객체가 만들어지기 전에 검증을 하였습니다. 
  그리하여 검증 로직을 나누어서 관리를 할 수 있고 프로그램을 위헤 자신만의 자료구조를 만들수가 있었습니다.  
  
  
  
  
  2. 상태와 행위를 한 곳에서 관리를 할 수 있습니다.
  
  마찬가지로 자동차 경주 게임을 예로 들면
  
  Car 리스트를 변수로 두고 있는 Cars 일급 컬렉션에서 Car 리스트(상태)를 다루는 우승자를 뽑는 메소드(행위)를 같이 관리를 할 수 있습니다.
  
  int attemptNumber 라는 시도 횟수 변수를 포장하고 있는 AttemptNumber 클래스에서 int attemptNumber(상태)를 이용한 시도 횟수만큼 자동차 이동을 시도하는 메소드(행위)를 같이 관리할 수 있습니다.
  
  다만 지금와서 보니 Car 클래스 내의 name이나 position도 충분히 클래스로 관리를 할 수 있었을텐데 그러지 못한게 아쉽네요..
  
  

 

 

 

jojoldu.tistory.com/412

일급 컬렉션 (First Class Collection)의 소개와 써야할 이유

일급 컬렉션에 대한 자세한 내용은 위 블로그를 참고하시면 될 것 같습니다. 저도 큰 도움을 받았습니다.

 

 

 

 

 

 

 

3주차: 지하철 노선도 

 

3주차 과제는 지하철 노선도 미션이 나왔습니다. 

 

1기 3주차는 로또, 2기 3주차는 블랙잭이 나왔기에 이번 미션은 블랙잭 아니면 새로운 미션이 나오지 않을까 생각을 하였는데 새로운 미션이 나왔습니다!

 

프로그래밍 요구사항은 1, 2주차와 다르지 않았습니다.

1, 2기 때는 메소드 10라인이나 들여쓰기 depth를 1까지만 허용하는 극악무도(?)한 요구사항이 있던 것으로 기억하는데 이번에는 그대로였습니다.

 

다만 제 기준으로 구현해야할 기능량이 극악무도했습니다..

물론 1, 2주차에 비하면 상대적으로 많다는 것이었고 잘하는 분들은 금방 구현을 하실 수 있지 않나 싶습니다..

 

3주차 때는 메일에 '여러 개의 클래스를 분리한 후 서로 관계를 맺어 하나의 프로그램을 완성하는 경험'을 목표로 한다고 적혀있었기에 저는 MVC 패턴을 제대로 적용해보기로 했습니다.

각각의 책임을 가지고 있는 클래스를 나누고 그 클래스끼리 협력을 통해 프로그램을 완성시키도록 하였습니다.

 

 

 

 

 3주차 때는 무엇을 배웠나?

 

 

 

 

• stream이나 Collections 메소드와 같이 자바 API 사용 및 enum을 사용해보면서 자바에 대해 더 알게 되었습니다.
  
  
  같은 역할을 하는 코드라도 stream이나 이미 자바에서 만들어져있는 메소드를 사용해보면서 코드량을 훨씬 줄여보았습니다. 
  
  가령 stream 메소드 체이닝을 통해 Station 리스트를 간단하게 만든다든지
  리스트 내에 객체 중복 체크를 위해 contains 메소드를 활용하여 한 줄로 코드를 끝내보는 등
  자바를 훨씬 더 자유롭게 사용해본 것 같습니다.
  
  또한 이번 과제에서 제일 어려웠던 점이 메뉴를 어떻게 구현할까 하는 것이었습니다.
  메뉴 입력을 어떻게 다루며 검증은 또 어디서 해주는 것이 좋을까 하고 계속 고민하였습니다.
  
  다른 분들의 코드를 참고하니 enum을 사용하여 관리하는 경우가 많았고 그때부터 enum에 대해 공부하기 시작했습니다.
  특히, 우아한 형제들 기술 블로그에 이동욱님이 작성하신 글이 크게 도움이 되었습니다.
  
  
  저는 이런식으로 MainMenu에 대한 enum과 그 메뉴를 선택했을 때 나오는 SubMenu에 대한 enum 타입을 만들어 사용하였고 이에 따라 검증 코드도 같은 곳에서 관리할 수가 있었습니다.
  
  
  
  

woowabros.github.io/tools/2017/07/10/java-enum-uses.html

Java Enum 활용기 - 우아한형제들 기술 블로그

 

 

 

 

• 상수 처리를 어떻게 할 것인가에 대해 고민을 하게 되었습니다.
  
  
  3주차에는 입, 출력과 관련된 메시지 상수가 굉장히 많았습니다.
  이것을 어떻게 처리하면 좋을 것인가를 두고 많은 고민을 하였습니다.
  처음에는 인터페이스로 따로 빼서 이걸 view 클래스가 상속하면 되지 않을까하고 고민도 하였고
  또는 클래스로 따로 빼서 한 곳에서 관리하는 것이 좋지 않을까라고 생각하였습니다.
  결국 저는 따로 빼지 않고 상수가 쓰이는 InputView, OutputView 클래스 내에 두고 쓰는게 알아보기 더 편하지 않을까 싶어 그대로 두었습니다만 여전히 무엇이 더 좋은지에 대해서는 알 수가 없네요..
  
  다만 이렇게 하다보니 각각의 메뉴 별로 중복되는 상수가 많다고 생각하여 역, 노선, 구간이 들어갈 부분만 %s로 처리하고 printf를 사용하였는데 지금 생각해보니 가독성에 크게 좋지 않은 것 같다고 생각도 들어 조금 아쉽습니다.

 

 

 

 

• 리팩토링이 재밌어졌습니다.
  
  
  제가 프로그래밍에 흥미를 지니게 된 계기는 '기능 구현이 재밌어서' 였습니다.
  내가 입력한 대로 무엇인가 만들어지고 내가 만든 로직에 맞게 기능이 구현 되는 것이 너무나도 재밌었습니다.
  그러다 보니 그저 기능 구현하는 것에만 목적을 두었고 부끄럽게도 에러가 발생하지 않는 이상 이미 완성된 코드를 다시 보는 일이 거의 없었습니다.
  굳이 리팩토링을 해야돼..? 와 같은 어리석은 생각을 가지고 있었습니다.
  
  그러나 1주차, 2주차동안 리팩토링을 계속 하였고
  특히 마지막 3주차의 경우 초반 설계를 잘못하여 기능 구현을 다하고 나서 리팩토링 작업을 앞 과제에 비해 많이 했습니다.
  신기하게 코드란게 계속 보면 볼수록 부족한 점들이 보이더라구요..
  그렇게 중복된 코드를 제거하여 하나로 통합시키거나 비슷한 메소드를 가진 클래스를 인터페이스로 빼서 상속시키는 작업을 하다보니 리팩토링이란 작업이 기능 구현만큼 재밌다는 것을 느끼게 되었습니다.
  
  

 

 

마무리

 

우선, 저에게 있어서 프리코스는 개발자로써 성장할 수 있는 소중하고 값진 기회였습니다.

부족한 점이 무엇인지 알게 되었고 많은 것을 배우게 되었습니다.

동시에 잘하는 분들이 정말 많다는 것을 다시 한번 깨닫게 되었네요.

또한 이런 분들과 같이 공동의 목표를 가지고 공부할 수 있다고 생각하니 더욱 더 우아한 테크코스에 참여하고 싶다고 느껴지는 시간이었습니다.

마지막으로 남은 코딩테스트를 열심히 준비하여 후회없이 마무리하고 싶습니다.

프리코스를 참여하고 진행하신 모든 분들 수고하셨고 감사드립니다.