우아한테크코스 5기 프리코스 1주차 회고

이번 우아한테크코스 5기 모집 전형에서는 모든 지원자에게 4주간 프리코스를 경험할 수 있는 기회를 준다.
우테코에 합격하여 공부하고 싶은 맘이 가장 크지만, 프리코스 자체만으로도 벌써 소중한 경험인 듯하다. 작은 것부터 혼자 해결해나가면서 깊게 고민해볼 수 있다는 점이 즐겁다! 결과에 관계없이 더 많이 성장할 수 있도록 남은 기간도 즐겨보려고 한다.

미션 제출 내용 보기

🚀 1주차 미션 소감

git, 과정별 언어, 미션 사이클에 익숙해지기 위한 시간이었다.
주어진 과제 레포지토리를 fork, clone하고 7개의 문제를 구현 및 테스트를 진행한 뒤 pull request로 제출하였다.
이 과정에서 기능 단위로 commit할 것 역시 요구되었다.

진행 소감은 과제로 제출하기도 했고, 혼자만의 회고보다는 다른 이에게 설명하듯이 이야기하고 싶어 다른 문체(?)로 적어보았다.

커밋을 “잘” 하자

커밋을 형식에 맞춰 작성해보는 경험을 처음으로 해보았습니다. Angular js의 커밋 컨벤션을 참고해서 커밋 유형과 범위를 구분하니 변경 사항을 보다 쉽게 파악할 수 있음을 알게 되었습니다. 그리고 짧고 명확하게 커밋 메시지를 작성하는 것이 중요하지만 쉽지 않았는데, 미션을 마무리할 때 즈음에는 조금이나마 익숙해지지 않았나 싶습니다.
하지만 "기능 단위로 커밋"을 해야 하는 요구사항을 지키는 일에는 조금 미흡했던 것 같습니다. 처음에는 "feat" 타입이 이미 기능 구현 단위를 명시해주기 때문에 그 외의 문서 수정을 비롯한 자잘한 변경 사항 또한 다른 타입(docs, chore …)으로 지정한다면 모두 커밋으로 남겨도 된다고 생각했습니다. 그런데 그렇게 세세하게 커밋하다보니 기능 중심의 히스토리를 한눈에 파악하기 어려워졌습니다. 작업 순서의 일관성이 없는 것 역시 커밋 내역에 드러났다고 생각합니다.
다음 미션에서는 작업의 순서를 지키며 커밋하는 단위를 좀 더 명확히 해서, 파악하기 쉬운 커밋 히스토리를 남길 수 있도록 해야겠습니다.

클린 코드와 객체 지향

문제를 해결할 때 가장 중점에 둔 것은 각 메소드가 한가지 일만 담당하도록 하는 것이었습니다. 그 외에도 우테코 클린 코드 체크리스트를 참고하는 등 이전에는 몰랐던 원칙을 적용하려고 노력했습니다. 그동안의 저는 “클린 코드”를 피상적으로만 이해하고 그 단어를 너무 쉽게 사용해왔다는 생각이 듭니다. 앞으로도 클린 코드를 만들기 위한 여러 원칙과 이유들을 제대로 습득해서 진정한 리팩토링을 하고 싶습니다.
문제6, 7번은 보다 객체 지향적인 관점에서 구현해보려고 했습니다. 하나의 클래스에서 결합도가 낮은 여러 메소드를 구현하기 어렵기도 했고, 주어진 요구사항이 실제로 어떤 서비스에 포함된 기능이라면 확장 가능성이 중요하다고 생각했기 때문입니다. 이를 통해 전에는 몰랐던 일급 콜렉션을 만드는 등 전에는 해보지 못한 다양한 시도를 해볼 수 있었습니다. 여러 클래스를 정의하고 사용하는 과정에서 출력 인수를 지양해야한다는 점 등 미처 생각하지 못했던 클린 코드 원칙 또한 알게 되었습니다.
그러나 말 그대로 주어진 “기능 요구 사항”에 비해 필요 이상의 규모로 설계한 것은 아닌지 고민이 됩니다. 성급하게 클래스를 정의하는 과정에서 오히려 클린 코드 원칙을 저해하기도 했던 것 같습니다. 그래서 리팩토링 하기 전에 구현 로직 자체가 더 단순해질 수는 없는지 더 철저하게 생각한 뒤 진행해야겠다는 생각 또한 들었습니다. 이러한 점에 대해서는 앞으로 열릴 커뮤니티에서 다른 참여자 분들과 의견을 나눠보면 배우는 점이 더 많아질 것 같아 기대가 됩니다.

TDD

프리코스 덕분에 처음으로 테스트 도구를 사용해볼 수 있었습니다. 그동안은 기능 단위로 테스트를 한다고 해도, 콘솔 창에 값을 출력해보는 방식으로만 진행했습니다. 그러다보니 main 메소드에 직접 테스트 케이스를 썼다 지웠다 반복하는 등 불편한 점이 많다보니 체계적으로 테스트하기 어려웠고 대충 넘어갈 때도 많았습니다. 그런데 이번에 jUnit을 사용해보니 테스트 중심의 개발을 하기에 훨씬 수월하다는 것을 느꼈습니다. TDD 개념과 테스트 도구의 존재에 대해서는 정보처리기사 공부를 하면서 이론적으로만 접한 상태였는데, 경험을 통해서 이를 더 명확히 알 수 있는 계기가 되었습니다. 역시 직접 경험하고 부딪히는 것이 중요하다는 생각이 듭니다.

💻 외부 피드백

공통 피드백

1주차 미션 제출이 완료된 뒤, 공통 피드백을 받아볼 수 있었다. (피드백의 내용에도 또 한번 우테코에 감동)
과제를 진행하며 어렵게 느꼈던 점들이 모두 피드백에 담겨 있어서 앞으로도 스스로 어렵게 느끼는 부분일 수록 더 확실히 짚고 넘어가야겠다고 생각했다.
이를 테면 space와 tab의 혼용 같은 것 말이다. 아주 예전에 그 둘의 차이를 접했지만 잊고 있었다. 그런데 이번에 작업한 내용을 github에서 보니 들여쓰기가 엉망으로 되어있어 놀라 찾아보니 바로 그 문제 때문이었다. tab을 space 몇 개로 인식할지는 환경에 따라 다르기 때문에, 들여쓰기를 space로 통일하기 위해 IDE에서 설정해주는 과정을 거쳤다.
commit의 내용을 수정하기 위해 rebase를 사용해보았던 것 역시 마찬가지였다.

코수다

또한 코치들과의 대화시간인 코수다 역시 진행되었는데 많은 인사이트를 얻을 수 있는 시간이었다.
특히 인상깊었던 것은 "현실 세계를 반영한 문제 해결"에 대한 이야기였다. 일부러 스스로 판단할 수 있도록 제한사항을 비롯해 빈틈이 있는 문제를 내는데, 현실 세계의 요구사항 또한 빈틈이 아주 많다고 하셨다. 알고리즘이나 시험 문제 풀이라는 생각에 갇히지 말고 현실 세계에서 문제 해결을 하듯이 스스로 생각해보면 좋겠다는 점이 아주 인상깊었다.
나 같은 경우에도 알고리즘 역량이 부족해서였기도 했지만 6번과 7번 문제를 해결할 때 실제 서비스 구현의 일부라고 생각하고 진행해보고 싶었기 때문이다. 그러나 제출 후 다른 분들의 코드를 보니 훨씬 적은 코드 수로 구현을 하신 것을 보고 내가 방향을 엉뚱하게 잡았나 주눅들기도 했다. 하지만 코치님의 말씀을 듣고 주눅들 필요가 없다는 것을 깨달았다. 내가 맞다고 생각한 방향에서 "잘" 구현하는 것이 더 중요한 것 아닐까. 그리고 그렇게 하면서 반대로 미흡한 점도 많이 발견되었지만... 그래서 더 성장할 수 있는 발판을 스스로 만들 수 있지 않나 싶다.

피어리뷰

피어리뷰는 1주차 미션이 종료된 어제, 커뮤니티를 통해 시작되었다. 가장 기대되는 활동 중 하나이기도 하다.
이 글을 마무리한 뒤 나도 피어리뷰 활동에 참여해보려고 한다!!

✅ 2주차 미션에서 보완할 점

1주차에서 스스로 느낀 점과 외부적 피드백을 2주차 미션에 반영하고자 한다.

• 이번 미션이 무엇을 위한 미션인지, 어떤 것에 집중해야하는지 생각하며 진행하자
• 커밋 컨벤션, 커밋 단위 등에 대한 원칙을 정확히 정리해두자
• 어떻게 구현할지 충분히 고민해보자 (성급하게 구현하려고 하니 구현하는 도중 기능목록을 수정하기 바빴다.)
• 처음에는 쭉 코딩해보고 이후에 클린 코드를 위한 리팩토링을 진행해도 좋다.
• 방어적 코딩과 TDD를 적극 적용해보자
• 학습 과정을 잘 회고할 수 있도록 매일 정리된 기록을 남기자 (1주차에는 아무렇게나 메모해놓기만 했다)
• 현실 세계를 반영한 문제해결을 해보자