EZY, 계획하는 방식을 새롭게 정의하다.

제가 한 일이에요 !

• 컨트롤러 / 서비스로직 주석 수정/보완
• 회원탈퇴 컨트롤러 Response Http Status 204 -> 200으로 지정
• 아이디(username) 찾기 로직 삭제

아이디(username)찾기 로직을 삭제한 이유는 이와같습니다 (iOS와 소통 한 결과...)

1. 아이디(username) 재설정 기능이 있다. (로그인 후 사용가능한 기능)
2. iOS 단에서 기능이 없는 줄 알고 페이지 자체를 만들지 않고 서버에서만 만든 기능이라고 합니다. (현 PR 서버 부분에서 기능 삭제함)

여러분의 의견 듣고싶습니다. (개인적으로 로그인 하지 않았을 때 아이디(username)를 재설정하던지, 찾는 기능이 필요하다고 생각합니다.)

한 PR 에 많은 변동사항 죄송합니다 ! 작업하다보니 많아졌네요 😓

저희 엔티티에 이슈가 있는 것 같습니다.

가설은 아래와 같습니다.

1. PlanEntity 생성자를 만들어 PersonalPlanEntity, UserEntity, categories 를 실어 16 개 넘겨줍니다.
2. 이렇게 되면 PlanEntity 16개가 동일한 PersonalPlanEntity를 FK 로 참조하게 되는데요.

저는 이렇게 생각합니다 1개의 PersonalPlan은 무조건 한번 FK 를 참조하게 해야하고, 결론적으로 Plan 과 PersonalPlan은 1대1 대응이 되어야 한다고 생각합니다. 제가 제기한 이슈에 대해 comment 남겨주세요.

이슈의 발단

이슈의 발단은 다음과 같습니다.

@qoxogus 님이 getRefreshToken 메서드가 HttpServletRequest객체를 인자로 받고 있어 Test코드작성이 어렵다고 하셨습니다.

하지만 그 말은 HttpServletRequest객체 대신 순수 JWT값을 getRefreshToken메서드에 DTO와 같은 형식으로 넘겨주면 해결 될 문제일거 같아 getRefreshToken로직에 대한 분석을 진행했습니다.

그러면서 해당 구조적인 문제를 발견하게 되었습니다.

Service가 controller에 의존하게 되는 문제

Controller에서 생성되는 HttpServletRequest를 Service로직(getRefreshToken)에서 사용한다는 것은 Service(RefreshTokenServiceImpl)는 Controller(RefreshTokenController)에 대한 의존성을 가지고 있다는 의미를 담고 있습니다.

HttpServletRequest은 톰켓과 같은 WAS에서 관리하므로 개발자는 순수 비즈니스 로직에 집중해야 합니다.

RefreshTokenServiceImpl가 RefreshTokenController에 의존하게 되어 생기는 문제점은 다음과 같습니다.

• RefreshTokenServiceImpl로직에 대한 불안정성이 높아지게 됩니다.

  참고 레퍼런스 입니다. https://techblog.woowahan.com/2561/

• RefreshTokenServiceImpl 이 RefreshTokenController에 높은 결합도(high coupling)이 생깁니다.

  직접적인 의존관계는 아니지만 getRefreshToken매서드는 RefreshTokenController에서 생성되는 HttpServletRequest가 없으면 로직을 수행할 수 없으므로 높은 결합이 생겼다고 할 수 있어요

해결 방안

controller에서 Header에 저장되어있는 JWT값을 추출 후 순수한 데이터를 service에 넘겨주기

• RefreshTokenServiceImpl는 좀 더 POJO에 가까워질 수 있어요

  getRefreshToken메서드는RefreshTokenController의 HttpServletRequest이 아닌 순수한 값에 의존하기 때문

• 결합도가 줄어들어 재사용성, 확장성이 증가합니다.

결론

RefreshTokenServiceImpl의 getRefreshToken매서드는 HttpServletRequest객체 대신 순수 데이터를 전달받아야 합니다.

PersonalPlanSave Dto로 RequestBody(json) 형식을 갖춰 사용자에게 요청받기

현재 builder를 위해 존재하는 생성자가 spec과 맞지 않다 생각들어 도움을 요청합니다!

PersonalPlanSetDto는 아래와 같게 설계 했습니다.

@Getter @Builder
@NoArgsConstructor(access = AccessLevel.PROTECTED) @AllArgsConstructor
public class PersonalPlanSetDto {
    @NotNull
    private PlanInfo planInfo;
    @NotNull
    private Period period;
    private TagEntity tag;
    @NotNull
    private Boolean repetition;

    public PersonalPlanEntity saveToEntity(MemberEntity memberEntity){
        return PersonalPlanEntity.builder()
                .memberEntity(memberEntity)
                .tagEntity(this.tag)
                .planInfo(this.planInfo)
                .period(this.period)
                .repetition(this.repetition)
                .build();
    }
}

이처럼. Builder 를 통해 사용되는 개인일정을 추가하는 생성자 가 Entity만을 받기 때문에.. ReqBody로 하여금 여러 Identity 불변을 지키지 못하는 상황을 초래하게 됩니다. (아래 dto json spec 참고)

도움을 주시면 좋겠습니다. 이 문제를 어떻게 해결하는게 좋을까요? @qoxogus @siwony

EZY UserEntity에 issue 를 추가합니다.

테스트 가설

1. @BeforeEach 로 회원가입/로그인 로직 작성 - nickName 중복 Issue 발생
2. 모든 메서드에 같은 회원가입 로직 사용 후 호출, 통합테스트 - nickName 중복 Issue 발생
3. 통합테스트 진행 - 아래와 같은 컬럼 생성(사진참고)

PlanEntity에 PersoanlPlanEntity personalPlanEntity 필드에 UNIQUE 제약조건을 추가하여 #55 이슈를 수정했습니다.

이제 PlanEntity와 PersonalEntity는 1 : 1 매핑이 확실하게 되었지만 src.test.com.server.EZY.model.personal.repository.PlanRepositorySupportTest에 개인일정_모두_찾기() 테스트가 실패합니다. Stream으로 PlanEntity 생성하실때 PersonalPlanEntity를 new 연산자를 활용하여 객체를 각각 생성하셔서 진행하시길 바랍니다. @Johnjihwan

예시

        List<PlanEntity> planEntities = Stream.generate(
                () -> new PlanEntity(
                        new PersonalPlanEntity(),
                        userEntity_t,
                        categories
                )
        ).limit(12).collect(Collectors.toList());

제가 한 일이에요 !

• 전화번호 중복여부 확인 API 개발

• 회원가입 조건문 수정

existsByUsernameAndPhoneNumber를 사용하지 않고 이렇게 따로 && 연산자를 이용하여 처리한 이유는 existsByUsernameAndPhoneNumber를 사용하면 unique속성인 username, phoneNumber 입력값 중 하나만 이미 회원인 정보와 일치했을 때에 이미 존재하는 회원입니다 예외가 아닌 알 수 없는 에러(sql unique에 대한 예외)로 핸들링이 되어버려 이러한 방법으로 처리했습니다.

제가 한 일이에요!

• request username이 @로 시작되는지 check하는 조건문 추가
• 그에맞게 테스트코드 변경

currentUser는 MemberService에 있는 로직을 거치치 않기때문에 @ checking을 추가하지 않았습니다 (입력값만 변동해주면 될 것 같아요)

clean build result

코드에 문제가 있어보이거나 궁금한 점 있으면 comment달아주세요 ! 😊

전지환님 께서 요청하신 데로 PlanEntity의 이름을 HeadOfPlanEntity로 변경하였습니다.

PersonalPlan로직 변경사항

• 변경 도중 PlanRepositoryCustom와 PlanRepositoryCustom의 구현체 PlanRepositoryImpl에 findThisPlanByUserEntityAndPlanIdx 매서드명이 다음과 같이 변경되었습니다. findThisPlanByUserEntityAndHeadOfPlanIdx

• PersonalPlanService에 있는 PlanRepository는 HeadOfRepository로 변경되었습니다.

• PlanRepositoryImpl에서 기존 QPlanEntity를 사용하던 것을 QHeadOfPlanEntity를 사용하게 되었습니다.

지환님께서 검토해야 할 일

• PersonalPlan로직에 대해 전반적으로 검토

• PersonalPlan로직에 대해 PlanEntity관련 주석을 HeadOfPlan으로 변경

• 전반적인 personalPlanEntity의 test code 검토

Test 상황

PlanEntity의 이름을 PlanManageMent로 변경했습니다. 그로 인하여 QueryDsl에 충돌이 있었는데 /build/generated 경로를 삭제해 주시고 Gradle의 compileQuerydsl task를 실행해 주시길 바랍니다. (ex. gradle compileQuerydsl)

테스트는 아무 문제 없이 실행되었습니다.

UserControllerTest 에서 통합테스트 시 signupTest에서 테스트를 실패합니다.

before() 는 @Test가 달린 모든 테스트 메서드가 실행하기 전에 무조건 실행합니다. 그리하여 signupTest를 실행하기 전에 이미 before() 에서 BeforeEach 라는 유저를 만들고 그후 signupTest에서 BeforeEach유저를 만들어 CustomException이 발생합니다. 이부분 수정바랍니다.

그리고 controller 를 테스트 한다는 것은 클라이언트에 반환되는 json값을 테스트 해야 하지만 UserControllerTest 는 서비스 로직을 테스트합니다. contoller를 테스트 하는방법은 MvcMock 객체를 사용하는 방법이 있습니다. 참고링크: https://theheydaze.tistory.com/218

현재 저희의 querydsl 은 위와 같은 extends, impl 구조로 상속, 구현 되어졌습니다. 하지만 v1.1.0 부터 하나의 repository 에 JPAQueryFactory 클래스를 생성자 주입 후 사용하려 합니다. 즉, 현재와 같이 DataJPA 와 querydsl 을 나누어 구조화 하는 것이 아닌, 하나의 repository 로 통합하여 사용하려 합니다.

v1 릴리즈 전에 이 부분을 수정하기에는 리소스도 꽤 크고 성능에 영향이 있는 부채는 아니기에 v1.1.0 이후로 전가 합니다.

참고하기 -> 우아콘2020 수십억건에서 QUERYDSL 사용하기