[우테코 프리코스] 1주차 회고

이번 주에는 우아한테크코스의 첫 관문인 프리코스의 1주 차를 수행하였다. 총평을 해보자면, 좋은 코드를 만들기 위해 스스로 고민해 볼 수 있는 좋은 기회였고, 다수의 동료들로부터 코드 리뷰를 받는 엄청난 경험을 할 수 있어서 뜻깊었다.

 

프리코스의 주제 자체가 함께 성장하기이다보니 지원자들이 모인 디스코드에서는 1주 차임에도 불구하고 정보 공유와 토론이 매우 활발하게 이뤄졌다. 이런 정도면 주차가 지날수록 더 활발해질 것으로 보인다. 여기서 좋은 코드 작성을 위한 인사이트와 여러 꿀팁들을 얻을 수 있었다. 프리코스가 지나면 이런 기회가 사라질 것이라고 생각하니 아쉽기도 하면서 더 많이 가져가고 싶다는 욕심이 생겼다.

 

프리코스에서 기대했던 것 중 하나가 코드리뷰였다. 서로의 경험과 실력의 차이에 상관없이 서로 리뷰하고 의견을 나누는 경험이 새롭기도 하고 코드 리뷰에 대한 인상을 갖게 만들어 줄 것 같았기 때문이다. 실제로 1주 차 코드 리뷰를 받으면서 내가 몰랐던 부분들을 많이 알게 되었다. 지원자 모두들 코드 리뷰에 대한 열망이 컸는지 과제 제출 기한이 끝나자마자 리뷰 요청 스레드가 엄청 올라왔었다. 이러다 나는 코드 리뷰를 받을 수 있을까 걱정을 하기도 했지만 다른 분들이 먼저 리뷰해주시기도 하고 나도 먼저 리뷰를 하다 보니 맞리뷰를 해주시는 분들도 있고 순조롭게 진행되었다. 리뷰를 통해서 내가 몰랐던 부분을 깨우칠 수 있고 새로운 사실들을 알 수 있어서 매우 즐거웠다. 이번 주차 과제에서 부족했던 부분을 보완해야겠다는 다짐도 하게 되었다.

 

이번 회고를 하면서 정리하고 싶은 것 중에 하나가 이번 주차에서 부족했던 부분을 정리하기이다. 리뷰를 통해서 기록과 작성의 중요성을 느껴서 가능하면 최대한 글을 쓰는 습관을 들여야겠다고 다짐했다.

 

첫 번째로, 기능 구현 목록을 좀 더 철저히 작성하기이다. 기능 구현 목록 작성은 1주차 과제의 요구사항 중 하나였는데, 처음에 나는 이 요구 사항은 글쓰기 전의 초안처럼 생각하고 단순히 기능의 목록을 나열했었다. 그런데 다른 분들의 PR을 보니 엄청 세세하게 작성하기도 했고 객체나 애플리케이션 설계에 대한 내용을 세세하게 작성해서 내 것과 너무 비교되었다. 다음 주차에는 열심히 써보려고 한다.

 

두 번째로,검증 로직에 실수가 없도록 노력하기이다. 숫자 야구 게임에서 숫자를 입력받을 때 숫자가 중복되지 않음을 검증하기 위해서 1-2, 2-1, 3-1 번째 숫자끼리 같으면 예외를 발생하도록 설계했으나 마지막 조건을 빼먹으면서 구멍이 생겨버렸다. 이런 실수는 어떻게 해결할 수 있을까 생각해 보니 기능 구현 목록 작성 단계에서 깊이 생각해 보았다면 막을 수 있는 참사였지 않나 싶다.

 

세 번째로, 다음에는 MVC 도입을 시도해보려고 한다. 많은 분들이 이미 MVC 구조를 이용해서 하신 걸 보았고 구조화되어 있는 코드들은 역할과 책임이 나눠져 있어서 표준화되어 있고 코드를 처음 보는 개발자들도 쉽게 파악이 가능할 것 같았다. SRP에 따라 책임을 분리하자는 관점에서도 적합한 설계인 것 같다.

 

네번째로, DTO와 그냥 객체에 대해 탐구해보려고 한다. 리뷰에서 나온 내용 중 하나인데 DTO는 getter/setter 외에 다른 로직을 가질 수 있는가였다. 나는 가질 수 있다고 생각했었는데  DTO는 데이터 전송을 위한 객체이다 보니 그렇지 않을 수도 있지 않아서 생각이 필요해 보였다.

 

다섯 번째, 이중 for문 스트림 사용이다. 이번 과제 중에 반복문을 중첩해서 사용해야 할 경우가 있었다. 나는 이전부터 리스트를 순회할 때 스트림을 사용해 본 적이 있다. 근데 중첩된 반복문에 대해서는 어떻게 해야 할지 감이 잘 안 왔다. 그래서 다음번에는 반드시 시도해 보려고 한다.

 

여섯 번째, 1급 컬렉션 도입이다. 사실 이번 주차에 디스코드 함께 나누기 채널에서 자주 언급되었던 내용 중 하나였다. 컬렉션을 감싼 객체로써 해당 컬렉션에 대한 로직들을 담고 있다. 숫자 야구에서는 입력 숫자나 정답 숫자를 담는 객체로 사용했으면 어땠을까 하는 아쉬움이 있다.

 

일곱 번째, 뎁스 2 이하 유지이다. 나는 평소에 return early 패턴을 쓰다 보니 스스로 뎁스를 깊게 작성하지 않는다고 생각했었다. 그런데 그건 오만이었던 것 같다. 이중 for문만 해도 뎁스가 3을 넘어간다. 이중 for문 사용이 어쩔 수 없다고 스스로 타협하지 않았나 싶다. 이것도 이번에 고쳐야 할 습관이다.

 

여덟 번째, 한줄에 "."이 많으면 의심하기이다. 코딩 컨벤션 중에 한 줄에 "."이 하나가 되도록 유지하라는 것이 있다. 점이 많다는 것은 기차 충돌(train wreck)등 문제가 있을 수도 있으니 항상 조심해야 할 것 같다.

 

마지막은 정규식 사용 시 Pattern 객체 캐시화이다. 과제에서 정규식 사용 시 String의 matches() 메서드를 사용했는데 matches()는 내부적으로 Pattern과 Matcher 객체를 생성한다. 나는 자바에서 정규식 사용 시 두 객체를 사용한다는 것을 알고 있었지만 코드 양을 줄여보겠다고 matches()를 썼다. 그런데 matches()를 사용할 때마다 Pattern 객체가 계속 생성된다고 한다. Pattern 객체는 생성 비용이 크기 때문에 동일한 정규식인 경우 static 변수 등으로 캐시해 놓고 사용하면 좋다고 한다.

 

쓰고 보니 이만큼 많은 새로운 정보들을 얻었다는 것을 실감하게 됐다. 좀 더 많은 사람들의 리뷰를 받는다면 더 많은 정보들을 알게 될 수 있을 것 같다. 내 리뷰를 받는 것도 좋은데 다른 사람 리뷰를 읽어보는 것도 새로운 사실을 알게 될 수 있는 좋은 계기가 될 것이다. 내 리뷰는 내 코드만을 바탕으로 하지만 다른 사람들의 리뷰는 다른 사람의 코드를 바탕으로 하니까 말이다. 리뷰를 해주고 리뷰를 읽는다는 경험이 얼마나 소중한 경험인지 알 수 있었던 한 주었다.