같이 일하고 싶은 개발자

최종 프로젝트가 진행된지 어느덧 3/5 정도가 지났다. 이 기간동안 정말 많은 일들이 있었고, 많은 감정들을 느끼게 되었다. 그런 내가 보고 듣고 느낀 감정들을 회고하고, 글로써 표현함으로써 내 감정에 더욱 솔직해지고, 내가 더 성장하기 위해 글을 남긴다. 정말 많은 고민을 하게 된 한 주였다.. 내 감정에 솔직해져보자.. 나는 성장하고 싶은 사람이다. 그래서 욕심이 많다. 물욕이 많은게 아니라 더 성장하고 싶은 욕심이 많다. 그래서 항상 나의 성장에 포커스가 맞춰져있다. 어떻게하면 내가 더 성장할 수있을까? 결국 내가 성장하려면 한걸음 더 나아가야한다고 생각하고, 고민의 스펙트럼과 계속해서 더 나은 방향으로 고민하고, 나아갈 수 있도록 의견을 제시해야한다고 생..

최종 프로젝트가 시작한지 어느 덧 1일정도 지나가고있다. 오랜만에 서비스를 A-Z까지 기획하고, 설계하며 여러 고민들 속에 최고의 결과물을 도출해내기 위한 이 과정이 너무나도 재밌다. 개발도 개발 나름이지만 기획도 매우 재밌다. 옛날부터 뭔가 나는 누군가를 대상으로 이벤트 기획하고, 기획한 행사를 주도해서 이끌거나, 항상 집단을 리드하고자 하는 성향이 강했다. 이러한 성향덕에 적게는 몇 백 많게는 천 명 단위의 집단도 이끌어보며 이 속에서 좋은 추억과 경험을 간직하고, 또 내 나 자신이 스스로 성장할 수 있도록 많은 환경들을 만들어 냈다. 각자의 속도와 배경 지식들은 능력은 다 제각각이다. 나도 맨처음 누군가 잘 따라오지 못하고, 방황하거나, 엊나가면 "왜 저사람은 그럴까?" 라는 생..

최근에는 어떻게하면 검색효율을 높일 수 있을까?에 관한 고민과 동적 쿼리에 관한 고민속에서 얻은 해답 중 하나인 Query dsl을 학습했다. 매일매일 이렇게 TIL로 남기기에 애매하다고 생각해서 학습을 끝내고 복습하는 과정에서 정리를 진행하고, TIL을 작성해야겠다고 생각했기에 요 최근엔 TIL이 밀렸었다. 매일매일 학습한 내용을 뭔가 글로써 남기기 어려워졌다. 이렇게 생각한 이유는 과거에 모르던 부분이 많아서 매일매일 학습한 내용을 정리하며 TIL을 작성하거나 블로그에 글을 써내려갔었는데, 이제는 그래도 어느정도 아는 부분이 생기다보니 블로그에 포스팅 하는 빈도수가 줄었다. 그렇다고 해서 공부에 부실하는 것이 아닌, git에는 매일매일 commit 하도록 노력하고 있으며 Commit Message를 ..

들어가기 스웨거 적용해보기 마무리 들어가기 처음으로 스웨거라는 라이브러리를 적용해보았다. 스웨거는 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..

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

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

오늘은 직접 간단한 @Test 예제를 통해 직접 테스트를 해보고, 왜 이 테스트가 필한지 이 리팩토링이 왜 필요한지를 직접 몸으로 느끼게 되었다. 개발자의 입장에선 불필요한 자원의 낭비나, 내가 구상한 방향으로 flow가 진행되지 않는다면 잘못된 결과를 초래할 수 있는데, 이는 곧 책임에 맞지 않는 코드를 사용하는 것과 같은 맥락이다. 보통 main() 메서드에 해당 메서드에 값을 전달해서 찍어보는 방식을 사용하거나 @slf4j라는 log를 찍도록 도와주는 어노테이션을 사용해서 올바른 데이터가 들어오는지 등 방식을 사용했다. 물론 이러한 방식이 잘못되었다는 것은 아니나, 만약 코드가 엄청 복잡해지고, 길어진다면? 과연 코드만 분리한다고 해서 우리가 가진 근본적인 문제를 해결할 수 있을까? 등 여러 고민들..