<div id="readability-page-1" class="page"><div><h2 id="코드-리뷰어">코드 리뷰어<a href="#코드-리뷰어"><i></i></a></h2><p><code>2022 공채 신입 코드리뷰어</code> 로 활동하고 있다. 조직에 합류하기 전 인턴 때 코드 리뷰를 받으면서 많이 성장했다고 느꼈기에 나도 되돌려주고 싶었다. 코드 리뷰는 대부분 업무시간을 할애하긴 하지만, 새벽에 리뷰를 하는 경우도 있어 체력적으로 힘이 들었는데, 뉴크루가 성장하는 모습이 너무 대놓고 보여서 뿌듯함을 느낀다. 리뷰이가 앞으로 조직에서 함께할 동료이기에 더 중요하게 생각한 것 같다. 리뷰이가 다른 조직이었다면 시간을 이만큼 들일 수 있었을까 싶기도 하다. 이번에 활동을 하면서 남긴 리뷰들을 잘 정리해서 템플릿 처럼 활용할 수도 있을 것 같다. (너무 공장 마인드인가 ?)</p><p>평온한 리뷰어였던 나에게 긴장감을 주는 활동이었다. 코드 리뷰어 활동은 좋은 경험인 것 같아, 조직 내 후기를 공유할 예정이다.</p><h2 id="업무-고민">업무 고민<a href="#업무-고민"><i></i></a></h2><p>코드 리뷰어를 통해 누군가의 성장을 도왔지만, 정작 본인의 일은 잘 쳐내지 못했다. 이슈 하나 처리하는데 너무 오래 걸리고 있다. 피로도가 쌓여서 <code>업무 집중도</code> 가 많이 떨어진 탓일까. 내가 일에 몰입하지 못한 것도 원인이겠지만, <code>조직 내 코드 리뷰</code> 도 한 몫한 것 같다. 공채 코드 리뷰어를 진행하던 습관 때문인지, 조직 내 코드 리뷰에 시간이 많이 소모했던 것 같다. 심한 날은 ‘내 직업은 <code>코드 리뷰어</code> 인가?’ 하는 생각도 들었다. 물론 해당 코드는 더 좋아지긴 하지만서도.. <code>가성비(?)</code> 가 안 맞는 것 같다. 코드 리뷰에 노하우가 더 필요한 걸까. <code>트레이드 오프</code>가 필요해 보인다.</p><p>어쨌든! 2월에는 일에 더 몰입을 할 수 있었으면 좋겠다.</p><h2 id="도메인">도메인<a href="#도메인"><i></i></a></h2><p>파트원과 코드 리뷰를 하다가 내가 <code>도메인</code> 이라는 용어 개념을 명확하게 알지 못하구나 라는 것을 깨달았다. 그래서 <code>도메인</code> 용어에 대해 준비해서 50분간 발표했다. 도메인에 대해서 조사하다보니 우리 소프트웨어는 정말 문제의 영역과 기술적인 부분을 분리해서 생각해야 할 필요성을 느꼈다. 도메인을 주제로 이야기하다가 자연스럽게 <code>유지보수</code> / <code>도메인 모델</code> 까지 언급이 있었다.</p><p>그렇다. <code>사실 이건 DDD 스터디를 팔기 위한 빌드업이었던 것(?)</code></p><h2 id="사내-스터디">사내 스터디<a href="#사내-스터디"><i></i></a></h2><h3 id="대용량-서비스를-위한-아키텍처-with-redis-패캠">대용량 서비스를 위한 아키텍처 with Redis (패캠)<a href="#대용량-서비스를-위한-아키텍처-with-redis-패캠"><i></i></a></h3><p>위 강의를 듣고 토론하는 식으로 조직 내에서 스터디를 했다. 강의는 이론과 실습을 병행하는 식으로 이루어져 있는데, 스터디가 끝날 때 대용량 서비스를 위한 전문가가 되지는 못했다. 단지 어떠한 것들이 있는지 굵직한 것들에 대한 버킷이 생겼다고나 할까. 다음에 해당 내용을 접하면 다시 찾아볼 법한 레퍼런스 정도 얻어간 것 같다. 실습을 따라 하면서 막히는 부분도 있었는데, 커뮤니티가 없는 패캠의 구조도 아쉬웠다. (인프런에는 강의마다 질문하는 곳이 있음. 패캠에서는 내가 못 찾은 걸까?)</p><h2 id="읽은-책">읽은 책<a href="#읽은-책"><i></i></a></h2><h3 id="1-만들면서-배우는-아키텍처">1. 만들면서 배우는 아키텍처<a href="#1-만들면서-배우는-아키텍처"><i></i></a></h3><ul><li>계기<ul><li>작년에 <code>클린아키텍처 서적 스터디</code> 를 했었는데, 아쉬운 부분이 있었다. 개념적으로는 알겠는데, 실질적인 코드의 부재가 아쉬웠었다. 조직의 아키텍처와도 약간 거리가 있어 차츰차츰 머리속에서 잊혀지고 있었다. 그러다 작년 말에 아는 형의 소개로 <code>만들면서 배우는 아키텍처</code> 책을 알게 되었고, 읽게 되었다.</li></ul></li><li>내용<ul><li>이 책의 내용은 간단하다. 헥사고날 아키텍처를 직접 코드로 만들어나간다. <code>도메인 모델</code> 부터 시작해서 <code>유스케이스</code> 구현. <code>유효성 검증</code> 도 다루고 있으며, <code>웹/영속성 어댑터</code> 도 <code>in/out 포트</code> 를 구분하여 구현한다. 각 경계 별로 <code>테스트 코드</code> 짜는 것도 있고, 마지막에는 만든 것들을 조합해서 실행 가능한 프로그램을 완성시킨다.</li><li>이 책에서는 <code>도메인 Entity</code> 와 <code>영속성 Entity</code> 를 완벽하게 분리한 점이 인상 깊었다.</li><li>나는 책을 읽으면서 하나하나씩 직접 타이핑을 했는데, 이 편이 훨씬 좋은 것 같다. (당연한소리?) 직접 타이핑을 하면서 책을 보다보니 <code>책이 나에게 조언을 해주는 것으로 들렸다</code>. 이 경험은 그냥 책을 읽었을 때보다는 훨씬 얻는 것이 많지 않을까 싶다.</li><li>한가지 아쉬운 점이 있다면, 여러 도메인 사이에서는 어떤식으로 교류를 하는지에 대해서는 나와있지 않았다. 이 부분은 책을 읽은 이후에 오히려 갈증으로 남게되었다. 그래도 너무 좋은 책이라고 생각한다. 어쩌면 지금 클린아키텍처를 다시 읽어야 하는 타이밍이 아닐까 싶다.</li></ul></li><li>추천하는지?<ul><li>100% 추천하고 싶다. 헥사고날 아키텍처를 도입할 예정이 없더라도, <code>유지보수를 해야하는 서비스를 개발하는 개발자</code> 라면 읽어서 나쁠 건 없다고 생각한다. 아래는 조영호 님의 추천사이다.</li><li><img width="528" alt="CleanShot 2022-02-04 at 14 24 11@2x" data-src="https://user-images.githubusercontent.com/25674959/152476775-36b62b26-b8a3-4fe4-9329-9c3916012328.png" data-proofer-ignore="" src="https://user-images.githubusercontent.com/25674959/152476775-36b62b26-b8a3-4fe4-9329-9c3916012328.png"></li></ul></li></ul><h3 id="2-이펙티브-코틀린">2. 이펙티브 코틀린<a href="#2-이펙티브-코틀린"><i></i></a></h3><ul><li>계기<ul><li>나는 코틀린을 이용하여 개발은 하고 있지만, 잘 사용하고 있는건지 확인이 필요했다. <code>코틀린 인액션</code> 을 완독하지 않은 입장에서 <code>이펙티브 코틀린</code> 을 보는 것이 순서가 맞을까 싶기도 했지만, <code>자바의 정석</code> 을 완독하지 않은 내가 <code>이펙티브 자바</code> 에서 많은 깨달음을 얻은 경험이 있으니 이번에도 괜찮지 않을까 싶었다.</li><li>이펙티브 코틀린 번역본이 출간되었다는 소식을 듣고 바로 구매했다. 책을 읽고 나면 코틀린을 좀 더 코틀린답게 사용하기를 바라며 책을 읽었다.</li></ul></li><li>내용<ul><li>책 구성은 <code>이펙티브 자바</code>와 비슷하다. 여러 Item 으로 구성되어 있다. 이 책은 코틀린 이외에도 <code>클래스 설계</code> / <code>추상화</code> 에 대해서도 다루고 있다. 해당 내용은 다른 책에서도 많이 다루고 있기에 불필요하다고 생각했으나, 결코 그렇지 않았다. 개념을 다시 익힐 수 있어 좋았고, 그 안에서도 코틀린스러운 코드들을 볼 수가 있었다.</li><li>내가 평소에 <code>sealed class</code>, <code>sequence</code> <code>공변성</code> 에 대한 고민이 부족했음을 느꼈다.</li><li>이 책을 한번 읽는 것 만으로 안에 내용을 다 익혔다고 생각하지 않아서 2월 중에 한번 더 읽을 예정이다.</li></ul></li><li>추천하는가?<ul><li>코틀린을 조금이라도 써보았고, 조금 더 잘 쓰고싶다면 무조건 추천하고 싶다. 코틀린을 써보지 않았다면 이 책보다는 <code>코틀린 인액션</code> 이 맞지 않을까 싶다.</li></ul></li></ul><h2 id="2월에는">2월에는…<a href="#2월에는"><i></i></a></h2><ul><li>일 빨리빨리 잘하자</li><li>조직 내 DDD Study<ul><li>조직 내에서 2월에는 DDD 스터디를 참가했다. 조직에 DDD 를 정착시키기 위함은 아니지만, 함께 도메인 레이어에 대한 필요성을 느끼며 조금씩 개선해 나갈 수 있지 않을까 싶다.</li><li>DDD 스터디를 통해서 우리 현 아키텍처에서 문제가 무엇인지. 그것은 정말 문제인지. 문제라면 어디부터 손대는게 좋을지. 에 대한 이야기를 나누는 계기가 되었으면 한다.</li></ul></li><li>조직 내 JPA Study<ul><li>DDD 뿐만 아니라 김영한님 인프런 강의를 이용해서 스터디도 참가했다. 인턴 때 JPA 1차/2차 캐시 에 대해 발표를 하면서 JPA에 대해 친숙해졌었는데, 조직에 합류하고서는 JPA를 사용하지 않아 거의 까먹었다.</li><li>다시 학습하고자 강의를 구매하여 스터디를 참가했다. 회사에서 비싼 강의료를 지원해 준 만큼, 조직에서도 잘 정착하는 기술이 될 수 있으면 좋겠다.</li></ul></li><li>조직 내 이펙티브 코틀린 약팔기</li><li>이펙티브 코틀린 2회독</li></ul></div></div>

2022년 1월 회고

댓글