같이 일하고 싶은 개발자

궁금한 점을 튜터님께 여쭤보면서 피드백을 받게 되었다. 1. 우선 Entity 자체를 반환하는 것. 왠 일인지 모르겠는데, 평소에 잘 지키던 규칙을 깨버렸다. 수정해야겠다. 2. 한 서비스에서 다른 레포지토리를 DI하는 것, 만약 이렇게 서비스에서 다른 레포지토리를 DI하는 것은 의존성이 높아진다 예를들어서 board의 입장에서 comment를 모르는 것 처럼, service를 참조해야지 직접 레포지토리를 참조하게 되면 안된다. 키워드 : 단일책임, 접근 루트

대량의 데이터를 삭제하게 되면서, 쿼리문을 확인하게 된 사건에서 이 이슈가 발생했다. 과연 데이터를 삭제할 때, 그 데이터가 방대하다면, JPA는 어떻게 쿼리를 만들어서 뱉을까? 확인해본 결과 JPA에서는 deleteByxx 이런 쿼리를 사용할 시 데이터를 하나씩 delete 했다. 이러한 내용을 in query를 이용해서 한줄의 쿼리로 성능 최적화를 이루어 냈다. 또한 SQL 문제를 해결할 때 ,발생했던 오류가 있었는데, 왜 이 오류가 발생했는지를 확인하며 학습하는 하루였다. 2023.01.14 - [스프링/JPA] - 만약 대량의 데이터를 지워야 할 일이 있다면??? (JPA) 2023.01.14 - [오류발생과 해결] - [Error] QueryExecutionRequestException : No..

목차 0. 프로젝트 소개 1. 팀 소개 2. ERD & API 명세서 3. 어려웠던 점이나 느낀 점 4. Git 코드 공유 👂프로젝트 소개 "개인 과제로 진행한 내용을 바탕으로 팀 별 협업을 이용한 간단한 백엔드 블로그 만들기" Spring 기본-숙련-심화 과정에서 얻은 지식을 바탕으로 팀 별 백엔드 블로그를 제작함으로서 Spring에 대한 이해도를 높이고 더 나아가 협업과 소통능력을 향상하기 위해 해당 프로젝트를 진행. ⛏ 개발환경 및 기술 Spring Boot 2.7.7 Lombok Spring - data - JPA Java 11 Database - H2Database, MariaDB Gradle Spring Security Jwt Git, Notion, Zep ⏰ 진행 기간 : 2022년 12월 ..

들어가기 본론 마무리 들어가기 만약 우리가 게시물을 지워야 한다면? 게시물과 연관된 테이블의 데이터를 먼저 지운 후 게시글을 지워야 한다. 게시물은 하나만 지우면 끝이지만, 게시물에 작성된 댓글이 만약 무수히 많다면? 게시글 - 사용자 : Many to One (다대일) 게시글 - 댓글 : Many to One (다대일) 만약 윗 코드처럼 댓글을 지우게 된다면 댓글의 갯수많큼 delete 쿼리가 발생할 것이다. 댓글이 많이 존재하지 않으면 괜찮은데, 이 댓글이 무수히 많다면? 성능상에 이슈가 발생할 여지가 생길 것이다. 어떻게 이를 해결할 수 있을까? 본론 이 글의 시작은 게시물에서 시작되었다. 예를 들어서 1번 게시물을 지우고자 할때, 윗 그림에서 확인할 수있는 것처럼, 연관관계가 맺어져 있기에 연관괸..

직접 @Query 파라미터를 통해 데이터를 지우려고 했을 때, 발생한 Error로 쿼리유형이 잘못 동작했을 때 발생하는 타입이다. 이를 해결하기 위해서는 해당 query 메서드를 실행한 곳에 2개의 어노테이션을 추가해줘야 한다 @Modifying @Transactional @Modifying 메서드는 Query 어노테이션으로 작성된 insert나 update, delete 쿼리를 사용할 때 필요로 한다 (주로 벌크연산을 하나의 쿼리로 수행할 때 사용 ) 벌크 연산 관련 참고자료 :( https://data-make.tistory.com/617 ) @Modifying 공식문서 ( https://docs.spring.io/spring-data/data-jpa/docs/current/api/org/spring..

인프런 실전! 스프링 부트와 JPA 활용 2편을 듣고 정리한 내용은 다음과 같다 DTO 속에서도 Entity를 가지면 안된다 (ex. List). 이는 엔티티 스펙이 외부에 노출되며, 완전히 entity에 대한 의존을 끊어야 한다. (Entity가 바뀔 위험이 있으니까) N+1의 문제를 다시 접하게 되었다 ( 정리할 것 - 면접 단골 질문 ) 일단 모든 연관관계는 지연로딩 (Lazy)로 설정해놓고 필요하다면 fetch join을 사용할 수 있어야 한다. 이는 실무에서 매우 중요하게 작용하며 JPA를 사용하는 곳에서 대부분의 성능 최적화는 fetch join을 통해서 이행된다. 이 fetch join을 직접 작성하고 눈으로 확인해보니 확실히 쿼리가 줄어들었다. 또한 Repository는 순수한 엔티티를 조..

이제서야 그간 진행한 미니 프로젝트에 관한 KPT 회고를 정리해서 올려본다. KEEP 소통 GIT 활용 좋은 분위기 열린 피드백 아직 교육과정이 많이 진행되지 않아서 다른 팀은 팀원끼리 소통이 부재함을 많이 느끼게 되었다. 소통의 부재는 결국 팀의 분위기를 좌지우지 한다고 생각한다. 그러나 우리팀은 서로 간 벽을 허물고 누구나 편하고 쉽게 접할 수 있도록 서로 칭찬하고 농담도 던지며 다른팀에 비해 활발하고 적극적인 스탠스를 취했다고 생각했다. 그런 결과가 Keep으로 나타나지 않았나 라는 생각이 들었다. 또한 git을 활용해본 팀원들이 많아서 조금은 편하게 협업을 진행했다 . 개발자에 있어서 피드백은 매우 중요하다고 생각한다. 그 피드백으로 하여금 나는 새로운 인사이트를 얻고, 내가 모르는 지식을 습득하..

0. 프로젝트 소개 1. 팀 소개 2. 체크리스트! 3. 어려웠던 점이나 느낀 점 4. Git 코드 공유 들어가기 0. 프로젝트 소개 호텔 프로젝트보다 조금 더 신선하고, 다양한 기능은 물론 조금 더 객체 지향 설계를 할 수 있을 것이라 생각해 은행 프로젝트를 선택했으며, 주어진 요구사항에 맞춰 간단하게 은행 서비스를 구현해보며 객체 지향을 이해하고, 커뮤니케이션 능력 향상을 위해서 미니 프로젝트를 진행했다. 1. 팀 소개 👲🏻 저희 팀 이름은 소림사입니다! 팀 이름이 소림사인 이유는 서로의 공통점을 찾다 파생된 소림사라는 단어에서 고수라는 단어를 떠올리면 중국의 소림사가 생각이 나 이 점에서 영감을 받아 “우리도 실력을 갈고닦아 고수가 되자”라는 의미에서 소림사를 팀 명으로 정하게 되었습니다. 팀원 소..

FACTS(사실, 객관) : 이번 일주일 동안 있었던 일, 내가 한 일 시큐리티 뜯어보기 중간 프로젝트 진행 Stream과 for loop FEELINGS(느낌, 주관) : 나의 감정적인 반응, 느낌 나름대로 시큐리티를 이해했다고 생각했는데, 아직 에러를 해결하지 못한거 보니 이해도가 부족함을 느꼈다. 시큐리티에 발목잡혀서 현재 next step으로 넘어가지 못하고 있다. 내용이 어렵다기보단 답답하다. 해결을 못하니까 시큐리티를 정복하고싶다. FINDINGS(배운 것) : 그 상황으로부터 내가 배운 것, 얻은 것 Spring Security https://jipang9-greedy-pot.tistory.com/134 https://jipang9-greedy-pot.tistory.com/135 Stream..

금일 학습 과정에서 얻게 된 정리 - 즉시로딩 사용 시 - JPQL - Query는 다 발생하지만 정작 데이터는 똑같이 들고옴 ( 쓸모없는 쿼리가 나간다는 뜻이겠지?), 이렇게 쿼리가 다 나가니까 성능 최적화를 할 수있는 여지가 줄어든다 - 가급적이면 사용하는 데이터만 API에 노출하는게 맞다 ( 사용자 정보 문제 ) - Entity를 리턴값으로 넘기게되면 불필요한 데이터의 노출은 물론 변경시 문제점이 많이 발생한다 - 그래서 별도의 DTO를 만들어서 사용한다는 점 - Entity에는 표현계층의 기능들이 들어가면 x