Spring & Java

Setter를 지양해야 하는 이유? Setter를 사용할 경우에는 코드만 보았을때 한번에 뚜렷한 목표를 알기 어렵다. 객체의 역할 분리로 VO/DTO 가 가져가야할 Validation 영역이 Service 레이어에 남는다. 예시를 들자면 다음의 시나리오에서 유저

'Test는 어느 환경에서나 미리 구축할 필요없이 작동해야한다.'라는 개념과 어디에서나 자동으로 동일한 테스트 환경을 구축하는 라이브러리가 없을까? 라는 생각으로 출발하여 Test 실행시 서버 테스트에 필요한 환경을 자동으로 구축해주는 라이브러리를 찾아보았습니다.역시나

카카오 페이 과제중에 동시성을 처리해야하는 상황에 직면 했다.1\. 사용자 포인트 충전2\. 음료 주문예를 들어 상품 구매 시나리오에서 다음과 같은 과정이 필요하다고 생각해 보자.상품의 재고가 충분한지 확인상품 주문이때 락이 없다면, 상품의 재고가 1개만 남았을때 서로

TDD 를 하다 보니 테스트 케이스가 많아질 수록 테스트들을 한눈에 읽어내기 어려워졌고,클래스의 메소드별로 한번 더 분류하는 작업에 필요성이 느껴졌다.그렇다고 해서 하나의 메소드마다 테스트 클래스를 만들기에는 더 혼란 스러워 질것이 분명하기에 다른 방안을 찾아 보았다.

개발 환경 Springboot 3.3.1 JDK 17 Intellij Mac OS gradle 8.8 마켓 컬리 Redisson을 사용한 분산 락 위 링크를 참고하여 redisson 사용한 분산 락 구현중에 예상치 못한 오류에 직면 했다. Aop 에서 넘겨주는 pa

일하다 보면 주석에 대한 의견이 많이 갈린다'주석은 코드의 이해를 방해하는 나쁜 것으로 주석을 달지 않기 위해 노력해야 한다' 라는 주장과'주석은 코드의 유지보수성을 위해서 반드시 달아야 한다'라는 두 의견으로 팽팽하게 맞선다.개인적으로 둘다 맞다고 본다.실제로 현업을

JPA를 통해 회사에서 SI용 탬플릿을 만들때 공부했던 것입니다. 팀장님과 제가 테이블 관계가 1:N 의 경우 EAGER(팀장) vs LAZY(나) 전략중 무엇을 기본 전략으로 고를지 논의중이었을때. 이 글을 통하여 팀장님을 설득에 성공하여 LAZY 전략을 기본 전략으

신입때 나중에 필요하면 다시 보려고 evernote에 정리해둔 복잡한 join 쿼리입니다. 혹시나 mybatis를 사용하는 초보분들에게 좋은 자료가 되었으면 좋겠습니다.