문홍의 공부장

## 1. 진행하던 단기 TF 종료 3월 말에 드디어 릴리즈를 했다 ! 릴리즈 전후 2주는 정말 정신없이 보냈는데, 릴리즈 하자마자 빵빵 터지는 이슈에 꽤나 고된 하루하루였다. 뭔놈의 핫픽스를 하루걸러 하루로 내보내는지,, 운영 안해본 티가 팍팍 나죠 이런저런 시행착오를 겪으면서 나아가는 거겠지. 괜찮아 괜찮아! (+) 수치화된 테스트 시나리오 작성과, 테스트 코드의 중요성을 다시 한 번 깨닫는 계기가 되었다. 테스트코드... 진짜찐쨔 짜야찌. ## 2. 구글 엔지니어는 이렇게 일한다 완독 드디어 다 읽었다! 중간중간 내 상황과 안맞는 부분이나 내가 실질적으로 다루지 않는 부분들이 있어서 약간 집중도가 흐려질 때도 있었지만, 그래도 열심히 읽어서 드디어 1회독 완료! 전자책에 북마크 해두고 하이라이트 쳐..

웹 애플리케이션을 개발하다 보면 하나의 클라이언트 요청에 대해 애플리케이션 전반에 걸친 특정 Context를 유지해야 할 필요성이 생긴다. 대표적으로 로깅 정보나 사용자 정보가 있다. 이 때 흔히 사용하는 방안은 ThreadLocal을 활용하는 것이다. 스프링에서 Web Request 가 오게 되면 하나의 쓰레드를 할당해서 해당 작업을 처리하게 된다. 이때 Thread 에 대한 정보를 ThreadLocal 에 저장하게 되면 해당 작업이 끝날 때 까지 모든 상황에서 context 를 유지하고 저장하고 찾아볼 수 있다. ThreadLocal은 쓰레드의 로컬 컨텍스트 변수로 Thread 가 존재하는 한 계속해서 남아 있는 변수이다. 작업 요청이 들어왔을때 하나의 쓰레드가 생성이 되고 작업이 끝나면 쓰레드가 없..

서비스 로직 간의 강결합이 주는 문제점 애플리케이션을 개발하면서, 한 번의 요청에 의해 2가지 이상의 기능을 수행하는 경우가 빈번하게 발생한다. 혹은, 간단하게 시작된 도메인 로직이 서비스가 확장됨에 따라 여러가지 추가 로직이 늘어나는 경우 역시 발생한다. 이러한 상황에서, 다수의 기능을 하나의 메서드에서 코드로 구현하면 기능 간 강결합이 생기게 된다. 강한 결합이 생기면 생길수록 로직을 분리해서 관리하기 어렵고, 특정 기능에 문제가 발생하였을 때 이를 처리하는 로직 역시 섞이게 된다. 클라이언트에서 회원 가입 요청이 발생하였을 때, 아래와 같이 프로세스가 진행된다고 가정해보자. (로직에서 사용한 메서드는 별도 구현이 되어있음을 전제한다.) 회원 등록 가입 축하 메일 발송 @Service @Require..

CompletableFuture 는 기존의 Future 인터페이스의 한계를 보완하기 위해 등장한 클래스이다. Future 인터페이스는 비동기 작업에 대한 결과값을 리턴받기 위해 사용되었으나, 아래와 같은 한계점이 존재한다. 외부에서 완료시킬 수 없고, get(long timeout, TimeUnit unit) 의 timeout 설정으로만 완료 가능 블로킹 코드(get()) 을 통해서만 이후 결과를 처리할 수 있음 여러 Future 를 조합하거나, 예외 처리 할 수 없음 CompletableFuture 는 이름 그대로 외부에서 '완료 가능한' Future 이다. 또한, CompletionStage 인터페이스를 구현하여 작업의 중첩, 완료 후 콜백(Future 간 조합)을 가능하게 하였다. public cl..

### 1. 새 회사 적응기 이직하고 적응하기 어려운 것이 여러가지가 있지만, 가장 큰 건 회사 규모가 커지면서 나의 역할은 작아졌다는 점이다. 아무래도 스타트업은 한 사람이 여러 업무를 하기 마련인지라, 개발자가 기획자이기도 개발자이기도 데브옵스 엔지니어이기도 QA 이기도 DBA 이기도 했는데, 지금은 모든 역할이 쪼개져 있다. 물론 이건 장점이자 단점이다. 전 직장에서 많이 했던 말 (댁아리를 쥐어싸매며) 제발 기획자 좀 뽑아줘,,,, (셀프 머지와 동시에) 배포하겠습니다 (대충 TF 팀방에) 잠깐 DB 작업 좀 하겠습니다 (6시 이후) 김개발자 퇴근합니다 김QA 출근했습니다 이런식이었고 역할이 나눠지지 않고 한 사람이 알아서 다 해야 한다는게 스트레스 였는데, 지금은 다 분업되어 있으니 모든 게 협..

1. 근황 이직을 하고 한 달이 지났다. 배울 것이 정말 많구나 느낀 한 달이었다. JPA가 가장 큰 산이 될 거라고 생각했던 내 예상과 달리, JPA 와 Querydsl 은 모르는 개념만 잡고 가면 생각보다 어렵지 않을 것이라는 생각이 든다. 그거보다 더 큰 산은 Back to the Basic. 내가 안다고 생각했던 것이, 그 깊이가 고작 요정도 였구나를 깨닫게 되었다. 스프링 기능을 사용하다보면 '스프링이 알아서 해주는' 부분에 대해 알고 넘어가야 한다고 생각해서 코어를 파보긴 했었는데, 스프링은 넓고 내 지식은 좁았다. 아예 몰랐던 기능도 튀어나왔고, 비동기 처리는 전 직장에서는 쓸 일이 거의 없었어서 개념만 알고 있는 수준이었다. 기초부터 탄탄히의 중요성을 또 한 번 깨닫는 계기가 되어 공부해야..

애플리케이션을 개발하다 보면, 하나의 테이블에서 조회하는 단순 조회 쿼리 뿐 아니라, 다수의 테이블을 조인하여 값을 조회하는 경우가 매우 빈번하게 발생한다. Querydsl은 결과를 사용자 정의하는 두 가지 방법, 즉 행 기반 변환을 위한 FactoryExpressions와 집계를 위한 ResultTransformer를 제공합니다. Querydsl의 FactoryExpression 구현 기능은 com.mysema.query.types.Projections클래스를 통해 , ResultTransformer 는 com.mysema.query.group.GroupBy를 통해 구현되어 있다. 1. Projection Projection 이란, Querydsl을 이용해 entity전체를 가져오는 것이 아니라 조회 ..

JPA를 사용하다보면 여러가지 상황을 캐치하여 작업을 해야할 경우가 생기곤 한다. 예를 들어, 데이터의 수정/삭제가 발생하였을 시 그 요청 이력을 관리하여야 한다고 가정하자. 이 때 모든 수정/삭제 로직이 끝날 때 이력 관리 테이블에 데이터를 저장하는 로직을 추가하는 것은 매우 비효율적인 일이다. 하이버네이트에서 제공하는 JPA EntityListeners 를 활용하여 엔티티의 생명 주기에 따른 이벤트를 처리할 수 있다. Callback Events PrePersist: persist() 를 호출하기 전, 새로운 엔티티가 영속성 컨텍스트에 관리되기 직전에 호출된다. 식별자 생성 전략을 사용한 경우, 엔티티의 식별자는 아직 존재하지 않는 상태이다. PostPersist: persist()를 호출한 후, f..