민팽로그

[Spring] DTO 사용 시 필요한 lombok annotation [Spring] DTO 사용 시 필요한 lombok annotation 요즘 프로젝트 리팩토링을 하면서, DTO에 작성하는 여러개의 lombok 어노테이션의 사용 이유를 정확히 알지 못하고 사용하는 것 같아서 하나하나 고찰(?) 해보기로 했다. 일단, DTO는 Data Transfer Object codingwell.tistory.com 자바 리플렉션 (Reflection) 기초 자바 리플렉션 (Reflection) 기초 리플렉션 (Reflection) JVM은 클래스 정보를 클래스 로더를 통해 읽어와서 해당 정보를 JVM 메모리에 저장한다. 그렇게 저장된 클래스에 대한 정보가 마치 거울에 투영된 모습과 닮아있어, 리플렉션 hudi...

1. CustomException 나중에 에러 추적 & 디버깅을 위한 로그를 남기고 프론트쪽에 에러에 대한 정확한 메세지를 전달해주기 위해 에러 코드와 에러 원인을 반환해주어야 할 필요성을 느낌 RuntimeException을 상속받는 커스텀 예외 클래스를 만들어서 사용 에러는 에러 코드와 에러 메세지로 enum 클래스에 상수 형태로 관리 예외 처리를 위해 오류를 검사하는 역할을 하는 클래스를 따로 만들어 둠 컨트롤러에서 CustomException이 발생하면 이를 처리하는 RestControllerAdvice 클래스를 구현 에러 내용을 기록하는 로깅도 필요할 것 같음 구현 사진 더보기 2. Swagger 전에는 POSTMAN에 API 명세서를 만들었는데 이 작업이 상당히 귀찮았음.. Swagger를 사..

지난 프로젝트에서는 순환참조 문제 해결을 위해 어노테이션(@JasonManagedReference, @JsonBackReference)을 사용했는데, 면접에서 다른 방법을 알고 있냐는 질문에 대답하지 못하였다. 좀 더 알아보니 컨트롤러에서 엔티티를 반환하기 보다는, 가능하면 DTO를 사용하여 반환하는게 가장 좋은 방법이라는 것을 알게 됐다. 엔티티를 DTO로 감싸서 반환하면 좀 더 안전하게 사용할 수 있다. 일단 엔티티 객체는 테이블과 매핑되는 객체이기 때문에 값을 쉽게 수정해서는 안된다. 따라서 @Setter 어노테이션은 가급적 사용하지 않아야 한다. DTO는 데이터를 전달하기 위한 객체이기 때문에 @Getter, @Setter를 모두 사용해도 괜찮다. DTO에 필요한 데이터만 선정해서 반환해줄 수도 ..

배포 환경에서 발생하는 쿼리나 오류 로그를 알 수 없어 파일에 저장하는 김에, 개발 환경과 배포 환경의 로그 환경을 분리하여 설정하게 됨. https://velog.io/@shawnhansh/SpringBoot-logback-%EB%8D%94-%EC%89%BD%EA%B2%8C-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0application.properties%EC%99%80-logback-spring.xml https://livenow14.tistory.com/64 https://oingdaddy.tistory.com/256 요로캐 참고했음. spring boot는 application-properties에 적힌 로그 설정 먼저 확인 후 resources 폴더에 있는 logback-..

저번 프로젝트를 진행할 땐 N+1 문제를 신경쓰지 않았다. 나중에 공부를 하다보니 이런 문제가 발생할 수 있구나 정도로만 알고 있었다. 그리고 이번 프로젝트를 진행하면서 sql 쿼리를 콘솔에서 확인하다보니, 의도한 것보다 select 쿼리가 훨씬 많이 발생하고 있다는 것을 발견하고 N+1 문제를 정리해보게 되었다. N+1 문제란? 1. 즉시 로딩과 지연 로딩 즉시 로딩: 연관 관계에 있는 엔티티를 사용하지 않아도 한번에 바로 로딩. 비어있는 내용은 프록시 객체로 대신함. 지연 로딩: 연관 관계에 있는 엔티티를 바로 로딩하지 않고 사용하는 시점에서 로딩 연관된 모든 엔티티를 매번 즉시 로딩하는 것은 좋은 설계가 아니다. 해당 엔티티의 조회가 필요할 때마다 조회하는게 좋다. 2. 기본 패치 전략 @ManyT..

한이음 프로젝트가 시작되고 6월 말까지 프로젝트 설계를 진행했다. 엇 근데 머쓱한건 프로젝트 이름을 한동안 유행했던 가보자고~로 정했는데 시기적절하게도.. 네이버에서 서울 가보자고 서비스를 냈다...이름이 똑같...! 핳 나는 백엔드를 맡았기 때문에 백엔드 설계를 중심으로! 1. 요구사항 정의 및 WBS - 요구사항 정의서 예시 - WBS 예시 2. 화면 설계 피그마를 이용해 작성했다. - 화면 설계: https://www.figma.com/file/k2k6iXtsjObhdJ0QKHxBhU/MZ%EC%99%80-%22%EA%B0%80%EB%B3%B4%EC%9E%90%EA%B3%A0%22 Figma Created with Figma www.figma.com 3. DB 설계 DB를 설계할 당시 마침 계절학기..

알게 된 것 1. onCreate() -> onStart -> onResume() 순으로 호출됨 -> 필요에 따라 적절히 사용 가능 2. Thread 실행이 끝나기 전에 다른 작업 수행으로 인한 오류를 해결하기 위해서, sleep을 두거나 join()을 활용하여 실행 순서를 제어할 수 있음 3. 리사이클러뷰와 카드뷰를 사용하여 스크롤 기능을 갖춘 카드 리스트를 만들 수 있음: 리사이클러뷰를 담는 레이아웃, 데이터를 저장하기 위한 클래스, 카드의 뷰?를 다룰 수 있는 뷰홀더, 뷰홀더와 리사이클러뷰를 연결하는 어뎁터 등이 필요했음(추상클래스 상속받아 구현 필요) 4. rest api의 method 중 delete는 규칙상? body를 가질 수 없음! 기억에 남는 점 오류 발생 시 가장 힘들었던 쪽이 thre..

중간보고서를 최대한 체계적으로 작성하려고 노력했는데, 요구사항 정의서, 메뉴 구성도, 화면 설계서, 엔티티 관계도 등 많은 내용을 구체적으로 작성해 보기가 처음이라 그런지 어려웠다. 보고서 작성이 어떤 프로젝트를 얼마나 진행했는지에 관한 지표라는 점에서도 의미가 있지만, 이번에는 다른 의미가 있다는 것도 살짝 느꼈다. 보고서를 구체적으로 작성하는 과정에서 프로젝트 기획, 설계 과정에서의 문제점들이 크게 드러나서 좋은 아이디어가 떠오르지 않았던 나로써는 상당히 고통스러웠다.... 부족함을 알 수 있는 것과 동시에 모호했던 설계 계획들을 더 구체화할 수 있어 보고서 작성 전보다 좀 더 완성도 있는 프로젝트 설계에도 도움을 준다는 것을 느꼇다. 앞으로 다른 프로젝트를 하면서도 이렇게 보고서를 자세하게 작성하게..

기획서 공모전 첫 도전이었다. 급하게 준비했기 때문에 결과보다는 경험에 의의를 두는 것이 좋다고 생각한다. 😊😀 기획서도 처음 써보았다. 첫 기획서 검토 회의때 멘토님이 굉장히 지적을 많이 하셨다. 요약하자면, 주제가 명확히 드러나야 하며 중요한 내용은 강조가 되어야 함. 제품 명은 직관적으로 지어야 함. 서비스의 주제가 명확히 드러나도록 작해야 함. 제품 서비스 개요는 매우 중요한 부분임. 대상 타겟층과 서비스가 필요한 이유가 뚜렷하게 드러나야 함. 충분한 내용을 담을 수 있을 만큼 길게 써주는게 좋음. 제품∙서비스의 목적 및 필요성 등 도입 부분은 줄글로 가독성이 떨어지게 쓰지 않도록 함. 순번을 메기거나 소주제를 정하는 것이 좋음. 이렇다. 확실히 멘토님 말씀을 토대로 수정하니 부족한 기획안도 퀄리..

기억에 남았던 멘토님 말씀 공모전 참여의 의의 1) 공모전 탈락 후 억울해서 눈물날 정도거나 탈락한 이유가 이해가 안돼 다시 도전하고 싶은 마음이 드는가? 수상자들과 우리같은 팀들의 기본적인 차이는 "문제 색출 -> 해결방안 찾기"과정의 정교성임. 무언가를 해야한다는 의미로 참여한 것이었기 때문에 어떤 문제를 꼭 해결하고 싶어서 구체적으로 몰두하는 사람들과 비교하면 차이가 뚜렷하게 드러남. 특히 1차 합격 후 합격자들의 공모전 발표를 들어보면 어떤 문제를 반드시 해결하고자 기획한 아이디어에는 그만큼의 몰두와 연구가 있었다는 점에서 명확한 차이가 남. 2) 지속적인 발전과 도전이 중요 1차 합격이나 수상보다는 부족했던 점, 잘못했던 점을 깨닫고 계속 도전하는 자세가 더 중요함. 그런 것을 경험하고 깨달았다..