ultra_dev

📌 막연하게 어떨 것이다라고 생각하지말고 근거를 가지고 판단하기 대충 넘기려 하지 말고 왜 이 방법을 사용했는지 거기에 대한 구체적인 근거가 필요 머리 아프다 📌데이터베이스에 null이 들어가는 것과 객체에 null이 들어가는 것은 다르다는걸 깨달음

최종프로젝트 너무 힘들다!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 이미지 업로드 기능을 좀 알아봐야겠다. 📌 단방향..게시글 서비스에서 댓글 서비스 참조도 못하는 경우 댓글을 어떻게 받아올지 고민중 여태 너무 백엔드 관점에서 생각했나 싶다 게시글을 받아오는데 굳이 댓글까지 껴서 받아올 필요가 있나..? 게시글만 받아오고 댓글만 받아오고 프론트엔드쪽에서 한 화면에 보이게 딱 해놓으면 되지 않나? 프론트를 공부 안해봐서 잘 모르겠다. 공부 예정 📌 좋아요 갯수는 굳이 필드값으로 안넣어줘도 조회 시 Dto에 레포지토리에서 꺼내온 카운트값만 추가로 넣어줘도 될 것 같다. 📌 빌더패턴 생성자에 @Builder만 붙혀주니까 바로 사용가능해서 편했다. 확실히 가독성도 좋고 일반 생성자보다 편한 것 같다..

📌@ColumnDefault 이거 사용할 때 기본 디폴트값 넣어주기 조심!! "기본값"이 아니라 "'기본값'" 이런식으로 "" 따옴표 하나씩 더 들어가야.. 📌@DynamicInsert 인서트시 null인 필드 제외. 그래야 디폴트값으로 정해준 게 들어갈테니 📌jira 사용. 괜찮은 것 같다! 📌계층구조(제대로 다시 공부하기) 컨트롤러 -> 서비스 -> 도메인 -> 레포지토리 📌2개의 변수를 사용하는 status에서 boolean vs Enum 논쟁의 여지가 있지만 개인적으로는 Enum이 0과 1보다는 더 직관적으로 확인 가능하고 추후 확장성에서도 이점이 있을 것 같아서 더 타당해보인다. 참고 https://stackoverflow.com/questions/4337942/using-enum-vs-bool..

📌 API 복수명사여도 그냥 s 붙혀주자! 본인인증 user/me 같은 계층.. 다른 컨트롤러 쓸거면 /a/{aId}/b/{bId} 금지 쿼리파라미터로 받거나 a안에 b컨트롤러 기능들 집어넣든가 파라미터로 b받기 /b/{bId}?a-id=1 📌 조회할 때 게시글은 게시글만 댓글은 댓글만! 실무에서 그렇다함 📌 @OneToMany 사용 하지말고 객체 대신 그냥 id값으로 넣어주자 실무에선 거의 안쓰인다고 함