A. 이 부분은 사실 registNum을 쓰는것에서 너무 한번에 ROLE로 구분하고자하는 것으로 변경되고 있습니다. 기본적으로 완성된 상태에서 개선이라는 토픽을 정하고 그것이 챌린지의 과제입니다. 그런점에서 살펴보면 현재 상태는 프론트엔드를 안보더라도 기본적인 백엔드 코드가 완성이 되지 않은 상태로 볼 수 있습니다. 컨벤션 이런 구성을 떠나서 기능적으로 인증/인가 에 대한 유효성 검사, 예외 처리등을 보완해야 합니다. 하지만, 첫번째로 registNum을 사용하는데 그것에 대한 기본적인 Validation이 없습니다. 따라서 Validation에 대한 작업을 해야하는데 여기서 연결되서 또 살펴보면 기본적으로 DB 설계의 잘못된점이 있습니다. User에 사업자 번호가 있을 필요가 없습니다. Store에 있어야 하고, 오히려 User가 받는 Store_Id PK가 null인 경우로 만들어야 합니다. 현재 회원에 너무 매몰되어있지만, 사업자번호는 가게에 있으면 되는것이고, 모든 User중에 사업자(가게 등록)을 하는 API가 있으면 거기서 오히려 User에게 Store_id pk를 주는 방식이 맞습니다. 위 내용을 토대로 결과적으로 이 팀은 DB 설계부터 다시 기본 형태들을 갖춰서 완성 상태를 만들어야 챌린지가 시작된다 생각해야합니다. 현재 상태로는 챌린지를 하는것이 아니라 기본 상태가 구성되었다 하기 어렵습니다. 마치 완성되지 않은것에 갑자기 어려운 기술스택을 사용해보는 시도를 하는 것과 같습니다. 이 말은 그냥 바로 어려운 기술 스택을 공부해보는 스터디와 별반 다를바 없다는 판단입니다. 또한 현재 방식은 결국 팀보다는 개별적인 프로젝트를 하는 느낌이 또 나타나게 됩니다. 결국 개인 스터디를 팀만 꾸려서 하는 느낌은 동일하기 때문에 팀프로젝트를 했다 라는 것으로 보기에 어렵습니다. 우선 기본을 갖추도록해야 합니다. 아래 답변을 참고하시기 바랍니다.

Q. 현재 프로젝트 종료까지 현실적인 프로젝트 주제 정리에 어려움이 있습니다.

A. DB 설계 보완과 AOP적용, 각 기능의 테스트코드, 리프레시토큰 까지 범위를 기본 범위로 잡으세요 1. DB설계 수정 -> User 에서 가게를 등록하는데 검증하는 getStore reginum 두개를 쓴다플로우 차트에 대한 미스 2. 설계가 맞는가? "제 2 정규화"에 대해서 찾아보고 적용하기 3. DB 역할에 대한 문제 부분 코드 상태 변화, ERD 변화 등 개선된 모습 기록해두세요(초기, 중반, 현재를 추적하며 회고 내용으로 조금 다룰 생각) 예외 핸들러 적용 <<-- 적용하기 4. 아래 부분을 AOP를 적용해서 해결하세요. aspect -X필요없음 / 컨트롤러 등 어드바이스 <<-- 적용하기 / // 중복 코드 제거를 위한 메소드 private ResponseEntity<StatusResponseDto> handleServiceRequest(Supplier<StatusResponseDto> action) { try { return new ResponseEntity<>(action.get(), HttpStatus.OK); } catch (IllegalArgumentException ex) { ex.printStackTrace(); return new ResponseEntity<>(new StatusResponseDto(ex.getMessage(), 400), HttpStatus.BAD_REQUEST); } catch (Exception ex) { ex.printStackTrace(); return new ResponseEntity<>(new StatusResponseDto("서비스 요청 중 오류가 발생했습니다.", 500), HttpStatus.INTERNAL_SERVER_ERROR); } }

Q. 위까지 정리한다면 다음과정은 어떤것을 진행할까요.

A. 테스트 코드를 작성하세요 테스트의 범위는 한다면 다해야지 대표기능만 단위를 뽑아서하는건 테스트코드의 목적이아님, 테스트 코드를 만든다는것 자체가 기본은 모든기능이 작동하는지에 대한것이기 때문 여기까지가 과제의 종료일수도 있습니다. 테스트코드의 러닝커브도 있기때문에, 이상 진행되기 어려울 수 있습니다.

Q. 그 다음과정은 어떤것을 진행 할 수있을 가능성이 있나요?

A. 리프레시 토큰까지 스터디? 정도 가능할 것 같습니다. 테스트코드까지 과정을 진행했다면 리프레시토큰 까지 적용하거나 조금 안된다면 이 부분의 정리 정도까지가 최대 가능 범위가 될 것 같습니다. 여기부터가 사실 조금 챌린지과제의 시작이라 볼 수 있습니다..

Q. 시간적으로 불가능하더라도 이 과정과 연속된다면 어떤것들을 했어야 할까요?

A. 사실 여기부터가 챌린지라 볼 수 있습니다. 위까지 기본적인 세팅이 종료된 것이고 이미 일정상 여기가 진행되고 있어야 되는 시점이기도 합니다. 인증/인가에 대해서 위 처럼 기본 세팅이 되었다면 ROLE방식으로 할지 어떻게 개선되는지를 보여 줄 수 있는데 현실적으로 시간이 부족합니다. 그래도 유저와 비지니스 유저로 구분하는 것을 작업하시던 부분이 조금 있기 때문에 시간에 따라 포함되면 좋겠지만 우선순위는 위 과제들이 해결되어야 합니다. 여기서 유저, 비지니스로 테이블을 구분하는것까지 적용시켜보는 것이 한가지 방안, 스프링의 어노테이션등을 적극 활용한 권한 구분, 설정 등을 다뤄보는 것이 두번째 방안으로 이처럼 2가지를 비교 또는 개선 진행해보는 것이 처음 시작 될때 구도가 잡혀있었으면 좋았을텐데 현재 이 주제를 다루기에는 현실적으로 하루 이틀로는 시간이 부족합니다. 첫번째 방안이라도 회의를 통해서 적용 할지, 현실적인 시간에 맞춰서 팀원간 회의를 진행해야 합니다. 배포와 과제 작성등에도 문제가 발생할 수 있는 시간도 충분히 고려해야 하기때문에 시간이 부족하다는 판단이 됩니다.

ROLE로써 유저 유형을 구분한다하면 API자체에 접근하지 못하게 하는것이 스프링의 의도 → @PRE… → API도 변경되야 하는데, 큰 의미가 없다. 또 별도로 프로젝트하는 느낌이다.

•

→ 지예, 테이블을 나눔 → 메소드를 1, 2인지 정해야되는것이고 → 1로간다면(기존방식) 위 답변중 추가할 기능 보완을 해야한다.
 만약 2로 간다면, spring security쪽에서 추가적인 설정또 있어야한다. = 오래걸린다. 위험X

•

→ 인용해찬, Spring주석을 사용하려한다 @Pre메소드를 제한하기때문에 메소드 2가 필수적 = 오래걸린다. 위험X

•

그럼 다시 최초 문제부터 생각해보자.

◦

문제의 발단은 registNum = null 이걸 해결하기 위한 문제라는것

▪

그런데 이것 조차 완성된 상태가 아닌데 벌써 Spring ROLE로 넘어간다? 순서가 맞지 않는다.

▪

→ Validation을 생각 안했던것부터 채워야 하며, 그걸 보기 위해서는 살펴보니 DB 설계부터 또 문제가있다.

•

→ DB설계부터 뜯어고쳐야 한다. → API그 변경에 따라 손봐야할수있다.

•

→ 그 이후 AOP도 기본사항이다.

•

결과적으로 챌린지라기 보단, 시간을 많이 소모했기도 했다. 오히려 서비스팀보다 퀄리티가 낮을 수 있다. 하지만 위 기본사항은 채워야 하는게 현실이다. 따라서 “코드개선”을 목표로 우선 하고 “테스트코드” 작성까지를 최종적인 완료로 일단 생각하는 편이 좋다. 시간적 여유가 부족하다.

◦

그럼 코드 개선에 대해서라도 자료들을 좀 정리해야한다.

▪

최초 상태(잘못설계되었던 ERD 주문과 가게가 연결되었던 그시점1

▪

1차로 수정 정리, 했는데 부족했다.

▪

→

▪

현재상태

▪

그리고 이제 바꿀 registNum이 Store테이블로 이동한 상태

◦

왜 이런 설계 미스가 있었고, 어떤 부분이 잘못되었다 생각되었었고, 그렇기 때문에 고쳐나갔다. 이것의 반복을 스토리로만들어라. 

◦

그 ERD들의 변화를 보여줄 자료도 만들면 좋다.