해킹왕 양선규

[썬카/백엔드] 서비스 계층 및 커스텀 리파지터리 테스트 코드 작성, 팩토리/빌더 클래스 설계와 영속성 컨텍스트, Hibernate 통계 관리(Statistics)

썬카의 기능이 조금씩 많아지니, 코드를 수정할 때마다 매번 Postman으로 api를 호출해보는 나를 발견할 수 있었다. 이 작업이 번거롭다고 느껴지는 순간, 테스트 코드를 도입할 때가 왔다고 느꼈다. 그래서 잠시 스프린트는 접어두고 테스트 코드를 도입한 후 작업에 들어가기로 했다. 처음 작성해 보는 테스트 코드였지만, 나는 말 그대로 테스트만 하는 코드인데 오래 걸리겠어? 라고 생각했다. 그러나 이렇게나 생각할 게 많고 복잡할 줄 몰랐다. 테스트의 종류도 여러 가지였고 각각 어떤 테스트인지, 어떤 상황에서 도입해야 하는지, 우선순위는 어떻게 되는지 전부 생각해야 했다. 테스트 코드 자체도 전부 처음 보는 방식, 메서드들이라 기존의 난 완전 백지 상태나 다름이 없었어서 완전히 하나하나 차근히 공부하면서 ..

스프링 부트 테스트 전략 - 단위 테스트와 통합 테스트

테스트 코드는 매우 중요하며, 개발자에게 있어 필수적인 핵심 역량이다. 서비스 규모가 작을 때야 코드를 수정한 후 api 몇 개 직접 호출하면 금방 테스트할 수 있겠지만, 규모가 커져서 api가 수백 수천 개, 메서드가 수천 수만 개 된다면 반드시 테스트 코드가 필요할 것이다. 미리 잘 짜놓은 테스트 코드는, 배포하기 전 매번 테스트를 직접 수행하는 번거로움을 줄여주며 정확히 어디에서 오류가 발생했는지 쉽게 디버깅할 수 있게 해 준다. 개발이라는 분야에 있어서 기능의 구현 만큼이나 코드의 유지보수성과 확장성이 중요하다는 것을 생각한다면, 테스트 코드는 비즈니스 로직 만큼이나 중요하다고 해도 과언은 아닐 것이다. 스프링 부트 테스트 전략은 크게 [단위 테스트, 통합 테스트, E2E/기능 테스트] 로 나뉜다..

스프린트 3이 종료되었다. 스프린트 2 회고에서 차량 등록, 조회를 어떻게 구현할지 걱정했지만 훌륭히 구현해 냈다.이번에 구현한 기능은 아래와 같다.차량 등록판매 차량 상세 조회 차량 정보를 다루는 엔티티가 무려 10개였기 때문에, 백엔드 코드 작성이 매우 매우 어려웠다. 애플리케이션 레벨에서 관계는 어떻게 정의하며, repository와 service는 어떤 구조로 작성하고 관리하는지, 쿼리는 어떻게 최적화 하는지 등등… 고민해보지 못했던 문제들을 많이 만났다. 스프린트 2의 유저 관련 로직을 짤 때보다 10배는 더 어려웠던 것 같다. 이번 스프린트 3을 진행하며 가장 크게 배운 것은 객체지향적 설계와 SOLID원칙, 그리고 쿼리 최적화이다. 백엔드에서 어려웠던 점 - 객체지향적 설계와 N+1, 카테시..

차량 상세조회 기능을 구현하며 차량 관련 엔티티 10개를 조회해야 했는데, 이 과정에서 Lazy Loading, fetchJoin, BatchSize를 공부하고 적용해 보았다. 백엔드에서 쿼리 짜는 게 제일 어려운 것 같다. 아래는 Lazy Loading, fetchJoin(), BatchSize에 대해 내가 정리한 글이다.https://yskisking.tistory.com/316 JPA 쿼리 최적화 - Lazy loading, fetchJoin(), BatchSize개인 프로젝트 썬카에서 차량 상세 조회 기능을 만들다가 쿼리 최적화 문제에 부딪혔다.무려 10개의 엔티티를 전부 조회해야 했고 성능 부분을 신경쓰지 않을 수 없었기에, 자연스럽게 Lazy loadingyskisking.tistory.com..

개인 프로젝트 썬카에서 차량 상세 조회 기능을 만들다가 쿼리 최적화 문제에 부딪혔다.무려 10개의 엔티티를 전부 조회해야 했고 성능 부분을 신경쓰지 않을 수 없었기에, 자연스럽게 Lazy loading, fetchJoin, BatchSize에 대해서 조금 공부하게 되었다.  Lazy Loading- JPA/Hibernate 에서 사용하는 데이터 로딩 전략- 연관 엔티티의 데이터를 실제로 필요한 시점까지 DB에서 조회하지 않고 지연시키는 방식 Lazy Loading - 작동 원리- 엔티티 조회 시 영속성 컨텍스트에 주 엔티티 데이터 로드- 연관 엔티티는 실제 데이터 대신 프록시 객체(참조)로 대체됨- 연관 엔티티(프록시)에 getter로 접근하는 시점에 추가 DB 쿼리가 발생함 // Lazy loading..

차량 판매등록 기능은 카히스토리 api를 사용해 받아온 데이터를 등록해야 하지만, api를 아직 도입하지 못해서(너무 비싸..) 임시로 더미 데이터를 입력하는 방식으로 구현했다. 해당 기능은 인터페이스를 통해 구현된 facade 서비스 클래스에 존재하는데, 기존엔 배포용 차량 판매등록 기능과 더미 데이터 판매등록 기능이 하나의 인터페이스에 공존하고 있었고, 그것을 두개의 구현체로 구현했었다. 배포 때는 배포 판매등록 기능, 개발 때는 더미 판매등록 기능이 이용 되어야 하며, 두 기능은 하나의 환경에서 동시에 사용되지 않아야 한다. 따라서 하나의 인터페이스에서 파생된 두 구현체는, 사용되지 않는 메서드까지 상속받아 무의미하게 구현하고 있는 상태였다( ISP 위반 ). 또한 두 구현체는 같은 부모 인터페이스..

차량 판매등록 기능을 구현하며 객체지향적 설계를 한 것에 대해 정리해 보고자 한다. 차량 등록에 필요한 엔티티는 10개이며, 판매되는 자동차 1대가 10개 엔티티의 데이터를 전부 필요로 한다. 현재 차량 정보를 조회하는 카히스토리 api는 도입하지 않았기 때문에(너무 비싸..) 도입했다는 가정 하에 api 리턴값과 동일한 형태의 테이블을 설계했고, 그에 맞는 더미 데이터 생성 로직을 작성했다. 그 더미 데이터를 이용해 차량 등록 기능을 구현해 보았다. 다만 엔티티가 너무 많았기 때문에 코드가 길어졌고, 하나의 서비스 클래스에 이 모든 로직을 (엔티티 저장, dto변환, 더미데이터 생성 등) 담는 건 매우 좋지 않은 설계라고 생각되었다. 따라서 각 엔티티별 서비스 클래스에 create 메서드를 각각 만들고..

차량 판매등록 기능을 구현하는데, 차량 관련 엔티티 10개에 대한 반복적인 작업을 해야 했다.각 엔티티 만들고, 서비스 인터페이스 + 구현체 만들고, DTO 만들고... 전부 하나하나 일일이 해야 했다. 최대한 효율적으로 작업할 수 있는 방법은 없을까 많이 고민했지만, 엔티티 자체가 많은 거라 어쩔 수 없이 반복작업이 필요한 부분이었다. 그래도 유지보수성을 조금이라도 올리기 위해, facade 서비스 클래스를 따로 만들어서 여러 엔티티를 거치는 비즈니스 로직은 여기서 처리하고, 나머지 각 엔티티 별 서비스에서는 최대한 단일 책임 원칙(SRP)을 지켜 해당 엔티티에만 영향을 주는 로직을 작성하기로 했다. 그러나 정말 무의미하다고 느껴졌던 부분이, DTO 엔티티를 변환하기 위한 팩토리 메서드를 작성할 때였..

객체 지향 프로그래밍(OOP)에서 지향해야 할 5가지 설계 원칙을 SOLID라고 칭한다. 개인 프로젝트를 시작하면서, 완벽하고 빈틈없는 코드를 짜겠다 라는 목표를 세웠다. 그러나 생각만 하는 것 보다는, 5원칙을 참고하여 좀더 명확한 목표를 잡고 프로그래밍 하는 것이 낫겠다고 느꼈다. 지금까진 SOLID 원칙이 중요하다고 지나가듯이 들었던 말들 뿐이었는데, 이번에 제대로 공부해보며 어째서 중요한 것인지 이해할 수 있었다.  5원칙 중에는 나도 모르게 이미 적용하고 있던 것들도 있었고, 하긴 하는데 왜 하는지는 모르는 것도 있었고, 아예 모르는 것도 있었다. 실무 가서 일하다 보면 혼나고 깨지면서 자동으로 이 5원칙에 따라 코드를 짜게 된다던데, 지금부터 미리 5원칙을 이해하고 코드를 설계할 수 있다면 큰..

스프린트 2가 종료되었다. 6일이 걸렸으니 스프린트 1에 비해 3배는 빨리 끝났다.당연한 거겠지만 환경설정과 학습 시간이 빠지고, 기능 구현에만 집중하니 작업이 훨씬 빨랐던 것 같다.스프린트 2에서 구현한 기능은 아래와 같다.마이페이지 조회마이페이지 내 정보 수정판매중인 차량 목록 조회 프론트와 백엔드를 함께 진행하며 느낀건데, 확실히 백엔드가 좀 더 논리적으로 생각할 게 많은 것 같다. 물론 내가 백에 좀 더 신경을 쓰고 있는 것도 사실이지만, 백 로직을 생각하는 것이 3배는 머리아픈 것 같다. 백은 깊고, 프론트는 넓은 것 같다고 느꼈다. 개인적인 생각이다. 프론트엔드에서 어려웠던 점 - 다양하고 자잘한 이슈들마이페이지 조회와 내 정보 수정 기능은 백에서는 아주 수월했다. 쉽게 구현할 수 있었다. 하..