과정을 즐기자

이번 글에서는 시간, 랜덤 값과 같은 제어할 수 없는 영역을 테스트하는 방법에 대해 작성해보겠습니다.예시로 날짜에 따라 할인을 적용하는 간단한 로직을 만들어보았습니다. Bad - 의존성이 내부에 숨겨져 있음 위 코드는 2024년 6월 30일 이전 날짜인 경우에만 2000원의 할인이 적용됩니다.잘 작성한 것 같아보이지만 문제점이 보이시나요? Bad - 테스트하기 어려움 할인 날짜보다 이전/이후 날짜에 따라 할인 적용 여부가 결정되는데 시간의 흐름에 따라 테스트 코드가 달라질 수 있습니다.제어할 수 없는 영역인 시간에 대한 정보가 메소드 내부에 숨겨져 있기 때문입니다.즉, 해당 코드는 테스트 코드를 작성하기가 어렵습니다. 📕 제어할 수 없는 영역은 밖으로 밀어내자이제 이 메소드를 리팩토링하여 테스트할 수 ..

이번 글에서는 프로젝트를 진행하면서 복잡한 비즈니스 로직을 풀어냈던 방법에 대해 작성해보려고 합니다.⛳️ 요구 사항먼저 요구사항에 대해 정리해보겠습니다. 1. 각각의 회원이 각자의 캘린더를 가지고 있음2. 회원은 여러 모임에 참여할 수 있음3. 모임장은 참여한 회원들의 캘린더 정보를 바탕으로 팀원들의 가용시간을 확인할 수 있음4. 이 가용시간을 바탕으로 특정 시간에 미팅을 생성할 수 있음 위와 같은 요구 사항이 있습니다. 이번 글에서는 3번에 대한 요구 사항을 중점적으로 이야기를 해볼텐데 대략 아래와 같은 UI를제공합니다. 각 회원의 캘린더 정보를 가져와서 하나의 캘린더에 색상으로 표현을 합니다.색상이 진할 수록 가능한 사람이 많은 시간대를 의미하며 해당 캘린더를 클릭하면 가능한 회원의 정보를 볼 수 있..

이번 글에서는 프로젝트를 진행하면서 저희 팀이 어떻게 테스트 코드를 작성하고 있는 지에 대해 이야기 해보려고 합니다.저희 팀은 현재 백엔드 개발자가 3명입니다. 테스트 코드를 작성하는 규칙을 정할 때 많은 이야기가 오고 갔습니다.주로 이야기 했던 것은 테스트 코드가 중요하다고 관성적으로 작성하지 말고 "왜" 필요한지를 꼭 인지하며테스트 코드 작성이 서비스 개발에 큰 도움이 되는 것을 느껴보자는 것이었습니다. 테스트 코드가 중요하다는 사실은 수도 없이 들었지만 이전에 해왔던 방식에서 크게 2가지 문제점을 느꼈습니다. 1. 관성적으로 의미 없는 테스트 코드를 작성하지는 않았는가?2. 실질적인 이득을 본 것이 무엇인가? 이러한 문제를 인식하고 안정적이고 견고한 서비스를 개발하기 위해 테스트 코드를 작성하는 규..

프로젝트를 진행하면서 사용자가 시간표를 등록하면 해당 시간표 정보를 서비스의 캘린더에 반영하는 기능을 구현하였습니다. 이때 1명의 사용자만 한 학기의 시간표를 등록해도 한 번에 200, 300개의 insert 쿼리가 날라갔습니다. 만약 1000명의 사용자가 동시에 등록을 하게되면 20, 30만건의 insert 쿼리가 한 번에 날라가게 된 것입니다. Spring Data Jpa의 save 메소드 기존에 Spring Data JPA를 사용하여 단순히 save 메소드를 호출하였는데 서비스가 점점 커질수록 이러한 방식은 문제점을 가지고 있던 것입니다. 먼저 기존의 코드를 살펴보겠습니다. 저장할 스케줄을 List로 받아서 하나 하나 save 메소드를 호출해주었습니다. @Transactional public voi..

대학교 내 단체 모임 생성/참여 서비스 프로젝트를 진행하면서 영속적인 데이터를 RDB에 저장하기 위해 테이블 설계를 해보았습니다.  회원 정보, 학과 정보, 학교 정보, 클랜 정보(동아리 같은 그룹), 어셈블 정보(모임) 등의 테이블이 존재합니다.이때 유연한 설계가 필요한 요구 사항을 마주하게 되었는데 이번 글에서는 RDB로 어떻게 풀었는 지에 대한 글을 작성해보려고 합니다.📚 어려웠던 주요 요구 사항테이블 설계하면서 설계하기 어려웠던 요구 사항은 크게 2가지가 있었습니다. 1. 커스텀 필터 기능2. 어셈블 (모임 정보) 통합 관리 기능 이제부터 하나씩 살펴 보겠습니다.📘 커스텀 필터 기능문제 상황저희 서비스에서는 관리자가 어셈블(모임 정보)을 쉽게 관리할 수 있도록 하기 위해 참여한 회원을 학번, ..

프로젝트를 진행하면서 서비스를 배포하는 방법에는 여러 가지가 있습니다.먼저 단순한 방법으로는 내 로컬 PC에서 프로젝트를 빌드하여 scp 명령어로 운영 서버로 파일을 전송하고 서버에 들어가서 해당 파일을 실행 시키는 방법이 있습니다. 하지만 매번 이러한 과정을 수행하는 것은 굉장히 번거로운 작업입니다. 이를 개선하기 위해서 운영 서버에서 github에 있는 코드를 가져와서 프로젝트를 빌드하고 프로젝트를 실행하도록 하는 쉘 스크립트를 작성할 수도 있습니다. 하지만 이러한 경우도 여전히 단점이 존재합니다. 우선 개발자가 운영 서버에 직접 접속하여 쉘 스크립트를 실행해야 합니다.또한 운영 서버에서 프로젝트를 빌드하기 때문에 운영 서버의 리소스를 낭비할 수 있다는 단점도 있습니다.이러한 단점들은 개발자가 많아질..

각종 블로그 글, 유튜브, 페이스북, 오픈 카톡방, 인프런 글 등을 보다 보면 테스트 코드 작성시 @Transactional의 사용 여부는 끊임없이 논쟁되는 주제 같습니다. 여러 글들을 많이 보았는데 향로님의 블로그에서 이러한 의견들을 잘 정리해놓은 글을 보았습니다. 테스트 데이터 초기화에 @Transactional 사용하는 것에 대한 생각얼마 전에 2개의 핫한 컨텐츠가 공유되었다. 존경하는 재민님의 유튜브 - 테스트에서 @Transactional 을 사용해야 할까? 존경하는 토비님의 페이스북 2개의 컨텐츠에서 테스트 데이터 초기화에 @Transajojoldu.tistory.com정말 책, 강의, 유튜브 등에서만 보았던 존경하는 분들의 의견이 정리되어 있었습니다.테스트 코드에서 @Transactional..

그동안 도메인과 엔티티를 분리하는 것에 대한 장점이 크게 납득이 되지 않았습니다.하지만 개인 프로젝트에서 여러 가지 테스트를 하며 고민해보고 인턴을 하며 회사 코드에 적용을 해보았는데이것이 꽤 유의미한 작업이 될 것이라고 생각했습니다. 저는 DDD도 모르고 헥사고날 아키텍쳐도 모릅니다.그냥 요구사항에 대한 구현을 더 잘하기 위해 도메인과 DB 엔티티를 분리하는 작업을 해보겠습니다.엔티티와 Dto를 분리 먼저 엔티티와 Dto 분리에 대해 이야기 해보겠습니다. 그동안 엔티티와 Dto를 분리하는 작업은 많이 해왔습니다. 요청과 응답에서 엔티티를 직접 사용하면 안되는 이유이번 글에서는 요청과 응답에서 엔티티를 직접 사용하면 안되는 이유에 대해서 작성해보려고 합니다. 일단.. 너무 기계적으로 dto를 사용했기 때..

가장 기본적인 자료 구조 중 하나로 배열이 있습니다. 배열은 미리 일정 크기만큼 메모리를 할당한 후 데이터를 순차적으로 저장하는 자료구조입니다. Java 에서의 배열 Java에서는 다음과 같이 배열을 생성하고 사용할 수 있습니다. int[] array1 = new int[5]; 32 비트 정수형 데이터 타입인 int를 총 5개를 미리 메모리에 할당합니다. 물론 선언을 할 때 원소를 미리 저장할 수도 있습니다. int[] array2 = new int[]{1,2,3,4,5}; 그렇다면 이러한 배열과 내부 원소들은 메모리의 어디 부분에 할당되는 것일까요? 배열도 객체다 Java에서는 배열도 객체라고 할 수 있습니다. 배열을 생성할 때는 다른 객체 생성과 마찬가지로 new 키워드를 이용해서 배열을 생성합니다...

Spring을 사용하여 개발을 하다보면 공통 로직에 대한 처리에 대해 개발자가 구현하기 쉽도록 해놓은 것을 알 수 있습니다. 예를들면 AOP, Filter, Interceptor, ArgumentResolver 등이 있습니다. 이번 글에서는 로그인 인증과 관련된 부분에 대해 위와 같은 기술 중에서 어떤 것이 적합한 지 생각해보며 어떻게 처리를 할 지에 대해 작성해보겠습니다. AOP AOP는 Aspect Oriented Programming의 약자로 횡단에 걸쳐 계속 반복하여 사용하는 코드의 중복을 줄일 수 있는 좋은 방법입니다. 로그인 인증과 관련된 부분도 AOP로 충분히 처리가 가능합니다. 하지만 AOP는 굉장히 범용적입니다. 컨트롤러는 파라미터나 리턴 값이 일정하지 않고 HttpServletReque..