1일1커밋 회고나 다른 회고는 작성했으면서 정작 연말에 한번씩 작성하는 회고는 이번이 처음인 것 같다.

어제는 회사에서 백엔드 팀끼리 회고를 진행했다!!!

KPT 방식으로 진행을 했었는데, 바빠서 못했던 것들 그리고 문제적으로 좀 느끼고 있던 것들 위주로 Try 에서 3가지가 꼽혔다.

1. 테스트코드 2. 레플리카 DB 활용 3. 컨벤션 확립

테스트코드는 나는 단위테스트를 짜면서 개발을 진행했었는데, 다른 분들도 이제 유지보수가 점점 어려워지면서 테스트코드를 지금이라도 늦지 않았으니 꼭 짜자 라는 방식으로 안건이 나와 채택되었다.

레플리카 DB는 구성은 되어있으나 제대로 활용하지 않고 있었는데, 이번 기회에 내가 건의하여 이슈를 수면위로 드러냈다.

다들 의견이 동일하셔서 안건이 채택됐다.

3은 협업한다면 당연히 확립되어야 하는게 맞지 않나 해서 채택되었다. (얘기는 많이 나왔지만 실패했었다고 한다)

자, 이제 내 회고로 좀 돌아와보자!

올 초반에는 내가 다른회사에서 일을 진행했다.

일단 내가 블로그를 올해 많이 옮겼다.

초반에는 깃허브 블로그, 중간에 벨로그로 옮겼으며, 마지막인 지금은 티스토리에 정착한 상태다.

그래서 깃 커밋 로그를 좀 뒤져봤다 ㅋㅋㅋㅋㅋㅋ

1월

https://lsj8367.tistory.com/entry/Mock-%EC%82%AC%EC%9A%A9%EA%B8%B0 이 글이 1월에 작성했던 글이다.

이 때 당시에 테스트 코드에 대한 관심을 지속적으로 가졌고,

계속 진행했던 사이드 프로젝트 팀에서 HTTP 완벽 가이드 스터디를 진행했다.

2월

2월에는 자료구조, 알고리즘 그리고 디자인패턴에 관심을 많이 가졌던 한 때이다.

회사에서 테스트코드를 먼저 작성한 기반들을 토대로 리팩토링을 진행하면서,

디자인패턴을 적용시키거나, 아키텍처 관점에서 분리할 수 있는 방법들을 계속해서 생각해냈던것 같다.

그때 만들었던게 벨로그로 옮기면서 퍼사드 패턴 적용기

이걸 작성했는데, 이 때 당시에 나보다 늦게 들어오셨던 신입분께서 아는 지인이 이 글을 봤다고 했었다...!!! 😱

그래서 되게 신났던게 아직 내 기억에 남아있다 ㅋㅋㅋㅋ 더 열심히 글을 작성해야겠다고 생각했던 날이었다.

3월 ~ 4월

사실 이부분엔 되게 뭘 한게 없는것같다 라고 생각했는데,

이 때 친구의 권유로 스프링 스터디 모임에 나가게됐다.

김영한님의 스프링 고급편 + 토비의 스프링 1권을 읽는 스터디를 나가면서 많은 대화들을 나눴다.

다양한 회사에 근무하는 분들과 대화해서 좋았던 자리다.

이때 스프링이 끝난 후에도 Real Mysql 8.0 서적을 읽는 스터디도 진행했었다.

이 때 DB에 대해 좀 더 깊게 공부했던 때가 아닐까 한다.

책정리 는 노션에서 주로 했다.

계속해서 책을 읽었던것 같다. DDD... ㅋㅋㅋ

5월

5월은 이제 삽질을 많이했던 시기였다.

사내에서 배치 세미나를 열었었다. 이때 부터였다 세미나를 내가 해보고 싶다고 관심 가진것이. ㅋㅋㅋ

세미나 자료는 이때 DDD, 스프링 배치, 단위테스트 였다.

그리고 배치에서 나는 에러를 개선했다!!!

그리고 쿼리 속도 개선했던 작업도 있었고, 이게 바로 Real Mysql 서적을 같이 공부하면서 인덱스를 내가 적용했던 시점이다.

6월엔 운영체제 강의를 들었다!

더불어서 블로그를 이제 티스토리로 옮기게 된다.

하나씩 옮겼던 이유는 벨로그에선 전체 통계를 볼 수 없었던게 너무 아쉬웠다.

그래서 티스토리로 옮겨왔는데, 벨로그에 있는 글이 훨씬 사람들 방문이 많은 것 같다.

다시 옮겨가고 싶은 느낌도 들기는 한다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

그리고 7월에 공백기간을 좀 거친다.

이 때 했던것은 넥스트 스텝의 ATDD과정이다.

전에 TDD, Clean Code With Java 과정을 할 때에는 바빠서 마지막 볼링구간을 이수하지 못했다!

그래도 얻어가는 것은 많았는데 ATDD는 전부 완주를 했다.

ATDD회고

이 때의 나는 퇴사를 결심한다.

그러면서 핀테크로 도메인을 옮기게된다.

8월

8월에 드디어 모든 글을 티스토리로 옮기고, 

근황을 쓴다.

여기에 그동안의 근황이 다들어있어서 이걸 열어보신다면 좋을것 같다 👍

8월에 인프콘을 다녀왔었는데, 응모한 것에선 당첨이 되지 않았고,

지금 다니는 회사에서 발행하는 카드를 인프런이 사용하고 있어서 그걸 통해 내가 표를 받았었다!

본의 아니게 내가 친구한테 받은 라즈베리파이로 서버를 구축하면서 짧게 인프콘을 올렸었다.

컨퍼런스를 오프라인으로 접하게 되면서 다른 개발자분들은 어떤것에 관심을 가지고 있는지를 알아볼 수 있었던 시간이 좋았다.

9, 10, 11월

9월에 기억나는건 이펙티브 자바 스터디를 참여하게 된다.

회고를 쓰는 지금 이제 2주차 정도만 더 스터디를 하면 이펙티브 자바는 끝나는 상태가 된다.

2회독을 스터디로 하게 되면서 공유한게 많은 것 같다.

이 부분은 책정리에도 있다.

이 때는 내가 처음으로 Kafka 를 사용하게 되는 날이 온다!

막상 얘기만 들었지 사용해본 경험은 없었기에 새로운 시도라서 굉장히 좋았던 달이다.

그리고 입사를 하면서 적응하는 시기였고, 해당 금융 도메인 지식이 없던 상태에서 시니어 개발자분이 메시지 플랫폼을 구축해보는게 좋을 것 같다 하시면서 이 부분을 개발하게 되었다.

면접을 봤던 것보다 빡세게 설계 질문, 코드 질문, 기술에 대한 허점 같은 것들을 많이 질문해주셨다.

등에서 식은땀이 났던게 아직도 기억이 난다 ㅋㅋㅋㅋㅋㅋ

지금 회사에선 백엔드 개발자 분들이 나를 포함해 8명이 있다.

한분은 프로그래밍 동아리를 통해 마켓컬리로 이직하셨다. 👏👏👏

그러면서 회고를 쓰는 지금 신입 백엔드 개발자분이 한분 입사하여 8명이 변함없는 상태가 되었다 ㅋㅋㅋ

월별로 무언가를 정리해보니 꽤 많은 일들이 있었다.

11월엔 NHN Forward 컨퍼런스도 다녀왔고, 여기서 인상깊었던건 아무래도 DDD + Clean Architecture

이 세션을 너무 재미있게 들었었다. 아는 내용이기도 하고 지금 관심갖고 있던 터였기 때문이다.

MSA 구조로 회사가 전환을 하면서 기존의 계층형 아키텍처를 탈피하며 도메인 단위로 뭔가 구성을 해보고 싶어서 많이 들여다 본게 컸다.

12월

이펙티브 자바 스터디는 계속 유지하면서 알고리즘을 지속적으로 월, 목 마다 2문제씩 풀이하는 스터디를 한분과 진행중이다.

덕분에 설계하는데에 조금 더 생각하는게 깊어진 효과를 보는중이다.

아 참, 이때부터 까치산의 모각코를 나갔다 ㅋㅋㅋㅋㅋ 잘하시는 고수분들 많이 만났다.

업무에 많이 힘을 쏟았던 월이고, 오늘은 마지막날이라 휴가를 쓰고 쉬고있다 !!

이 12월에 좀 내가 회사에 정말 적응을 했다고 느끼는건 이제 사람들과 많이 대화하고 있다는것. 장난도 치며 웃기도 하고 소통도 활발해진것.

공유하고 소통하는 문화를 지향했던 나지만, 낯가림이 심해 적응이 힘들어서 본격적으로 공유를 활발하게 했던 월이라 가장 좋은 월인것 같다.

끝으로

한 해를 다 정리해버렸다. 이번 년도에는 6개월마다 이력서를 써보는 것을 많이 못해봤다.

시간을 내서 따로 지원해보고 했어야되는데, 업무가 많이 바빠 그럴 여력이 못됐던것 같다.

내년 상반기부터 다시 해서 실력 체크를 주기적으로 해봐야겠다 라고 느낀다!

요즘은 일일 회고를 작성한다. 업무가 됐든, 주말이 됐든 하루에 뭘 했는지 간략하게 쓰는 작업을 하고 있는데,

이것도 나중에 1년치를 작성하면 회고를 해보는것도 좋은것같다.

일단 지금은 링크로써만 공유를 해본다.

올 한해는 한 단어로 보면 과도기 인것 같다.

뭔가 하나에 잘 정착하지 못했다. 블로그든, 회사든

이제 좋은 개발자분들에게 많이 배우고 공부해야될 것도 늘어난 지금 많이 노력해서 내년엔 좀 더 많이 성장을 했으면 좋겠다!!

개발자 삶의 두번째 컨퍼런스인 NHN Forward에 다녀왔다.

인프콘 때와는 다르게 한 공간에서 쭉 들었다.

백엔드 세션만 들어야겠다 라고 생각했는데 그 세션들이 전부 한곳에 모여있었다 ㅋㅋㅋㅋ

들어가자마자 체크인을 QR로 진행하고 키노트를 진행하는데 계속 서서 컨퍼런스 장소까지 가니 다리가 아팠는데 또 내내 서있었다.

점심먹고 들었던 세션인 분산 시스템에서 데이터를 전달하는 효율적인 방법 세션에서

RDB, RabbitMQ, Kafka를 통한 서로 다른 마이크로 서비스들의 트랜잭션을 어떻게 관리할 것인가에 대해 되게 재밌게 봤다.

RDB로 사용하는 방법을 이번에 처음 보게되어 예전에 면접에서 받았던 질문이 이런걸 물어본 거였구나 하면서 아~ 하고 깨닫는 순간이었다.

메시지 큐를 사용하는 방법은 현재 내가 담당하고 있는 메시지 플랫폼에서의 데드레터 처리와 같았다.

자세하게 정리하는건 내 노션에서 해야겠다.

사람들이 엄청많았고, 아침에 점심 조금 늦게먹고 자리를 안잡았으면 밖에서 그냥 발만 동동 굴렀을 것 같다.

앉지 못하면 자리가 없어서 못들어간다고 밖에서 얘기하시는 스탭분을 봤다. 그래서 다른분들이 참여 못하시는걸 봤었다...

혼자만 뽑히게되어 아는사람 없이 혼자가서 얌전하게 세션들 다 듣고 바로 와버렸다.

중간에 다른 부스인 커리어리에서 앱 다운하면 뭔가 물품을 준다해서 이미 나는 앱이 있어서 저는 이미 앱이 있어요!

하니까 귀하신 회원님이라면서... ㅋㅋㅋ 바로 챙겨주셨다.

아무튼 너무 좋은 시간이었고, 지속적으로 이런 컨퍼런스도 참여하면서 많이 교류하고 정보도 얻어야겠다.

그리고 컨퍼런스를 다녀옴으로써 한번 더 자극을 받았고 다시 한번 열심히 달려봐야겠다!

시작하기

내가 클라우드 요금은 견딜 수 없어서 상당히 겁이 난 상태였다.

하지만 뭔가 내가 만들어서 써보고 싶은게 최근에 생기게 됐다.

그게 바로 북마크인데, 크롬에 의존해서 북마크를 하는게 아니라, 내가 직접 만들어서 거기에 글 포스팅을 스크랩하거나,

모르는 영단어나 줄여쓰는 영어등등.. 개발 관련 단어들도 뭔가 한 곳에 두고 싶었다.

그런데 웬걸, 친구가 라즈베리파이가 한 개 남는다고 이거 써보겠냐고 물어왔다. ㅋㅋㅋㅋㅋ 나는 좋지~

아두이노는 한번 써봤는데 이건 처음이라 그래도 OS설치는 이미 되어있다고 해서 받아서 써보는데 되게 귀엽고 성능은 좋은것 같다? (아직 첫날이라 그런걸까.... 🤔)

아무튼 각설하고 이 서버를 통해서 ssl 적용도 해서 도메인 주소 붙이고 나만의 북마크를 만들어보고 싶어졌다!

이 라즈베리를 사용하는 덕에 뭔가 운영체제나 메모리, 네트워크 등등의 지식들을 같이 얻어갈 수 있는 기회라 좋을 것 같다!

이제 막 여러 것들을 설치하면서 하나씩 보는데 상당히 재밌다.

ㅋㅋㅋㅋ 월급받으면 이 라즈베리파이에 쿨러도 달아줄까 생각중이다. (종일 써야되니 무조건 달아줘야 하는게 아닐까 싶긴 하다)

이게 진짜 웃긴게 sd카드는 용량을 다시 한번 확인해봐도 16기가였다.

근데 전체 디스크 용량을 보면 5.6기가 남짓이다.

좀 구글링을 해봤는데, 라즈베리파이에서 제공되는 OS 사용시 메모리가 4기가 남짓만 사용가능하게 설정된다고 한다.

그래서 용량을 재설정하는 것을 검색해보고 적용하니까 아래같이 바뀌게 됐다!

크... 87%에서 33%로 감소하는 수준의 용량차이다. ㅋㅋㅋㅋㅋ

뭔가 지금 해결되지 않은건 와이파이 설정인데..

일단 기존에 친동생 방에 이더넷 케이블이 남는 여분이 하나 있어서 당장 쓰지 않는 케이블이라 이더넷으로 연결해서 사용중이다.

공유기로 포트 물린게 아니라 따로 회선이 등록되어 있는경우라서 공인 ip로 바로 접속해버렸다.

이거 철저하게 관리하고 공유기로 돌릴 수 있는 방법 찾으면 그렇게 바꿔야겠다.

뭐 일단 ssh접속 포트도 바꿨고, public key접속으로만 접속하게끔 허용해놓은 상태라서 일단 당분간은 안심하고 쓸수도 있겠다.

뭐 mysql은 일단 설치 잘했고...

가장 최신 LTS인 Java17을 나중에 받아야겠다. 뭔가 homebrew에서 하는 설치랑 조금 다르게 wget으로 수행해주는 것 같다.

아니면 지금 공부중인 코틀린을 써볼까?! 하는 재밌는 생각이 계속 들면서 기분이 좋아진다.

소프트웨어 장인이라는 책을 출퇴근 시간에 읽으면서 마음가짐도 되게 많이 바뀌게 되는것 같다.

인프콘도 다녀오면서 오프라인 컨퍼런스를 체험하고 다른 개발자분들의 의지에 덩달아 자극을 받아 열심히 또 달려보려고 한다!

스터디도 JVM 관련 스터디와 이펙티브 자바 회독을 하려고 이 스터디도 들어가게 되서 총 2개 스터디를 들어가게 됐다.

이것도 같이 병행하면서 열심히 해야겠다. (북마크 만드려면 JavaScript도 공부해야되는데...?)ㅋㅋㅋㅋ

아무튼 요근래 못했던 삽질 ATDD과정 끝나면서 이런 값진 행동들을 하면서 많이 에러 맞아볼 수 있는 또 하나의 기회가 오지 않았나 싶다.

마무리

공부할게 정말 많고 시간이 없어서 내 자신을 하나의 프로세스로 두고 여러 스레드를 할당해서 병렬로 지식습득을 하고 싶다 😇

요즘에 계속 TDD를 하려는 습관을 가지다 보니까 전에 단위 테스트를 작성했던 나보다 훨씬 예외 케이스나 엣지 케이스들을 더 잘 찾아내는것 같다.

확실히 반복적으로 짧게 테스트를 가져가면서 피드백 받으니 이렇게 되는건가 싶다.

이전에 TDD, Clean Code with Java 12기를 이수하면서,

테스트 코드에대한 중요성 그리고 단위 테스트는 어떻게 해야겠다! 라고 깨달음을 얻었었다.

그렇게 하면서 업무에도 테스트코드를 적용하려고 하는데

흔히 Spring framework에서 사용하는 Controller, Service Layer 들의 테스트들을 내가 작성할 때에는 전부 Mock을 이용해서

테스트를 진행을 해주었다.

이렇게 해주는게 맞을까? 🤔 라는 의문을 계속 가지면서 그리고 최근에 뭔가 조금 해이해진 경향을 바로 잡고자

이 강의를 신청하게 되었다.

각 주차마다의 미션들을 좀 가져와봤다. 궁금하면 한번 놀러와주세요!

1주차 - 인수 테스트

https://github.com/lsj8367/atdd-subway-map

2주차 - 인수 테스트와 TDD

https://github.com/lsj8367/atdd-subway-path

3주차 - 인수 테스트와 인증

https://github.com/lsj8367/atdd-subway-favorite

4주차 - 인수 테스트와 리팩토링

https://github.com/lsj8367/atdd-subway-fare

이렇게 4주까지 피드백 받으면서 인수 테스트를 작성했더니 시나리오 흐름대로 뭔가 이해할 수 있게 테스트를 구성하는게 가능해진것 같다.

또 한번 사석에서 리뷰를 받아보니까 어떤 부분을 내가 놓치고 있었고, 어떤 부분에서 조금 더 나은 선택을 할 수 있는지 많은 고민을

할 수 있어서 굉장히 좋았다.

RestAssured를 사용해서 인수테스트를 진행했는데, MockMvc와의 다른점과 좋았던 점 등등을 다른 포스팅에서 다시 쓰도록 하겠다.

(여기는 회고글이기 때문)

한 프로젝트를 돌아가게 작성만 해놓고 다른 프로젝트를 또 시작하는 SI 형식의 개발이 아니기 때문에,

내가 짠 코드에 대해서 유지보수를 잘하게끔 도와주고, 더 나아가서는 코드를 다른사람이 볼 때에도 이해하기 쉽게끔 테스트를 구성하는게 습관이 되어가고있다.

이와 동시에 비즈니스 코드를 작성하는것보다 무조건 테스트 클래스부터 만드는 내 자신을 볼 때 좀 뿌듯한 감정도 있다. ㅋㅋㅋㅋ

다만 이 과정중에 아쉬웠던 것은, 조금 더 여유있을 때 해볼걸 하는 생각도 있지만 끝나고 보니 열심히 하는 다른 분들이 있어서

같이 자극받고 하지 않았나 싶다!!

이제는 다시 업무를 위한 공부를 하면서, 틈틈이 하려고했던 운영체제, 네트워크, 알고리즘을 쭉 해야겠다.

아무튼 좋았고 되게 값진 경험이었다!

블로그를 기존 벨로그에서 티스토리로 옮기게 되었다.

그래서 거기서 포스팅 했던 글들을 전부 지금 이 티스토리로 옮기고

드디어!! 진짜 날짜에 맞는 첫글을 써본다.

이직

우선, 전 직장에서 6개월을 하고 그만 둬버렸다. 뭔가 시도해보고 도입해보려고 했던건 많이 도입을 해보았던 것 같다.

내 입장에서는 그래도 같은 업무를 보는 개발자분들이 좀 더 많았으면 좋겠다고 생각했고,

여러 의견을 들어보고 싶었던게 가장 컸던 것 같다. 그래서 이직을 하게 됐다!!

물론 근속기간이 짧고 그렇게 이르게 이직을 했다는 것 자체가 문제라고 본다면 문제일 수 있다고 생각하지만,

뚜렷한 기준을 가지고 충분히 설명할 수 있을거라고 생각했었다.

B2C 서비스를 하던 기존 회사였지만, 그래도 아직 시장이 되게 작았었고,

그것으로 인해 여러 트래픽 경험을 못해봤던게 조금 아쉬움이 많이 남았는데..

B2B 핀테크 서비스로 옮기면서 전 회사가 작았던 탓인지 지금 이곳이 트래픽이 훨씬 많다!!!

무엇보다 이직한지 1달이 조금 넘은 지금은 CTO님이 계셔서 탄탄하게 흘러가고 있다는 것이 좋게 느껴진다.

다들 고민을 위해서 뭐든지 뛰어들고 공유해보고 얘기하는 것을 좋아하시는 것 같다고 내 주관적으로 생각한다.

아키텍처 리뷰

지금 당장 내가 담당하고 있는 일은 공통 메세지 서버를 개발을 진행중이다.

서비스가 점점 커지며 MSA 아키텍처로 전환하면서 지금의 회사는 Kafka를 도입했다. (이 포스팅에 대해선 추후에 다시 다루도록 하겠다. 😁)

이렇게 분리하면서 나온게 지금 내가 개발하고 있는 공통 메세지 서버이다.

간단하게 설명하자면 여러 메세지들을 푸시, 메일, 슬랙 등등으로 공지나 알람들을 보내주게 되는 서버이다.

처음 써보는 Kafka지만 그래도 다들 많이들 도와주셔서 잘 구축한거라고 생각한다.

작성 시점 기준으로 어제 아키텍처 리뷰를 받았는데, 면접 때 질문 받은것보다 이상으로 더 많이 깊게 물어봐주시고 알려주시고 한 덕분에

얻어가는게 많은것 같다. ㅋㅋㅋㅋ (아직 한참 모자라다고 많이 느낀다)

코드리뷰도 적극적으로 한 PR에 코드 수정이 아니더라도 생각할 수 있게끔 주시는 코멘트도 많아서

답변까지 포함해서 첫 PR기준으로 4~50개가 달렸었다. 각기 다른 시각으로 봐주는게 내 입장에서는 정말 좋다고 느꼈다.

개인적으로는 이직 후에 1달이 지난 지금이지만, 각 서비스에 대한 도메인 지식은 지금이 훨씬 습득이 빠른것 같다.

VOC도 처리하면서 온보딩 받아가며 하다보니 잘 잡혀가는 것 같다.

그래도 계속 내가 성장하는데 발목을 잡는건 CS였다. 뭔가 잘 개발하는것 같다가도 궁금증이 생기는 건 무조건 CS였다.

그래서 내가 생각했던 방법은...

모각코를 해서 다양한 사람들의 의견도 들어보고 내 공부도 틀어지는 것 같을때 질문해서 방향성 잡아 좀 깊게 하고 싶었다.

그래서 최근에 내가 거주하는 지역에서 오프라인 모각코를 모집했다.

내가 뭔가 주도해서 소통하고 싶고 다른 분들의 생각도 들으면서 공유하고 싶었던게 크다.

스터디 구인 글

이렇게 모집하면서 나를 포함한 8명이 내일이면 처음 모각코를 시작한다.

지속적으로 잘 운영이 된다면 인원도 늘려서 소규모로 자기가 배웠던것이나 최근 이슈를 해결했던 것을 발표하는 시간도 가져보고 싶은

생각이 있다. (커지면 해당 노션도 이렇게 운영되고 있다 라고 보여주려고 공유할 생각이다!)

계속 생각하는 것이지만 커머스, 금융 도메인에서 뭔가 돈이 관련된 서비스들을 주로 다루어보고 싶었다.

누군가가 보면 피곤하다고 생각이 들 수 있는데, 예민한 정보이고 깐깐하게 검증을 수행해주어야 하기 때문에

더 탄탄하게 많은 경우의 수를 가지면서 다룰 수 있을거라고 생각해서 이쪽으로 관심을 가지게 되었던 것 같다.

이제는 지금 회사에서 꾸준히 잘 성장하다보면 언젠가는 내가 원하는 회사에 갈 수 있지 않을까 생각한다.

다음 회고에서는 지금보다 더 성장하는 내가 되었으면 하고 계속 반복적인 연습이 답인것 같다. 🔥🔥🔥🔥

회고록

블로그를 옮기게 되어 날짜가 맞지 않는다.

작성일 : 2022년 2월 21일

서비스 회사로 와서 벌써 1달 반정도가 지났다.
스타트업인지라, 먼저 있었던 사람들을 욕할건 아니다.
그렇지만 지금 그렇게 쳐나가면서 생겼던 기술부채로 인해서 신규 개발건이 들어왔을 때
유지보수가 힘든 점들이 많다.

무책임했던 누군가

기존에 있던 백엔드 개발자가 나가고 없었기에 모르겠지만 그사람은

자바에 엄청난 자부심이 있다고 했다.

<<-- 이렇게 하면 안되지만 정말 못짰다..🤬

협업이라는 것을 싫어했고, 자기의 의견이 맞았으며, 코딩 컨벤션 또한 지켜진게 없었다.
그리고 외주로 뭔가 개발이 왔던건줄 알았던 코드가 그 사람의 코드였다...

악취나는 코드의 예시들

클래스가 MAIN_CLASS, main_class, MainClass, mainClass 등등... 네이밍이 상당했다.

이걸 나의 사수분께서는 JDBC -> JPA로 리팩토링을 하고 계셨던 찰나에 내가 입사를 했던 것이다.
많이 봐서 익숙했던 HTTP 상태 코드도 쓰지 않고 커스텀으로 200을 정의했는데 이게 에러였나? 그랬다.

switch(STATUS_CODE) {
    case 200: 
    case 201: 
    case 202: 
    case 203: 
    case 204: 
    // 이렇게 엄청 많이 있었다
}

이렇게 아마 300번까지 있나 그런다.. 너무 보기싫다.. 😇

아니 ResponseBody를 전역에서 설정해준것이 바로 @RestController가 아닌가?

난 내 지식이 의심스러울 정도였다.
간략하게나마 써보자면...
예를들어 유저를 조회하려는 API가 있다고 하면..

 

나름의 컨벤션이 있던건 같다. 클래스 뒤에 1은 create, 2는 read, 3은 delete, 4는 update였다 ㅋㅋㅋㅋ

 

아직도 웃기다.. 🤣🤣🤣🤣
아 아래 예시는 조회인데 조회 API 클래스만 따로있다.
그러니까 위에서 했던 1, 2, 3, 4 일련의 동작들이 하나로 엮인게 아니라
1기능 당 1개의 컨트롤러다.

@RestController
public class h_user_info_2 {

    @ResponseBody
    @RequestMapping(value = "/pood/user/view/2", method = RequestMethod.POST)
    public String USER_INFO_LIST_VIEW(@RequestBody h_user_info_vo2 header) { // 이런식으로 받아온다.. + 조회인데 POST + api 뒤에 숫자도 붙는다..
        // 왜 실행하고 있는지 모르겠는 로직...
        // 뭐 대략 이런식으로 돌아간다
        return response;
    }
} 

아무튼 뭐 이런식으로 구성이 되어있었으니 상당히 머리아프고 파악도 못해먹겠다.
그래서 사수도 엄청 답답했을 것이다.
이걸 JPA로 바꾼 사수님은 👍👍👍
하지만 그래도 이거로는 부족했다.

객체지향적으로 코드를 구성해보자

일단 바꾼것, 가독성을 높인건 사실 맞다.

하지만, 여기서도 문제가 있었는데 흔히 보는 JPA의 Repository인 UserRepository (예시)

이 Repository를 어떤 서비스에서 필요로 할 때마다 의존 주입을 해서 쓰고있던것이다.

여기서 이제 이것도 나는 바꿔야 겠다고 마음을 먹었고, 하나의 서비스 -> 하나의 리파지토리 를 의존하는 것이 가장 좋다.

라고 생각을 했다.

그리고 여러 비즈니스 로직을 담는 클래스 -> 서비스 인것 같은 뉘앙스가 많이 풍겼다.

흔히 볼 수 있는 Layered Architecture 로 구성이 되어있다.

근데 참조가 너무 많은거다. 😭 이 상황에서 퍼사드 패턴을 떠올렸다. 🤔

구성

그래서 Controller -> Facade -> Service -> Repository 로 의존의 흐름을 넘기는 것을 생각했다.

그래서 여러 서비스 클래스를 한데모아 Facade에서 각 서비스들을 조합해서 붙여주는 식으로 정리를 했더니

의존 방향도 틀이 맞춰지고, 서비스단과 리파지토리 단위테스트를 쉽게 가져갈 수 있게 되었다.

@RestController
public class Controller {
    private final Facade facade;

    public Controller(final Service service) {
        this.service = service;
    }
}

@Facade // 어노테이션을 새로 정의해주었다
public class Facade {
    private final Service1 service1;
    private final Service2 service2;
    private final Service3 service3;

    public Facade(final Service1 service1, final Service2 service2, final Service3 service3) {
        this.service1 = service1;
        this.service2 = service2;
        this.service3 = service3;
    }
}

// 이런게 3개 있다.
public class Service1 {
    private final Repository1 repository1;

    public Service1(final Repository1 repository1) {
        this.repository1 = repository1;
    }
}

아무튼 이렇게 구성을 하게 되었다.

결과

결국 전체가 더러워질 바에는 서비스가 더러워져선 안된다고 생각을 했고,
많은 사람들에게 자문을 구한 결과도 다들 방금 한 얘기를 다들 하셨다. 감사합니다~ 🙏
무언가를 호출해서 모아주는 집약체인 퍼사드 클래스가 더러워지게 된거다.
기존 코드에 비해 엄청나게 개선 되었다고 생각한다. 중구난방인 의존을 한데 모았기 때문이다.
아무튼 한달반동안 많이 성장한것 같고 더 성장해야겠다.
갈 길이 멀고 나는 아직 배가 고프다. 더 많이 더 빨리 더 높게 성장하고싶다 👊 🔥🔥🔥🔥