이번 연도 3월에 취업해서 개발자로서 커리어를 시작하다가 이직을 하게 되어 바쁘게 지나갔는데 벌써 23년의 끝이다. 저에게는 조금 더 특별하게 생각되는 한 해였습니다 3월 ~ 7월 (퇴사) 23년의 목표는 빠르게 취업을 해서 커리어를 쌓아가고 싶었다. 그래서 아무렇지 않게 취업이라는 것만 생각해서 여건이 좋지 않은 회사에 들어가게 되었다. 들어가 보니 너무 바쁘게 달려오기만 했다. 서비스를 출시하기 위해 입사하고 3주를 빼고는 퇴사하기 전날까지 매번 아침에 출근하면 저녁 11시 이후로 가는 날이 많아졌다. 그러다 보니 체력적으로도 그리고 내 삶이 없어지며 추가적으로 회사의 재정적으로도 안전하지 않게 되어 퇴사를 하게 되었다. 8월 퇴사하고 3주가량은 조금 휴식을 가지게 되었다. 하고 싶었던 운동을 위해 ..
Dto에 NoargsConstructor를 사용하는 이유 코드를 작성하다보면 프로젝트를 오랜만에하면은 Dto에는 기본생성자를 생성해줘야하는지 매번 헷갈리며 이유를 제대로 알아보고자 합니다. @Data @NoArgsConstructor public class SignUpRequestDto { private String email; private String password; } 우선 생성자가 필요한 이유를 알기위해선 스프링이 어떻게 Dto를 JSON으로 매핑하는지 원리를 알아야합니다. 스프링이 매핑하는 원리는 Jackson라이브러의 ObjectMapper를 사용하여 JSON으로 매핑합니다. 여기서 ArgumentResolver는 JSON데이터를 객체로 변환하기 위해서 MessageConverter가 사용됩..
안녕하세요 이번글은 Home-Delivery프로젝트에서 주문을 하는과정 중 반복적인 읽기 요청을 하는 부분에 대해서 캐시를 적용하여 성능을 향상시킨 과정을 적었습니다. 문제상황 주문까지의 유저들의 사용과정을 예상한다면 앱에접속 -> 카테고리 선택 -> 매장리스트 조회 -> 매장 상세조회 메뉴,메뉴그룹 조회 -> 메뉴옵션 조회 -> 장바구니담기 -> 주문의 과정이 이루어집니다. 이와같은 작업들은 주문하기전까지 한번에 이루어지는경우도있지만, 여러사이클이 반복될거라 생각됩니다. 동일한 데이터에 대한 반복적인 DB 요청이 발생합니다. DB요청이 많으면 발생하는 문제는 DB접근은 커넥션 뿐만 아니라 DB자체에서의 연산도 느리니 DB요청을 적게하면 좋습니다. 요구사항 - 매장목록, 메뉴목록, 메뉴그룹목록, 메뉴옵션..
이번글은 저희의 home-delivery서비스는 유저 주문이 수락할경우, 주문취소, 라이더가 배달완료, 라이더가 음식픽업 시 알림이 가도록하기위한 알림 서비스를 구현하면서 경험을 작성하였습니다. FCM이란? Firebase 클라우드 메시징(FCM)은 메시지를 안정적으로 무료 전송할 수 있는 크로스 플랫폼 메시징 솔루션(교차 플랫폼)입니다. FCM의 주요 기능으로는 알림 메시지 또는 데이터 메시지 전송, 다양한 메시지 타겟팅, 클라이언트 앱에서 메시지 전송 이있습니다. 이 중 저희가 필요한 부분은 알림 메시지였습니다. FCM의 장점 1) FCM은 교차 플랫폼 메시지 솔루션이기 때문에 FCM을 이용해서 개발을 진행하면, 플랫폼에 종속되지 않고 Push 메시지를 전송할 수 있습니다. -> Web, Androi..
안녕하세요 이번글은 프로젝트 Unit 테스트코드와 Integration 테스트코드 작성시 발생했던 문제에대해서 작성하였습니다. 문제상황 팀원분이 했던 코드를 PULL를 받고 테스트를 돌리던중 발생했던문제가있습니다. - 팀원분의 Redis포트번호가 저와 다르기때문에 발생했습니다. - Redis는 테스트 코드 실행 후 롤백이 불가능하므로 깨지는 테스트가 존재했습니다. 생각한 방법 방법1. Docker컨테이너를 테스트코드를 실행하고 나서 Redis 컨테이너 삭제하자. 왜냐하면 레디스는 롤백이없기때문에 테스트를 종료시키는게 좋다고생각했습니다. 그런데 이 방법은 개발자가 직접 매번 작동해야한다면 이것은 매우 불편한 일입니다. 즉 향후 CI / CD도입을 하는데 도입의 목적은 자동화를 도입시켜 생산성을 향상시키는데..
안녕하세요, 이번글은 장바구니 로직을 로직완성을 하고 개선을 하기위해 겪었던 과정의 글입니다. 문제상황 저는 장바구니 로직중 메뉴를 지우는 로직은 이와같습니다. 1. 장바구니에 담긴 메뉴를 지웁니다. 2. 장바구니가 비어있는지 확인합니다. 3. 비어있다면 유저가 가진 매장정보 + 유저의 장바구니 정보도 지워줘야합니다. 이부분에서 로직한번에 db커넥션을 4번이나 해야하는 상황이 생깁니다. 🎈레디스도 커넥션 풀을 가질가? 레디스는 메인 프로세스가 싱글스레드인것이고 커넥션은 일반 디비처럼 커넥션풀을 씁니다. 레디스 커넥션 설정을 찾아보면 설정하는게 존해합니다. 커넥션이란게 어차피 데이터 전송이 다 끝나고 handshake까지 마쳐야 종료되는거라 메인 프로세스와는 별도로 여러개의 커넥션을 가지고 네트워크 rou..
안녕하세요 이번 주제는 배달 음식을 시킬때 장바구니를 구현을 하면서 겪었던 문제점 입니다. 저희는 배달의 민족 클론코딩이기때문에 아래 사진과 비슷하게 장바구니 UI를 생각했습니다. 지희가 원하는 서비스는 - 장바구니에 같은 매장 음식들만 담을 수 있다. - 같은 메뉴이지만 메뉴옵션이 다르면 다른 메뉴로 장바구니에 담아진다. - 수량은 한번씩만 변경할 수 있다. - 메뉴에서 같은 (메뉴+옵션)을 선택한다면 수량이 증가한다 위와같은 로직을 구현해야했습니다. 저는 레디스 저장소를 사용했습니다. 인메모리저장소를 사용한이유는? 왜냐하면 장바구니 특성상 유저들이 대부분 장바구니에는 담았다 지웠다 많이 조회가 많이 일어나기도 해서 db에 매번 I/O를 것보다 속도가 더 빠르다고 생각하기도 하였고, 추가적으로 장바구니..
이번주차에는 메뉴옵션과 장바구니 기능위해 코딩했던 한주였습니다 메뉴옵션은 메뉴와 비슷하기때문에 큰 어려움은 없었습니다. 그러나 장바구니 기능은 생각할게 많아서 복잡했습니다. 장바구니를 만들면서 고민해야할것은 생각보다 많았던것 같았습니다. 첫번째로 레디스를 사용하기위한 설정부터 시작해서 저장소를 분리해야하나 말아야하나 등 여러가지가 많았습니다. 자세한 내용은 장바구니를 구현한 회고보다 장바구니에 관해 제가 글을 따로 적겠습니다. 1. 이번주의 더 고민점은 rest ful한지 여부인것같습니다. rest ful하게 url을 짜는것이 이번프로젝트의 저의 목표중하나입니다. 그런데 문제점이 이제 로직들이 더 생기는데 GET : /menus 하면 메뉴들을 보여주는것인데 여기서 어떤매장의 메뉴인지 여부였습니다. 그래서..
안녕하세요 이번글은 제가 메뉴리스트를 우선순위별로 불러오면서 겪었던 문제입니다. 메뉴그룹과 메뉴를 불러와야하기때문에 저는 아래 코드와같이 1. 먼저 storeId가 존재하는지 확인하고 2. 매장의 메뉴그룹리스트를 불러옵니다. 3. 메뉴그룹리스트의 메뉴그룹의 아이디를 통해서 menuMapper를 통해 각 메뉴리스트들을 가져옵니다. MenuListResponseDto에는 ( id, List) 를 속성으로 가집니다. 쿼리에서 정렬을 수행해주기때문에 저는 이상이없다고 생각했습니다. 그런데 문제점이있습니다. 위의 코드와 같이 한다면 steam을 돌면서 매장의 메뉴그룹마다 db를 호출해야하기때문에 수가 많아진다면 n번 만큼 호출하게 됩니다. 그래서 다음 작업은 db호출을 줄이고 Map 자료구조를 이용하는방법입니다...
이번주는 메뉴를 만드는 작업을했습니다. 음 가장 고민했던것은 우선순위변경로직이였습니다. 배민에서 화면을 볼때 메뉴 그룹과 메뉴들이 우선순위가 존재합니다. 예를들어 세트메뉴, 단품, 사이드 메뉴와 같이 메뉴그룹이 존재하는데 이 우선순위를 변경할때 작업을 진행했습니다. 첫번째로 우선순위를 변경할때 하나만 변경되면 나머지도 함께 변경하고자했습니다. 그래서 자료구조를 통해 순서대로 넣어서 변경할려고했습니다. 그런데 이 로직에는 문제점이 많았습니다. 바로 하나만변경되는데 나머지들도 바꿔줘야하기때문에 뒤로밀려난다면 하나하나 꺼내서 바꿔주는것도 생각해야하고 로직상으로 많이 복잡했습니다. 그래서 만약 프론트가 데이터를 화면에보이는대로 위에서 아래로 우선순위를 받는다면 한꺼번에 업데이트를 하고자 하는걸로 변경했습니다. ..
