우아한테크코스 7기 프리코스 중간 소감
우아한 테크코스(이하 우테코) 프리코스 3주차 미션을 마치고 작성하고 있습니다.
저는 우테코에 대해 큰 기대를 하고 있었습니다. 어디에 나와있는 것은 아니지만 개발 지망생들에게 알려진 바로는 부트캠프 1티어 중에 1티어라고 알려졌기 때문이죠. 그 중에서도 강점은 코드리뷰 시스템에서 드러난다고 들었습니다. 이러한 우테코의 코드리뷰 시스템을 프리코스를 하며 작게나마 체험해볼 수 있었습니다.
프리코스는 크게 과제, 코드 리뷰로 나눌 수 있습니다. 이 중에서 과제만 필수이고 코드리뷰는 선택입니다. 하지만 프리코스를 진행하면서 있었던 대부분의 성장은 코드리뷰 활동에서 이뤄졌다고 생각합니다. 1주차 과제를 보면 지금의 코드와 엄청난 차이가 느껴지는데요.
3주차 미션을 마친 시점에서 제가 이 코드를 피드백해보자면
1. Service에서 상태를 보관하고 있어 stateless한 service 계층을 권장하는 계층형 아키텍처의 입장에서 봤을 때 좋지 않아보입니다.
2. 배열을 사용하셨는데 배열보다는 컬렉션을 사용하시는게 자바에서 지원하는 메소드를 더 유연하게 사용할 수 있기 때문에 권장드립니다.
3. service에서 view를 불러오고 있어 계층형 아키텍처의 분리 원칙을 위반하고 있습니다. 각 계층의 역할을 구분하고 의존하는 방향을 일정하게 유지해야합니다.
4. 코드의 줄이 길어지면 다음줄로 분리해 가독성을 좋게하는 것이 좋을 것 같습니다.
5. 코드들이 딱 붙어있는데 의미 별로 개행을 넣으면 이해하기 더 쉬울 것 같습니다.
6. 한 메소드에 로직이 많이 들어있습니다. 분리했으면 좋겠습니다.
7. 중간에 나오는 2같은 경우에도 상수로 처리했으면 좋을 것 같습니다.
이정도가 될 것 같습니다. 이제와서 보니 엄청 부끄러운 코드였네요.
반면 현재의 코드는 어떨까요?
같은 service 클래스를 가져와봤습니다. 위에서 보였던 1주차 service 클래스는 service 클래스 안에서도 일부를 가져온 것이었는데요. 그보다도 간결한 느낌입니다. 코드가 이렇게 간결해진 이유는 역할에 따라 service 클래스를 나누고 상당한 분량의 비지니스 로직을 domain으로 옮겼기 때문입니다. 과제만 풀고 피드백을 통해 성장하지 않았다면 이러한 차이는 없었겠죠.
그렇다면 코드리뷰는 어떻게 이뤄졌을까요?
코드리뷰(피드백)는 공통 피드백과 개인 코드리뷰로 나눠지는데요, 공통 피드백은 매주 미션이 끝나고 나서 우테코 코치분들께서 풀 리퀘스트를 보시고 교육생 전반적인 피드백을 주시는 형태입니다. 그러다보니 각자 해당하는 부분도 있고 아닌부분도 있어서 제게 도움되는 부분만 별도로 정리했습니다.
다음으로 개인 코드리뷰인데요. 사실 우테코에는 개인 코드리뷰를 위한 시스템이 별도로 존재하진 않습니다. 따라서 본인의 코드에 리뷰를 받기 위해서는 커뮤니티에서 홍보를 해야합니다. 처음엔 제 코드를 남에게 보여주는 것이 부끄러워서 주저했었는데 막상 제가 코드리뷰를 하러 돌아다녀보니 저랑 비슷하신 분들도 많더라고요!(물론 잘하시는 분들도 많았습니다!)
그래서 용기를 내 코드리뷰를 시작해보니 더 나은 코드를 위해 많은 분들의 아낌없는 조언을 엿볼 수 있었습니다.
그 중 새로운 방법(디자인 패턴 및 기능)에 대한 키워드를 알게 되면 어떤건지 찾아보고, 왜 쓰는지 판단해보고 그것에 대한 개인적인 생각을 정리해봤습니다. 그리고 그렇게 정리한 '방법'을 다음주차 미션에 사용해보는 과정을 통해 가장 많이 성장할 수 있었습니다.
이런 과정이 바로 우테코 7기 설명회에서 말했던 메타인지를 쌓는 과정이었던 것 같습니다. 설명회에서 말한 메타인지는 문제의 정답을 찾는 것이 아닌 "문제를 풀기 위한 방법을 찾는 것 또는 그 방법이 맞는지를 찾는 것"이었습니다. 되돌아보니 그동안 제가 개발 공부를 하며 주로 관심있었던 것은 문제의 정답 즉, 이 문제를 어떻게 구현하지가 주 관심사였습니다.
하지만 우테코 프리코스에서는 '어떻게 구현해야 이 문제가 수월할까'라는 한층 고차원적인 고민을 하게 만들어줬습니다. 이러한 고민을 갖게된 것만으로도 앞으로의 개발자 커리어에 있어서 도움이 많이 될 것 같습니다.
마지막으로 우테코에서 아래 4가지 질문을 던졌는데 대답하고 마무리하고자 합니다.
- 테스트를 작성하는 이유는 뭐라고 생각하시나요?
예전에는 테스트 작성없이 postman을 통해서 완성된 api만을 테스트 했었는데 테스트 코드를 작성해보니 안정감이 다릅니다. api 테스트만을 진행했을 때는 여러 테스트를 한꺼번에 진행해볼 수 없었고, 하나하나 쳐보는 수밖에 없었습니다. 그러나 테스트 코드로 진행한 테스트는 빠른 시간 안에 모든 예외처리, 경계값 분석 등이 가능했습니다. 또한, 테스트 실패가 떴을 때도 결과값이 한꺼번에 나오기 때문에 어디와 연관되어 있는지 바로 알 수 있는 점도 장점입니다. 무엇보다 하나를 바꿨을 때 파생되는 문제들을 걱정해야 했던 과거와 달리 지금은 테스트를 한번 만들어두면 그 다음부터는 테스트 관련해서는 신경을 쓰지 않아도 된다는 점이 가장 좋은 것 같습니다.
- 지원서에 작성한 목표를 얼마나 달성하고 있다고 생각하나요? 그 이유는 무엇인가요?
저는 지원서에 세 가지 목표를 작성했습니다. 코드리뷰를 통한 성장, 함께 성장할 동료 사귀기, 그리고 함께 개발하고 싶은 동료 되기입니다.
첫째, 코드리뷰를 통한 성장입니다. 그동안 제대로 된 코드리뷰를 경험하지 못한 것이 아쉬울 정도로 그 효과를 절실히 느끼고 있습니다. 코드리뷰를 하면서 새로운 기능과 디자인 패턴을 배우고 적용해보았고, 리뷰를 받으며 부족한 부분에 대한 피드백으로 발전했습니다. 1주차, 2주차, 3주차 코드를 비교하며 제 성장을 확인할 수 있었고, 4주차에도 이러한 성장이 계속될 것이라 확신합니다.
둘째, 함께 성장할 동료 사귀기입니다. 프리코스가 온라인으로 진행되는 점이 아쉬웠습니다. 온라인에서 많은 활동을 했지만, 직접 얼굴을 마주하고 대화를 나누는 오프라인만큼의 친밀감을 느끼기는 어려웠습니다. 본 과정까지 함께 참여하여 이 목표를 꼭 달성하고 싶습니다.
마지막으로, 함께 개발하고 싶은 동료 되기입니다. 이번 프리코스 커뮤니티에서 활동하면서, 제가 동료로 삼고 싶은 사람은 개발을 잘하거나 열심히 하는 것이 ‘눈에 띄는 사람’이었습니다. 저 또한 그런 사람이 되고자 노력했습니다. 지난주 코드리뷰를 20곳에 남길 정도로 열심히 참여했습니다. 그 결과 꼼꼼하게 봐주셔서 감사하다, 먼저 리뷰 남겨주셔서 고맙다 등의 감사인사를 받을 수 있었고 제 목표의 일정부분을 달성했다고 생각합니다.
- 지원서에 작성한 목표를 변경해야 한다고 생각하시나요? 그렇다면 그 이유와 어떤 목표로 변경하고 싶으신가요?
제가 설정한 목표들은 정량적으로 측정하기 어려운 정성적인 목표입니다. 이는 제가 개발자로 성장하는 데 필수적이라고 판단한 것들입니다. 따라서 목표를 변경하기보다는 이를 달성하기 위해 노력하겠습니다.
- 프리코스를 진행하면서 눈에 띄는 변화나 깨달은 점이 있나요?
그동안은 프로젝트의 구현에만 몰두하는 현재 지향적인 고민을 하고 있었습니다. 하지만 이제는 "어떻게 하면 수정에는 닫히고 확장에는 열려있을 수 있을까?", "이 클래스가 단일 책임 원칙을 지키려면 어떻게 해야 할까?" 같은 미래 지향적인 고민으로 바뀐 것이 가장 큰 변화입니다. 처음에는 이런 고민 없이도 그럴듯한 애플리케이션을 만들 수 있어서 그 필요성에 의문이 들었습니다. 하지만 실제로 적용해보니 그 이유를 깨달을 수 있었습니다. 예를 들어, 이번에 도입한 불변 객체의 경우, 속성값을 변경하려면 생성자를 통해 새로운 객체를 만들어야 했습니다. 이를 통해 예상하지 못한 변경을 방지할 수 있었죠. 또한, 도메인 외부에서 속성값을 변경하려고 하면 컴파일 에러가 발생하므로, 관련 비즈니스 로직이 자연스럽게 도메인으로 이동하는 장점도 있었습니다. 이러한 학습 과정을 통해 제 자신의 성장을 실감할 수 있었습니다.
아직 4주차 미션이 남았는데 마지막까지 과제 풀이와 코드리뷰를 성실히 임하면서 더욱 성장할 수 있었으면 좋겠습니다!