해킹왕 양선규

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

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

비즈니스 로직에서 발생하는 모든 예외를 캐치하고 일관된 형태로 응답하기 위해서, 전역 핸들러와 커스텀 예외를 구현했다.예외 처리 로직을 비즈니스 로직으로부터 분리할 수 있고, 클라이언트는 일관된 형태의 예외를 응답받기 때문에 예외에 대한 처리를 유연하게 할 수 있게 된다.  예외 전역 핸들러(Global Exception Handler)- 애플리케이션에서 발생하는 모든 예외를 일관되게 처리하는 메커니즘- Rest api를 구현한 Spring Boot에서는 @RestControllerAdvice 어노테이션으로 이를 구현한다. 예외 전역 핸들러 - 필요성- 코드 중복 제거 : 각 서비스마다 예외 처리 로직을 반복할 필요 없음, try-catch 블록 최소화- 일관된 오류 응답 : 모든 API에서 일관된 형태..

시작 단계에서의 내가 지향하는 프로젝트의 방향성적은 기능을, 완벽하고 확실하게 구현하기다양한 상황을 고려한 예외 처리테스트 코드 작성실무에서 사용되는 코드와 최대한 비슷하게 구현하기유지보수성 생각하기재사용성확장성가독성 ( 코드 컨벤션, 주석, 변수명 등 )왜 개인 프로젝트를 시작했는가?나는 백엔드다.아직까지 개인 프로젝트를 한 번도 해 보지 않았다.한 번쯤은 프론트, 백엔드 그리고 프로젝트의 시작과 끝까지 모든 것을 혼자 해결하며 프로젝트 흐름을 이해하고 싶었다.그래서 개인 프로젝트를 하기로 결정했다.실무에서 많이 사용되는 RestAPI 방식으로 진행하고 싶었다.그래서 템플릿 엔진을 사용하는 SSR 방식이 아닌, Vue를 사용한 프론트엔드를 따로 분리하여 직접 작업하기로 했다.왜 중고차 거래 플랫폼인가?..

벌써 입소 후 55일이 지나 3일 전 목요일부터 PintOS 프로젝트가 시작되었다. 이젠 정글의 일상에 적응할 대로 적응해서 크게 힘들거나 하는 건 없다. 아니 물론 힘들긴 하다. 하지만 못 버틸 정도는 아닌 수준이다. 지난 주 webproxy 주차는 나름 나쁘지 않은 성과였지만, 시간이 너무 부족해 web server만 만들고 메인 과제인 proxy서버를 구현하지 못 해서 아쉬움이 남았다. 구현하지 못 한 게 아니라 접근조차 못 했다. proxy 전 과제인 tiny web server 를 끝낸 후 복습하면서 블로그에 정리 글을 올렸더니 이미 수요일이 끝나 있었다. 이틀.. 아니 딱 하루만 더 있었더라도 proxy서버까지 끝낼 수 있었을 텐데. 아쉬움이 남는다. 그나마 위안이 되는 것은 다른 사람들도 나..

회원 서비스 개발에 이어, 개발한 회원 서비스를 테스트할 차례다. 테스트를 수행할 MemberService에서, Ctrl + Shift + T를 누르고, Create New Test를 누른다. 그러면 이런 창이 뜬다. 테스트 클래스 이름도 본래 클래스 이름에 Test만 붙여서 자동으로 작성해 준다. 내가 테스트하고 싶은 메소드를 아래에서 체크해서 OK를 누른다. 그러면 이렇게 테스트에 필요한 틀을, 적절한 위치(경로)에 아주 쉽게 만들어준다. 일단 만들어진 테스트가 문제가 없는지, 현재 상태에서 바로 한번 돌려본다. 다행히 문제는 없다. 본격적으로 테스트 케이스를 작성해 보기 전에, 잠깐 MemberService로 가보자. 기존 코드를 변경해서, 이렇게 생성자를 통해 외부에서 리포지토리를 주입받도록 변경..

도메인, 리포지토리를 만들었으니 서비스를 만들 차례이다. hello.hellospring.service 패키지를 만들고, service 패키지 아래에 MemberService 클래스를 만들자. 서비스는 리포지토리와 함께 동작해야 하니, 미리 만들어두었던 리포지토리 객체를 만들어 주자. 회원가입 메소드인 join이다. member 객체를 매개변수로 받아서 리포지토리에 저장하고, 저장한 객체의 Id를 리턴한다. 단, 중복된 name을 가진 회원은 가입할 수 없도록 검증하는 과정이 있다. 바로 밑에 선언해둔 validateDuplicateMember가 중복을 검사하는 메소드이다. name을 기준으로 리포지토리에서 회원을 찾아서, 해당 회원이 이미 존재한다면 "이미 존재하는 회원입니다" 예외를 출력하고 메소드는..

개발한 코드가 잘 동작하는지 확인하기 위해서는, 테스트 케이스를 작성하여 확인해야 한다. 자바는 JUnit 이라는 프레임워크를 제공하여, 테스트를 효율적으로 실시할 수 있게 해준다. 우선 테스트 케이스를 작성할 패키지를 만들어 주자. 주의해야 할 점은, 앞서 코드를 작성했던 "Main" 디렉터리 밑이 아닌 그 아래에 있는 "test" 디렉터리 아래에 만들어야 한다는 점이다. test 디렉터리 밑에서, hello.hellospring.repository 패키지를 만들어 주자. repository 패키지 아래에 MemoryMemberRepositoryTest 클래스를 만들어 주자. 우리는 MemoryMemberRepository를 테스트할 것이기 때문에, 뒤에 Test만 붙여서 생성하는 것이다. 테스트 클래..

우선, 도메인을 구현할 패키지인 hello.hellospring.domain 패키지를 만들자. domain 패키지 하위에, Member 클래스를 만들자. 그리고 위와 같이 도메인 역할을 할 Member 클래스를 작성해 주자. 비즈니스 요구사항에서, 데이터는 회원ID, 이름 2가지였다. 그 역할을 해줄 id, name 필드를 선언하고 getter setter를 작성한 것이다. 다음은 repository 패키지를 만들어 주자. repository 패키지 하위에, MemberRepository "인터페이스"를 만들자. 위와 같이 인터페이스를 작성해주자. 여기서 구현을 할 수는 없고, 추상 메소드 4개를 선언했다. 이것은 MemoryMemberRepository라는 구현 클래스에서 구현할 것이다. reposit..

본격적으로 개발을 하기 앞서, 우선 비즈니스 요구사항을 정리해야 한다. 복잡한 비즈니스 로직을 배우는 것이 아닌, 스프링이 어떻게 돌아가는지를 이해하기 위함이므로 가장 쉬운 비즈니스 요구사항을 택할 것이다. 일반적인 웹 애플리케이션 계층 구조는 이렇다. 컨트롤러: 웹 MVC의 컨트롤러 역할 서비스: 핵심 비즈니스 로직 구현. 도메인을 이용한 서비스, 기능, 로직 그 자체를 의미 리포지토리(저장소): 데이터베이스에 접근하고 도메인 객체를 DB에 저장하고 관리함. 도메인: 비즈니스 도메인 객체. 회원, 주문, 쿠폰 등등. DB에 저장되고 서비스로써 이용될 것들. 비즈니스 요구사항 데이터: 회원ID, 이름 기능: 회원 등록, 조회 아직 데이터 저장소가 선정되지 않은 상태라는 가정 ( 어떤 DB를 사용할지 정해..