수많은 우여곡절 끝에 배포된 서버에 채팅 기능을 적용하게 되었다!간단히 말하자면 원래 담당했던 백엔드 팀원이 던져놓은 빅 똥을 치우게 되었다.내 프로젝트의 스택은 아래와 같다.Java 17 / Spring 3.x / JPA / Redis / Spring Security / JWT / OAuth / Websocket / MySQL / Firebase그리고 처음 팀원이 던져놨던 채팅 구현을 위한 기능은 Kafka + Socket.io 였다. 내가 알기로 Kafka는 MSA구조에서 그룹으로 묶어 메세지를 전달하는 메세지 큐 방식에 적합한 절대 가볍지 않은 스펙의 프레임워크였으며, Socket.io 또한 Spring으로 만든 프로젝트가 아닌 별도로 서버가 생성되는 과정을 요구하는 방식이였으나 팀원을 믿고 기다렸..

트랜잭션 문제중 맞닥뜨렸던 내용을 다시 찾아보지 않기 위해 기록한다...아래는 내가 겪은 예외내용이다. TransientPropertyValueException 예외에 대한 내용이며 영속성 컨텍스트에 퐇마되지 않은 상태의 데이터를 사용하려 하니 발생하는 문제였다.org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.TransientPropertyValueException: object references an unsaved transient instance - save the transient instance before flushing : com.mentit.mento.global.authToken.entity.SocialA..

요즘 AI 생성형 도구중에 가장 핫하다는 Cursor를 사용중인 사람들이 많을 텐데 Chat GPT에 사전 튜닝을 할 수 있듯이 Cursor도 사전 튜닝이 가능하다.그래서 이번 글에서는 간단히 ChatGPT와 Cursor에서 사전 설정을 할 수 있는 방법과 이 설정에 대해 미리 만들어 놓은 셋팅들을 가져올 수 있는 사이트 및 깃허브 레포를 소개하려고 한다! Chat GPT 사전 맞춤 설정아래처럼 내가 원하는 방식으로 사전에 설정을 할 수 있다.나는 백엔드 자바 개발을 위주로 하고 리팩토링 또는 예외처리에 대한 내용을 주로 물어봐서 아래와 같은 조건을 설정했다.1. 자바 백엔드 개발중이다.2. 리팩토링을 할 때는 수정한 코드위에 주석을 달아달라.3. 문제가 발생하는 원인에 대해 자세한 설명 및 개선방안 제..

Soft Delete 방식으로 데이터를 관리중이던 나는 @Where 메서드가 Deprecated된 것을 발견하였다...!이제 뭘 써야 고민하던 중에 Cursor AI 툴로 리팩터링을 참고하며 진행하던중 @SQLRestriction 이라는 어노테이션을 발견할 수 있었다.보자마자 이건 누가봐도 동일한 방식으로 사용하 수 있겠다 싶어서 내부 소스코드에 대한 설명을 읽어보았다. Specifies a restriction written in native SQL to add to the generated SQL for entities or collections. For example, @SQLRestriction could be used to hide entity instances which have been so..

2024.11.30 - [Spring/프로젝트 리팩토링 회고록] - 레이어 아키텍처 구조 개선하기모든 테스트가  h2를 필요로 한다?설계가 잘못되었을 수 있다. 테스트는 외부 객체의 주입을 받지 않은 상태에서도 동작할 수 있는 유닛 테스트가 필요한 경우가 있기 때문이다.또한 작성한 테스트가 실제로 테스트가 필요한 본질적인 책임을 갖고있는 객체가 아닐 수 있다. 레이어드 아키텍처의 구조레이어드 아키텍처는 유사한 기능들을 하나의 계층으로 묶어서 각각의 책임을 지게하는 구조이다.가장 쉽고 눈으로 봤을때 한 눈에 보인다는 장점이 있어 가장 많이 쓰이기도 한다. 하지만 이 아키텍처는 여러가지 단점이 있다.아래 이유를 적어놨지만 한 마디로 말해서 절차지향적인 코드를 작성하게된다. 우리는 자바를 객체지향적인 특징이 ..

테스트 코드를 작성하게 된 계기Swagger로 테스트를 해오던 나에게 더 이상 Swagger만으로는 테스트에 한계가 있다는 것을 깨달았다.그 이유는 이것저것 여러가지가 있었지만 요약해서 세가지이다.첫 째, 모든 상황은 가정하고 코드를 작성했는지 별도의 문서가 필요했다. 어떤 상황에 어떤 예외가 발생해야하는지 상황에 대한 제어를 내가 최대한 꼼꼼하게 해야하지만 스웨거만으로는 그 부분을 체크하기 어려웠다.둘 째, 어떤 메서드가 어떤 용도로 쓰이는지 별도의 문서가 필요했다. 테스트 코드를 작성함으로써 내가 의도하고 작성한 부분들을 바로바로 찾아가기가 어려웠다.셋 째, 내 프로젝트가 유연하고 확장에 용이한 코드인지 확인하기 어려웠다. 레이어드 아키텍처의 고질적인 문제인 의존성 문제를 해결해야 테스트 코드 작업이..