같이 일하고 싶은 개발자

이번에 정리한 내용은 팀 문화 중 하나인 지식 공유 시간에 Redis에 대해 간략하게 발표한 자료입니다.  [서론]레디스(Redis)를 설명하기에 앞서 캐시(Cache)에 대해서 먼저 간단하게 설명하고자 합니다.범용성 있게 일반적으로 3 tier Architecture의 구조 채택ClientServerDataBase이러한 계층형 구조를 Layerd Architecture(레이어드 아키텍쳐 / 계층형 아키텍쳐 ) 라고 칭함 그러나!!! 윗 구조에서는 명확한 한계점이 존재!바로 서비스가 폭발적으로 성장해 사용자가 많아지고, 실시간으로 요청하는 API 수가 많아짐에 따라 서비스의 부하가 상승하는 경우우리는 아키텍쳐를 분리하거나 캐싱이라는 기능을 사용해 서비스 어플리케이션에서 발생하는 성능의 문제를 해결할 수 ..

사내 팀 내 개발 문화를 도입하면서 공유한 내용입니다.  간단하게 어떤 개발문화를 도입했는지에 설명하자면 다음과 같습니다. - 팀원들 개인의 경험 공유 및 지식 나눔으로 매주 목요일 번갈아가며 진행- 발표자는 자유 주제로 팀원들과 소통- 무거운 주제도 괜찮지만 되도록 가벼운 주제로- 다른 개발의 영역이라도 자유롭게 참가 가능- 주 목적은 같이 성장하기 이미 여러 다른 회사들에서는 이러한 개발문화를 도입했을겁니다.이는 팀 내의 역량을 증진하고 더 나아가 발표를 하기 위해, 발표를 듣기 위해 자신의 지식을 점검하며 같이 성장하기에 주 목적이 있습니다   간단한 설명은 이쯤에서 끝내고 발표 준비한 내용을 공유도록 하겠습니다. 목차N+1 문제의 흔한 착각여러분은 Page와 Slice를 아시나요?DirtyChec..

[ 바로가기 목차 ] 들어가기 알아보기 마무리 [ 들어가기 ] 여러 테이블 혹은 DB에서 데이터를 가져와서 원하는 작업을 하는 방법에는 여러가지가 있습니다. 가져온 데이터를 원하는 형식이나 여러 객체를 하나의 객체로 합치는 일은 매우 흔한 일입니다. 이때 이러한 매핑 작업을 직접 개발자가 하게 된다면 문제가 발생할 수 있습니다. - 코드의 중복 - 생산성 저하 - 실수로 인한 데이터 누락 - 복잡한 로직까지 추가된다면 코드 가독성 저하 이러한 문제를 해결하기 위해 스프링(Spring)에서는 라이브러리를 지원합니다. - Mapstruct - ModelMapper 맵 스트럭트(MapStruct) 와 모델 매퍼(ModelMapper)의 차이점을 간단하게 설명하자면 객체의 생성 방식에 조금의 차이를 가지고 있습..

[ 목차 ] 들어가기 레이어드 아키텍쳐 장점> 참고 레퍼런스 [ 들어가기 ] 개발자는 어떻게 하면 더욱 코드를 효율적으로 작성하고, 유지보수가 쉽고, 성능이 좋은 코드를 작성할 수있을지 고민을 해야합니다. 이러한 내용을 바탕으로 서비스를 개선하고, 기술이 변하더라도 쉽고 빠르게 대응 가능하고 좋은 코드를 만들 수 있습니다. 이러한 고민속에는 아키텍쳐 설계가 코어로 자리잡고 있다고 생각합니다. 아키텍쳐를 설계하다보면 자연스레 계층과 관련된 레퍼런스를 접할 수 있습니다. 결국 잘 설계된 아키텍쳐를 기반으로 품질이 좋은 코드와 유지보수가 좋은 코드, 유연성 있는 소프트웨어가 나온다고 해도 과언이 아닙니다. 저 역시도 Layered architecture과 같은 내용을 많이 접했습니다. 그래서 과연 Layere..

서론 본론 결론 서론 다들 트랜잭션에 관한 고민을 해보신 적이 있으신가요? 저는 서비스 로직을 짜거나, TestCode를 작성하거나 JPA와 같은 ORM을 사용할 때 트랜잭션에 대한 고민들이 많이 있었습니다. " 어떤 단위까지 한 트랜잭션으로 간주해야 할 까?" " 외부 API를 호출하는 로직에서 만약 트랜잭션을 걸고, 해당 로직에서 문제가 발생하면??" " 만약 A 라는 서비스 로직에서 @Transactional 어노테이션을 추가하거나, 추가 하지 않거나 두 결과값이 어떻게 다를까? " " 그럼 과연 어느 서비스 로직에서는 @Transactional을 추가해야하고, 어떤 서비스 로직에서는 추가하지 않아야 할까? " 이렇게 다양한 고민들이 있었습니다. 오늘은 제가 입사하고 맡은 업무에서 경험한 트랜잭션과..

JPA에서는 영속성 전이(CASCADE)라는 개념을 지원해줍니다. 그럼 과연 영속성전이(CASCADE)란? 무엇인가요? 해석하자면 대상 엔티티에 대해 수행하는 작업들이 관련 엔티티에서도 작업이 적용된다는 것이다. JPA에서는 영속성 전이 타입 5가지를 지원해줍니다. ALL 상위엔티티에서 하위 엔티티로 모든 작업을 전파합니다. ( 모든 Cascade를 적용 ) PERSIST 하위 엔티티까지 영속성을 전달합니다. ( 엔티티를 영속화할 때, 연관된 엔티티도 함께 유지 ) MERGE 엔티티 상태를 병합할 때, 연관된 엔티티도 모두 병합 REMOVE 연결된 하위 엔티티까지 제거함 REFRESH 연결된 하위 엔티티까지 인스턴스 값 새로고침 ( 데이터베이스로부터 인스턴스 값 다시 읽어오기 ) DETACH 영속성 컨텍..

jpa에서는 애플리케이션 구동시 JPA 데이터 베이스의 전략을 설정할 수 있습니다. 총 5개의 전략을 지원해줍니다. create : 기존 테이블 삭제 후 테이블 생성 create - drop : create와 같지만, 종료 시점에 테이블을 삭제 none : 사용하지 않음 update : 기존의 테이블과 비교해서 변경된 내용이 있으면 수정 (SessionFactory와 연결된 DB를 비교해서 추가된 항복은 추가, 같은 변수명이면 오류 발생 ) validate : 엔티티와 테이블 정상 매핑 확인 ( SessionFactory 시작 시 객체 구성과 스키마가 다르면 예외가 발생) 이렇게 5가지의 전략이 있습니다. 일반적으로 초기 개발이나 테스트 할 떄는 create, update, create-drop을 주로 ..

복습 과거에 10분 테코톡을 보고 트랜잭션에 관련된 내용을 정리한 적이 있었다. 그 내용을 우선 다시 복기해보자. 일단 트랜잭션은 한 요청에 대한 작업 단위라고 생각하면 쉽다. 이 트랜잭션이 수행될 때, 중요한 부분이 내부 동작이였는데 DB 커넥션 풀을 이용해서 커넥션 객체를 가지고 오게되고, 이 객체를 이용해서 DB에 요청을 보낸다고 했다. DB 입장에서는 이 커넥션을 하나의 세션으로 생각할텐데 한 기능의 작업 단위를 묶지않으면, 결국 제 각각의 다른 커넥션으로 생각할 것이고, 이는 세션을 처리할 때, 개별 작업으로 처리해버릴 것이다. 그래서 우리가 원하는 기대 값이 나오지 아니할 가능성이 높다. 여기서 가장 중요한 점은 결국 우리가 만들고자 하는 기능을 작업 단위 즉 트랜잭션으로 묶어야 한다는 점이 ..

사건의 발단은 이랬다. 내가 조건에 맞춰 queydsl을 이용해서 원하는 데이터를 DTO로 뽑아서 조회하고싶었다. DTO로 뽑아오는 도중 많은 오류를 만났었고, 어떤 오류인지, 어떻게 해결하는지 직접 검색하고 찾아보면서 문제를 해결해 나가고 있다. 그러던 와중에 문득 데이터를 어떻게 뽑아오지? 라는 생각을 했다. 예를들어서 post 와 recommend 라는 테이블들이 각각 있으면 이들은 1:M // M:1 (양방향) 관계를 맺고 있다. 내가 원하는 것은 각각의 post에 맞춰서 recommend를 count 해오는 것이였는데, 어떻게 이를 count 해올 수 있을까? 라는 생각이 들었다. 먼저 where 조건절에 post.id.eq(recommend.post.id) 이렇게 조건을 주니 내가 원하는 데이..

본 내용은 infrearn 김영한 님의 query dsl 강의를 수강 후 정리한 글입니다. 코드 위주의 설명보다는 해당 강의를 보고 얻게된 지식이나 인사이트와 관련된 글입니다. 또한 Query dsl에 관한 저의 느낀점과 학습한 점을 정리한 것이라 Query dsl 사용 관련 내용을 담고 있지는 않습니다.. 목차 Query dsl 들어가기 내가 학습한 Query dsl ( 의존성만 등록해봅시다 ) Query dsl 마무리 Query dsl 들어가기 네? query dsl이요? 그게 뭔가요? querydsl을 알게 된 것은 작년 이맘 때쯤이였다.. 졸업작품 프로젝트를 시작하고, 어떻게 데이터를 검색할까에 관한 물음의 답이 바로 Query dsl이였다. 기술적 의사결정을 내린 후 본격적으로 query dsl..