밤낮개발

Introduction 프로젝트를 하던 중, DB 에서 테이블을 조회하는 코드가 중복이 많다는 것을 알게 되었다. 이후 중복을 없애기 위해 디자인 패턴을 적용하자고 마음을 먹고 전략 패턴을 적용해보았다. 패턴 적용 전 코드 public SearchPageGetResponse findTracksWithKeyword(Pageable pageable, String searchKey, String memberEmail) { Member member = validateMember(memberEmail); Page tracks = trackRepository .findAllByTrackTitleContainingOrAlbumAlbumTitleContainingOrArtistArtistNameContaining(ke..

기본 클래스를 찾거나 로드할 수 없다는 에러가 자꾸 발생해, 에러를 해결하고자 구글링을 계속 해야 했다. 에러 상황 해결 우선 스택 오버플로우에 Settings-> Build, Execution, Deployment-> Build Tools-> Gradle 에서 설정을 바꾸라는 식의 조언이 있어서 참고했지만 에러는 여전했다. 하지만 도무지 원인을 알 수 없었다. 분명 main 클래스를 건드리긴 했지만, 이름을 변경한 것이 아닌데 왜 인식을 하지 못하고 있을까? 그러던 중 걸리는 것이 딱 하나 있었는데, 프로젝트가 위치한 폴더 명이 한글로 되어있다는 점이었다. 이전에도 한글로 한 적이 있었던 것 같았지만 지푸라기라도 잡는 심정으로 폴더명을 영어로 변경해보았고 바로 해결되었다 🤣 결론 프로젝트 폴더명은 영어..

Introduction Spotify Web API 를 사용하던 도중, Album 과 Track 은 불러오는데에 성공하면서도 Artist 를 불러오지 못하는 문제가 발생하였다. 💥 문제 발생 아무리 코드를 둘러봐도 문제점을 발견하지 못했고, 빈 값으로 가져오는 이유가 명확하게 찾아지지 않았다. 혹시나 tracks/{offset}/artists/name 의 경로 설정이 다를 수도 있겠다고 판단이 되어서 로직 수정이 아닌 오타를 찾는 데에 집중했다. 하지만 찾을 수 없었다. 온갖 수정을 하던 차에 Json 데이터 값에서 key artist 의 value 를 추출하여 JsonNode 객체에 할당할 때 문제가 있을 수도 있으니 추출하는 코드를 변경하고 있었다. 그리고 기존 at 메서드 사용에서 get 메서드를 ..

GitLab 에서의 CI/CD 전형적인 배포의 단계들 1. 프로젝트가 빌드 준비를 마치면 Dockerfile 을 작성한다. 2. 파이프라인에서 사용하는 환경변수들을 설정한다. 3. 1번에서 작성한 Dockerfile 로 docker build 와 docker push 를 하는 YAML 파일로 파이프라인을 작성한다. 4. YAML 파일을 업데이트하면 파이프라인이 자동으로 실행되는 것을 목록에서 볼 수 있다. 5. 작성한 파이프라인이 성공적으로 실행되면 Container Registry 에 Docker 이미지가 생성되어 있음을 볼 수 있다. 📃 Note 여기까지가 Continuous Delivery 에 포함된다. Continuous Delivery, 지속적 제공이란 배포 직전 단계까지의 과정을 자동화하여 구..

🔍 Soft Delete 데이터베이스에서 row 를 실제로 삭제하지는 않아야 하는 상황에서 사용한다. 실질적으로 DB 에는 남겨두고, 프론트에서 접근하지 못하도록 숨기는 방식으로 pseudo-delete 를 구현하는 것을 soft delete 의 정의라고 할 수 있다. 현재 프로젝트에서는 포스트가 삭제되었는데 댓글과 좋아요가 삭제된 포스트 아이디에 대한 댓글과 좋아요로 남아 있으면 논리적으로 오류이므로 soft delete 방식을 사용한다. 댓글 엔티티와 좋아요 엔티티 모두에 deleted\_at 컬럼을 추가해서 삭제될 때 현재 시간이 기록되도록 쿼리를 튜닝해준다. 좋아요를 눌렀고, 댓글을 달았다는 기록은 남긴 채 대상 포스트가 사라졌다는 사실을 알고는 있도록 할 때 soft delete 를 사용한다고 ..

🔍 리팩토링 전의 코드 프로젝트 중 테스트를 작성하면서, 기계적이고 반복적으로 하나의 패턴을 여러 상황별 테스트 메서드에 공통으로 사용하고 있음을 발견했다. 아래 두 코드 블럭들과 같이 모든 코드가 동일하고 ErrorCode 의 종류와 HTTP 상태를 나타내는 status() 만 차이가 있는 메서드들이 있었다. 기능 구현 메서드들을 작성할 때에는 템플릿 콜백 패턴과 같이 인터페이스를 활용해 중복을 제거하고 관심사를 분리할 수 있었는데, 테스트 코드에서는 한 번도 매개 변수를 가진 메서드를 정의해본 적이 없다는 단순한 이유로 하나의 메서드에서 작성한 코드를 ctrl+c, ctrl+v (복사 후 붙여넣기) 하여 다른 메서드에서 쓰는 비효율적인 프로그래밍을 했다. 리팩토링을 거쳐서 어떻게 중복을 줄이고 공통된..

📃 Introduction 프로젝트에서 스프링 시큐리티를 적용해 기본적으로 모든 API 경로는 인증 절차를 거치게 하고, 회원가입과 로그인을 포함한 몇몇 API 는 인증이 없이 호출이 가능하도록 변경해야 했다. 모든 API 가 인증 절차를 거치게 하는 것은 어렵지 않았으나, 몇 개의 API 가 인증이 없이도 호출되도록 변경하는 것이 까다로웠다. 🚩 현재 상황 아래는 현재 보안 필터 체인의 구성이다. 각각 회원가입과 로그인을 나타내는 POST /api/v1/user/join 과 POST /api/v1/users/login 을 antMatchers 의 permitAll() 메서드를 활용해서 인증 절차가 필요하지 않게 설정해주었다. 문제는 GET api/v1/posts/** 또한 인증 없이 호출되게 설정했다는..

🔍 현 상황 프로젝트 진행 과정 프로젝트를 하면서 스프린트를 두 개로 나누었다. 각 스프린트를 브랜치로 만들었다. 첫 스프린트 단위는 브랜치 이름으로 sprint1 을 사용했다. sprint1 을 source 브랜치로 각 기능 구현을 할 때마다 1개 브랜치씩 만들었고, 기능 구현을 마칠 때마다 sprint1 으로만 병합을 하고 main 은 놔두었다. sprint1 의 모든 작업을 마친 후 main 브랜치에 병합을 할 생각이었다. 문제 발생 스프린트가 끝나기 전까지 모든 기능 단위에 대한 브랜치는 sprint1 에만 병합, 즉 merge 가 되어야 했다. 근데 무슨 생각이었는지, 실수로 Target branch 를 바꾸어주지 않고 main 에 기능 한 개를 merge 하고 말았다. 이후 main 에 스프린..