[우아한테크코스 5기] 웹 자동차 경주 2단계 학습 로그

웹 자동차 경주 1단계

GitHub 저장소

STEP 2 목표

변경 사항

개선할 점

배운 점

궁금한 점

나가며

📆 기간 : 2023.04.14 ~ 2023.04.24

들어가며

이번 2 단계에서는 이력조회 api, 웹 애플리케이션과 콘솔 간 코드 중복 제거를 진행하였다. 코드의 이식성을 생각하며 작성을 하다 보니 범용적인 코드 작성 법을 알게 되었던 것 같다. 콘솔로 만들었던 코드가 리팩토링을 통해 웹과 같은 비즈니스 로직을 통해 진행할 수 있었는데 재미있었다.

GitHub 저장소

웹 자동차 경주 2차 PR 깃허브 주소

STEP 2 목표

추가된 요구사항
이력 조회 api 추가
콘솔 출력 방식 수정
중복 코드 제거

api 추가 및 리팩토링을 통해 콘솔과 웹이 하나의 비즈니스 로직으로 작동하도록 한다.

변경 사항

반란군이 되기 위해 Winner를 없애보자

처음에는 game 테이블에 Winner라는 것을 가지고 있었다.

이렇게 해야 Winner를 구별할 수 있으니까. 하지만 나는 결국 없앴다. 그 이유는 다음과 같다.

1. Game 테이블에 Winner 존재

2. Winner 테이블 존재

3. Car 테이블에 Winner 체크하는 column 존재

1번과 2번은 Winner가 오션이라면 Car테이블에도 오션이라는 row가 존재하며 중복이 있다고 생각하였다. 나는 최대한 중복을 없애는 것이 좋다고 생각했기에 1번과 2번을 포기했다.

3번은 여러개의 Car들 중에 단 몇개의 winner를 위해 column을 만드는게 마음에 안들었다. 너무 비효율적이라고 생각했다.

그래서 결국 Winner를 없앴다. 승자를 계산하는 로직은 이미 있었기에 Winner를 저장하지 않고 로직으로 계산하여 출력하도록 하였다. 반란군이 되보고 싶었다.

이력조회 api

Get을 통해 이력을 조회할 수 있도록 하였다.

Response는 다음과 같다.

HTTP/1.1 200 
Content-Type: application/json

[
    {
        "winners": "오션",
        "racingCars": [
            {
                "name": "오션",
                "position": 6
            },
            {
                "name": "민트",
                "position": 4
            },
        ]
    },
    {
        "winners": "오션,민트",
        "racingCars": [
            {
                "name": "오션",
                "position": 6
            },
            {
                "name": "민트",
                "position": 6
            },
        ]
    }
]

콘솔 출력 방식 수정 현재 콘솔에서는 웹과 다르게 중간 과정을 출력한다. 이러한 로직을 제거하였다.

콘솔 중복 코드 제거

콘솔에서의 비즈니스 로직과 웹에서의 비즈니스 로직이 겹쳤다. 이러한 로직을 제거함으로써 하나의 비즈니스 로직으로 웹, 콘솔 모두 사용가능한 이식성 있는 코드를 작성하는 것이 목표라고 생각했다.

비즈니스 로직

비즈니스 로직은 RacingGame을 만들어서 서비스에서 이를 호출하여 사용할 수 있도록 하였다.

OutputView

웹처럼 ResponDto를 넘겨주어 이를 View로써 활용하였다. 처음에는 콘솔에서 Dto를 생각하지 못했는데 이를 수정하고 나니 중복 코드를 더 제거할 수 있었다.

콘솔 dao 추가

하나의 서비스를 사용하려고 하였다. 그렇다보니 웹 서비스에서는 jdbcTemplate을 사용하여 game, car dao인터페이스를 만들었는데 이를 콘솔에서 사용하기는 어려웠다. 그래서 여기에 콘솔에서 사용하기 위한 ConsoleGameDao, ConsoleCarDao 구현체를 만들어서 사용하였다. 객체지향의 다형성을 활용하였다.

테스트 코드 추가

테스트 코드에 대해서 어떻게 작성해야 할지에 대한 고민이 계속 있었다. 스프링부트에서 테스트를 어떻게 작성해야 하는지도 잘 몰랐고, mock이라는 것도 알기만 할 뿐 사용해보진 않았다. 하지만 언젠가는 써야하기에 이번에 사용하면서 연습해보았다.

api 테스트

api 테스트는 스프링부트 웹 환경에서 실제로 작동시키면서 테스트 가능하도록 하였다. RestAssured를 사용하였다. 반환값에 대한 값을 테스트 하기보다는 Body의 크기, 상태 코드 등을 테스트 하였다.

dao 테스트

실제로 Dao에 있는 로직을 사용하였다. 그렇다 보니 실제 h2에도 데이터가 저장되는데 이를 @Transactional로 해결하였다.

service 테스트

@ExtendWith(MockitoExtension.class) 를 추가하여 mock 테스트를 진행하였다. 모킹과 스터빙을 통해 해결하였다. 아직은 이렇게 작성하는 것이 옳은지는 모르겠으나 지금은 사용을 해봤다는 것에 의의를 두려고한다.

개선할 점

레벨 1에서 학습했던 것을 잊지 않기

레벨 2라고 해서 레벨 1에서 학습한 것을 잊지 말자

배운 점

Bean 이란 ?

Layered Architecutre

controller-advice

annotated controllers

Repository와 Dao의 차이

DTO와 Domain간 변환

궁금한 점

Dao에서 반환 타입

Dao에서 반환하는 것은 DTO인가 ? 라는 궁금증이 생겼다. 주변을 보니 entity라는 것을 사용하기도 하고 궁금했다. 나는 만약 Join을 한다면 Dao에서 Join한 값에 매핑되는 무언가(Entity같은)가 있어야 할 것 같은데 이것이 결국 Entity와 같은 역할을 하는 DTO일 것이라고 생각을 하였다. 그래서 Entity는 Dto인데 영속성 계층에서 서비스 계층으로 전송되는 Dto를 Entity라고 생각하게 되었었다.

파즈는 이것을 Dto라고도 보고 Vo라고도 본다. 사실 단어가 중요한 것은 아니라는 생각을 한다.

Join 시 쿼리 관리

이번에 JOIN을 하지는 않았지만 join을 할 경우에 어떤 Dao에서 처리되어야 하는지에 대해 잘 모르겠다고 질문을 해보았다.

해당 join을 하여 얻는 정보가 어느쪽 도메인의 정보에 초점이 맞춰져있는지를 보고 결정할 것 같습니다. 매우 큰 테이블끼리 조인을 한다면 쿼리 성능을 위해 규모가 작은 테이블을 메인 테이블로 둘 것 같다고 하였다.

나가며

기능적인 면은 많지는 않았지만 스프링에 대해 공부할 것이 무척 많았던 미션이였다. 재미있었지만 어려웠다. 하지만 스프링 미션 처음이기에 어려울 수 밖에 없다고 생각한다. 어렵다고 그냥 지나갈 것이 아니라 최대한 학습을 하면서 지나가려고 노력했던 것 같다.

'우아한테크코스' 카테고리의 다른 글

[우아한테크코스 5기] 장바구니 2단계 학습 로그 (1)	2023.05.07
[우아한테크코스 5기] 장바구니 1단계 학습 (2)	2023.04.30
[우아한테크코스 5기] 웹 자동차 경주 1단계 학습 로그 (1)	2023.04.23
[우아한테크코스 5기] 레벨1 레벨인터뷰 회고 (0)	2023.04.06
[우아한테크코스 5기] 체스 2단계 학습 로그 (0)	2023.04.02