같이 일하고 싶은 개발자

Keep (이번 프로젝트에서 좋았던 점을 통해 앞으로 유지(Keep) 할 사항) 2명씩 팀을 매칭해서 분업하는 구조 속에서 얻는 지식의 스펙트럼 고정된 사고를 깨버림으로서, 다시 한번 놓인 부분을 점검할 수 있었다. 항상 긍정적인 마인드셋, 그 속에서 얻는 최강의 시너지! 코드 리뷰 코드 윗미 기능을 활용한 개발 방식 항상 열린 질문과 답변 이번 프로젝트에서는 팀원들을 지도하고, 프로젝트의 방향성을 정하며, 평소에 내가 놓치고 있었던 부분이나, 고정적인 사고의 틀을 벗어나고 유연한 코드를 작성할 수있도록 도와준 미니 프로젝트라 생각한다. 메서드를 구현하는데, 계속 고정관념에 사로잡혀서 어떻게 이를 해결하면 좋을까?에서 멈춰있던 내 사고를 깨버리는 사건도 있었고, 어떤 코드에 관해 생각하는 바가 다르니 서..

심화 프로젝트 - KPT 회고 KEEP 다같이 API를 직접 작동시켜 QA를 진행함 의미있는 commit message와 Git 전략의 사용 시작 단계에서 API 문서 작성을 하여 개발 단계에서 참고하면서 개발 할 수 있었던 점 일정에 맞춰 계획한 코드를 모두 구현 한 점 상호 피드백을 통해 더 나은, 더 클린한 코드를 작성하도록 노력 domain별로 폴더를 구성한 점 PROBLEM 정해놓은 구현목표 이외의 도전해보지 않았음 맡은 기능에만 충실하여 다른 팀원들의 코드를 아직 완벽하게 다 이해하지 못한 점 의미있는 데이터에 관한 생각 어떻게하면 더 clean하게 code를 작성할 수 있을까? 테스트 코드를 작성하여 테스트 못해본 점 TRY 테스트 코드 작성 해볼 것 데이터를 더욱 효율적으로, 그리고 의미있..

FACTS(사실, 객관) : 이번 일주일 동안 있었던 일, 내가 한 일 query dsl 학습 및 심화 프로젝트 진행 심화프로젝트를 빠르게 완성시키고 추가 구현사항 혼자 만들어 보면서 해당 로직을 검증 test case 만들어서 모든 경우의 수 생각해보기... FEELINGS(느낌, 주관) : 나의 감정적인 반응, 느낌 집중하자, 빨리 query dsl이랑 이것저것 공부해서 시간을 효율적으로 써야겠다 FINDINGS(배운 것) : 그 상황으로부터 내가 배운 것, 얻은 것 query dsl 로직 한 메소드는 하나의 책임만 해야 한다 FUTURE(미래) : 배운 것을 미래에는 어떻게 적용할 지 1. query dsl 적용해보기 - 사용할 것

들어가기 스웨거 적용해보기 마무리 들어가기 처음으로 스웨거라는 라이브러리를 적용해보았다. 스웨거는 API를 자동으로 문서화 해주는 기능으로, 사용자가 직접 test 까지 해볼 수 있는 장점이 있다. 스웨거? Rest Apu를 문서화 혹은 빌드 등을 위해 사용하는 OpenAPI 사양을 중심으로 구축된 오픈 소스 도구 세트 https://swagger.io/ API Documentation & Design Tools for Teams | Swagger swagger.io 기존에 진행했던 프로젝트들에선 postman과 직접 노가다?를 통해 API 명세서를 작성했었는데, 이를 사용함으로서 더욱 깔끔하고 편하게 작업을 진행할 수 있었다. 이로서 생산성을 높일수 있는 장점이 있었다. 스웨거 적용해보기 먼저 첫번째로..

새로운 어노테이션을 알게 되었다. @DynamicInsert : insert 시 null인 필드를 제외한다 @DynamicUpdate ; update 시 null인 필드를 제외한다 해당 어노테이션을 Entity에 사용하고 쿼리문을 확인해보면 DynamicInsert 는 컬럼의 지정된 default 값을 적용시킨다. 기존에 @Query 파라미터를 이용해 데이터를 조회하고, 삭제 등 여러 기능에서 만들어서 사용했었는데, 어쩌다 이야기를 하다보니 NativeQuery라는 키워드가 언급되서 찾아보게 되었다. Native Query란 SQL을 직접 정의해서 사용하는 방식이다. 아! @Query 파라미터를 이용해서 쿼리를 직접 작성하는 방식이 네이티브 쿼리구나!

궁금한 점을 튜터님께 여쭤보면서 피드백을 받게 되었다. 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..