공부내용공유

서론취직을 하고 온보딩 프로젝트를 하던데 엊그제 같은데 어느새 경력이 1년 6개월에 가까워지고 있다.  대략 1년 4개월 동안 여러 프로젝트를 하면서 꽤나 많은 테스트 코드를 작성하였는데 최근 술 블로그 글들을 읽다가 여러 글들에서 테스트 코드에 대해서 많이 다뤄서 나도 한번 테스트 코드에 대한 내 생각을 정리하려고 글을 썼다.  본론 이 글의 목차는테스트 코드의 장점, 한계어느정도로 짜야할까으로 구성될 예정이다.  1. 테스트 코드의 장점 테스트 코드를 왜 짜야할까? 만약 테스트 환경이 구축이 안되어 있어서 구축을 해야한다면 어플리케이션 코드를 개발할 때 보다 오히려 시간이 더 걸리기도 한다. 업무 마감 기한도 빡빡한데 야근까지하면서 짜야하는 이유가 뭐가 있을까?  내가 느꼈던 테스트 코드의 장점을 느..

서론 백엔드를 처음 공부하면서 접했던 계층 개념은 가장 흔히 쓰이는 presentation, service, repository 이 3개의 계층으로 나눈 패턴이었다, 입사를 하고나서 개발중인 프로젝트들 중 위 계층들 외에 business 계층을 추가하는 것을 보았고, 집에서 추가로 공부하면서도 business 계층을 사용하는 예시를 보게되었다. 해당 계층을 사용하면서 내가 느꼈을 때 어떤 이점이 있는지 간단하게 정리하고자 이 글을 작성하였다. (다른 장점, 틀린 내용이 있다면 댓글로 얘기해주세요!) 본론 일단 가장 핵심적인 목적은 도메인 로직만 들어있는 service 계층을 만들기 위해서이다. 도메인 로직만을 남김에 따라 인수인계를 할 때 처음 프로젝트를 보는 사람이 도메인 로직을 체력 낭비 없이 빠르게..

서론 프로젝트를 진행하다 보면 항상 검증에 대해 많이 고민을 하게된다. Request로 들어올 때 부터 철저히 검사해야할지, entity를 만들고 검증을 해야할지 등등... 이처럼 검증에 관해서는 굉장히 다양한 상황들이 있고 은총알은 없다고 생각한다. 해당 글에서는 내가 고민하면서 찾은 내용들, 받았던 조언들을 정리할 것이다. 본론 먼저 해당 글에서는 흔하게 사용되는 Presentation, Service, Repository 계층으로 나누어진다는 가정하에 글을 작성할 것이다. (entity 패키지, business 계층 같은 부가적인 부분은 생략한다.) 간단한 객체 생성에 대한 API를 예시로 어떤 계층에서 검증을 했을 때 어떤 장,단점이 있는지 알아보자. Presentation 계층 여기서 prese..

서론 REST API 서버를 만들면 controller의 request DTO를 한 개쯤은 만들게 되고 편한 사용을 위해 여러 어노테이션을 사용하게된다. 지금까지 “RequestBody가 DTO로 맵핑될 때 그냥 대충 기본 생성자랑 리플렉션 사용해서 만들어진다“ 정도로만 알고 있었다.. 코드 리뷰를 받다가 해당 부분 관련해서 질문을 받았는데 대답을 하지 못했고 굉장히 부끄러웠다.. 수치심을 지식으로 바꿔보자. 본론 리뷰를 받았던 코드를 임의의 예시로 구현하였다. @Getter @Builder public class request { private final String name; private final int age; private final List options; } 리뷰어님 : 어 @NoArgsC..

서론 FCM 기능을 완성하고 로컬에서 프론트 담담 팀원과 함께 테스트까지 완료하여 deploy 브랜치에 올렸다. 그런데 도커 컨테이너가 꺼져버렸다……. 컨테이너의 상태를 보니 exited(1) 이 떠있었고 log를 통해 확인해 보니 FCM을 사용하기 위한 key를 읽을 수 없다는 log가 찍혀있었다. 어떤 것이 문제였고 어떻게 해결했는지를 정리하고 공유하기 위해 이 글을 작성하였다. 본론 문제가 발생한 부분 FCM 기능을 사용하기 위해서 FCM Service Key가 resources 파일에 있고 @Value 를 통해 resource로 가져와 FirebaseMessaging Bean을 만드는 구조였다. @PostConstruct를 사용한 Bean 생성 코드 일부 로컬에서 돌릴 때는 아무런 문제가 없어서 ..

서론 지금 진행중인 프로젝트에서 강의가 등록되었을때, 매니저가 공지사항을 등록했을때, 강의에 선정되었을때 등등 메인 비즈니스 로직에 알람기능은 필수이다. 원래 알람 기능을 맡았던 팀원과 프론트분과 기능을 구현하면서 어려움을 겪고 조금 진행이 늦어지고 있었는데 알람을 담당하던 팀원이 개인 사정으로 인해 프로젝트에서 하차하게 되었고 나와 다른 팀원 1명이서 임시방편으로 기능이 작동하게 고치고 베타 테스팅을 진행하였다. 그 후 FCM 도메인 공부 및 레퍼런스를 찾아보고 기능 수정, 추가 및 리팩토링이 필요하다고 판단을 내렸고 해당 issue 를 내가 담당하게 되었다. 도메인 공부 및 리팩토링을 하면서 고민했던것들, 작성한 코드등을 정리하기 위해 이 글을 작성하였다. 본론 일단 기능 수정 및 리팩토링에 앞서 현..

서론 스프링 Proxy를 공부하면서 Proxy Factory 에 대해 알게되었다. Proxy Factory는 interface 를 구현하고 있는 class 의 경우에는 JDK 동적 프록시를 사용해서, interface 를 구현하고 있지 않은 경우에는 CGLIB 를 사용해서 프록시를 만들어 주는 식으로 동작한다. Proxy Factory 가 어떻게 이를 구분하고 어떤식으로 proxy 객체를 만드는지 궁금해서 코드를 직접 보면서 간단하게 정리하였다. 본론 프록시 팩토리를 생성하고 해당 팩토리에서 프록시를 가져오는 코드를 먼저 살펴보면 프록시 대상으로 삼을 클래스를 정해준다. ProxyFactory 생성자에 해당 클래스를 넣어서 proxyFactory 를 생성한다. 해당 Factory 에 사용하고 싶은 프록시..

서론 처음에 프로젝트를 시작할때는 예외처리에 대해 깊게 고민하지 않고 비즈니스상 발생하는 Custom Exception 만 만들고 던지면 충분하겠지 라고 생각을했다. 그러나 실제 프로젝트를 진행하면서 client 개발자분은 다른 예외들을 더 많이 마주쳤고 해당 예외에 대해서는 별도의 처리가 안돼있어서 어디서 잘못된건지 알아볼 수 없는 형태였다. 예외가 터질때마다 연락을 하여 물어보는 비효율적인 방식을 개선하기 위해 위해 예외처리에 대해 알아보고 프로젝트에 적용을 하고 어떻게 더 개선할 수 있을까에 대한 고민을 글로 작성하였다. 본론 프로젝트를 진행하면서 client 개발자 분이 가장 자주 마주치는 Exception 들은 MethodArgumentNotValidException HttpMessageConv..

서론 Repository 계층 테스트 코드를 작성할때 처음에는 어플리케이션에서 사용중인 MySQL DB를 그대로 사용하였다. 그러다가 한 테스트에서 로컬에 저장되어 있던 데이터에 의해 테스트가 실패하였고, 물론 값을 바꿔주면 테스트를 통과하긴 하겠으나 이 테스트가 다른 사람 pc에서 안깨지려면 테스트 DB를 분리하는게 맞겠다는 생각이 들었다. Spring 으로 프로젝트를 진행할때 local DB 나 Test DB 로 H2 를 많이 사용하기에 나도 H2 DB 로 설정을 바꿔주고 테스트를 돌렸다. 그런데 잘만 돌아가던 테스트들이 깨지는 케이스가 발생했다. 이를 기억하고 앞으로 코드를 작성할때 주의해야겠다는 생각이 들어 이 글을 작성하였다. 본론 테스트가 깨진 경우는 2가지 였다. native query 사용..

서론 Data 계층 테스트 코드를 작성하기전에 JPA 복습을 하고 있었는데 이전에 공부할때는 그냥 넘어갔던 JPA의 Isolation 부분이 눈에 들어왔다. 고급 데이터 베이스 과목에서 배운 Repetable Read, Phantom Phenomon 등이 보여 흥미로워 복습도 하고 몰랐던 부분을 제대로 공부하기 위해 이 글을 작성하였다. 목차 트랜잭션이란? DB 트랜잭션 Level 에 따른 차이 JPA의 트랜잭션 수준 Optimistic Lock, Pessimistic Lock 트랜잭션이란? 랜잭션, ACID 는 데이터 베이스 과목을 수강하면 정말 많이 나오는 개념이다. 트랜잭션이 무엇일까? DataBase System concepts 7판에 나온 설명들에 따르면 하나의 logical unit을 실행하는..