즐거운 개발자가 되자

프로젝트 코드 작성 중 EmbeddidId와 관련한 고려사항을 정리해보았다. 구현 목표 매일 자정을 기준으로 랜덤하게 갱신되는 Shop에서, 특정 수량을 구매하는 기능 구현 설계 Shop : 매일 랜덤한 아이템 리스트와 수량이 업데이트된다. (자정 기준) 구매하지 않더라도 시간이 지나면 목록에서 사라짐(ex. 로스트아크 떠돌이 상인) User : Shop에 갱신되는 목록 중 일부 아이템, 일부 수량을 구매할 수 있다(최대 수량 이하). Purchase : User의 Shop 구매 목록(중간테이블 역할) 작업내용 이전부터 Entity를 설계할 땐, 관계 설정 시 항상 비식별 관계로 참조되는 형태로 구성했다. @Entity public class Purchase { @Id @GeneratedValue(str..

3월달 업무 목표를 좀 일찍 끝내서, 오랜만에 개인 프로젝트 코드를 조금 작성해보았다. 업무에서 JSP, MyBatis 등을 다루다가 캠프에서 사용했었던 SpringBoot와 JPA를 오랜만에 사용해보니 감회가 새롭다. JpaRepository 캠프에서는 MVC패턴으로 프로젝트를 작성할 때, JpaRepository를 extends한 repository interface를 만들어서 사용했었다. @Repository public interface UserRepository extends JpaRepository { Optional findByLoginId(String loginId); Optional findByUserId(Long userId); } 이런 식으로 findBy@@(조건) 이라는 메서드를 i..

아이디 중복 검사 API요청 로직을 구현하던 중, 처음엔 별 생각없이 isDuplicated 라는 Boolean타입으로 중복일 경우 true, 중복이 아닐 경우 false로 반환하도록 작성하였다. 단순히 논리적인 관점에서만 봤을 때 isDuplicated라는 이름으로 true, false를 반환하는 것은 나름대로 직관적인 것처럼 보인다. 그런데 프론트단의 코드를 짜려고 보니 중복 확인을 한 결과가 true이면 생성이 불가능함을 안내해야 하는 상황에 뭔가 불편함이 느껴졌다. 물론 프론트에서도 변수명을 isDuplicated라는 이름으로 나타낸다면 제3자가 보고 해석하는 데 문제는 없겠지만, true인데 불가능함을 나타내는 것이 불가피한 상황이 아니라면 이렇게 작성하는 것이 옳은가에 대한 생각을 하게 되었다..

TODAY'S WORK - 기획 초안 작성 - 기본 Class 제작 https://nosy-harpymimus-e01.notion.site/HI-SERVER-58b8708e039544c98eb2c775ca2c3a76?pvs=4 HI-SERVER | Built with Notion 개요 nosy-harpymimus-e01.notion.site