[Review] 2022/05/25 1차 PR (Aribnb 서비스)

이번 리뷰는 Dion 께서 해주셨다! 리뷰해주셔서 감사합니다 !!

https://github.com/codesquad-members-2022/airbnb/pull/40#discussion_r883130404

[Team - 06][BE] 에어비앤비 프로젝트 1주차 1회차 PR by leejohy-0223 · Pull Request #40 · codesquad-members-2022/ai

 

1. 질문

1-1) 위치 검색에 대한 질문

사용자의 위치(위도, 경도)를 중심으로 1km 정도의 범위에 해당하는 좌표의 House들만 조회 해오려 하는데,
이런식으로 접근하는 것이 맞을까요?... 지도 탐색이 처음이라 애당초 어떻게 접근해야 할지 감이 조금 안옵니다.
애당초 위도, 경도로 접근하는게 맞을지....

 

(다행이 우리 스스로 답을 찾았다. 가장 먼저 지도부터 만들고 시작했기 때문에 1주차의 보람이 큰것 같다.)

 

1-2) User의 검색 조건을 누가 유지할 것 인가?

우선 User는 다음과 같은 흐름으로 방을 검색해 나간다.

위치 -> 날짜 -> 가격 -> 인원수 -(필터링)-> 검색조건

위 과정마다에서 축적된 검색 조검을 누가 유지하고 있어야 할까요?

 

만약 가격까지 조건을 지정하다가 다른곳으로 잠시 이동하면 그동안 누적된 위치, 날짜, 가격 조건을 누가 저장하고 있어야 하는가?

에 대한 의문이 들었습니다.

 

일단 사용자의 Session을 만들어 저장시켜 두면 될것같은데?... 리뷰어님의 의견이 궁금합니다.

 

1-3) 검색 조건 SearchConditionDto는 어디까지?

검색 조건을 담고 있는 SearchCondition은 과연 어디까지 인자로 넘겨줘야 할까요?
일단은 controller 에 SearchConditionDto 로 전달하고, service, repository 에서는 메서드에 SearchConditionDto 을 전부 인자로 전달하도록 할려 하는데, 이게 맞는지 궁금합니다.

@Service
public class HouseService {

    private final HouseRepository houseRepository;

    public HouseService(HouseRepository houseRepository) {
        this.houseRepository = houseRepository;
    }

    public Page<House> findByCondition(Position position, Integer minFee, Integer maxFee, Pageable pageable) {
        return houseRepository.searchByCondition(position, minFee, maxFee, pageable);
    }

    // 생략...
}

위와 같은 코드가 더 적합할지, 아니면

@Service
public class HouseService {

    private final HouseRepository houseRepository;

    public HouseService(HouseRepository houseRepository) {
        this.houseRepository = houseRepository;
    }

    public Page<House> findByCondition(SearchConditionDto condition, Pageable pageable) {
        return houseRepository.searchByCondition(condition, pageable);
    }

    // 생략...
}

위와 같은 접근이 더 적합할지... dto의 데이터를 꺼내는 시점에 다른 글마다 다르기도 하고...

확실한것은 repository 에는 dto를 전달하면 안될것 같아서 최소 service에서는 값을 꺼내 전달해야 될것 같은데...

리뷰어님의 의견을 듣고 싶습니다.

 

1-4) 답변

공간 좌표 같은 경우 MySQL의 Point 라는 자료형을 사용하면 저장하기에 편리하다.

또한 Spring에서도 Point 자료형을 사용할수 있기 때문에 이를 활용하면 저장, 추출에 편리하다.

 

또한 거리 계산은 MySQL의 함수중 하나인 ST_Distance_Sphere 를 사용하여 해결하였다.

 

2. 코드 리뷰

2-1) API URL의 리소스 식별 명칭

다음과 같은 리뷰를 받게 되었다.

사실 왜 search 라는 동사형의 이름을 선택했는지 과거의 나도 의문이다.

자원에 대한 행동은 Method로 정의하면 되는데, 사실상 Search는 GET 메서드로 충분하게 의미를 전달할 수 있었다.

 

또한 URL 설계 가이드를 찾아보게 되는 좋은 리뷰였다.

https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

위 글에서 나온 내용중 일부이다.

 

▶ URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)

    GET /members/delete/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI입니다.

URI는 자원을 표현하는데 중점을 두어야 합니다. delete와 같은 행위에 대한 표현이 들어가서는 안됩니다.

 

이 외에도 여러 API 가이드 사항을 읽게 되었다

 

2-2) Embeddable 타입의 필드 접근

다음 문제는 사실 평소에 Lombok의 getter, setter를 즐겨 사용하기 때문에 경험해보지 못했던 문제이다.

이번 프로젝트 기간동안에는 Lombok을 사용하지 않기로 팀원과 협의 했기 때문에 직접 구현하여 사용하고 있는데,

덕분에 이러한 문제도 경험해보고 좋은것 같다.

 

우선 JPA는 FIELD, 프로퍼티(getter,setter) 엑세스 두가지 방법이 있다.

따라서 해당 Entity에 접근하려면 두 방법중 한가지를 명확하게 명시 해줘야 한다.

 

하지만 처음 우리 코드에서는 Getter만 있고, Setter가 있지 않았다. 따라서 다음과 같은 경고가 발생했다.

getter 와 setter 모두 명시하기를 권장한다는 경고문 이다.

 

이를 해결하기 위해 getter/setter 모두 명시해주는 대신, 위에서 봤듯 @Access(AccessType.FIELD)를 적용하게 되었다.

 

이와 관련된 영한님의 답변글이 있었다.

https://www.inflearn.com/questions/78106

@Embeddable 사용시 질문 입니다. - 인프런 | 질문 & 답변

 

2-3) @GenaratedValue의 전략 명시

기본적으로 H2 과 Oracle은 시퀀스 전략을, MySQL 은 identity 전략을 사용한다.

하지만 나는 평상시 아무것도 명시하지 않으면 사용하는 auto 전략을 주로 사용하였다.

테스트 시 H2 DB를 사용하다가 배포때는 MySQL 등 다른 DB로 변경해서 사용하려 할수도 있는데, 전략을 명시하지 않으면 DB에 의존하는 기본 전략을 선택해주기 때문에 혹여 나중에 DB를 바꾸더라도 수정하지 않아도 되기 때문이다.

 

혹시 명시로 하게 되는 장점이 있을까?? 다음과 같이 답변해 주셨다.