perfect dish | Refactoring (1) - 요구 사항이 계속 변경 되면 말이지요

🍽 Perfect dish 개발 일지

이 글은 개발 여정을 기록한 것으로 틀린 내용이 나올 수 있습니다. 점점 고쳐나가기 때문이죠 

 

요구사항을 모두 구현하고 테스트까지 마쳤다. 오늘부터 리팩토링에 들어간다. 
controller에 ResponseEntity로 상태코드 , 응답헤더와 본문을 보내어 postman으로 확인하려 한다. 

 

💡 회원 가입 시나리오 - 이 로직은 어떤 계층에 있어야 하는가 

 

기능을 개발할 때는 db와 직접적으로 상호작용을 하는가? 사용자 요청 처리를 하는가? 이 둘로 나누었다. 

회원가입을 하려면 
1. 이름 검증 
 ㄴ 중복 ? 010을 제외한 휴대전화 번호 8 자리 입력 및 검증
                  ㄴ 중복? throw 사용자정의 에러코드와 메시지 
2. 회원으로 등록 완료 + status : ACTIVE 

   
현재 repository, service레이어 둘 다 이 메서드 들이 혼재해 있다. 

[before]
번호 8자리에서 뒤 4자리만 추출 
4자리 중복 리스트 중 이름이 같은 유저 추출 
--------------------------------------

번호 -> 이름 순 이었다면 

[after]
이름 으로 먼저 필터링 -> 중복 있을 수 있음, List<String>
번호 8자리 같은 유저 추출 
-------------------------------------

 

💡 Menu의 예외 처리 추가 시 

 

Menu를 save 할 때 중복되는 메뉴 이름이 있으면 예외 발생을 추가하였다. 
repository 부분에서 collection별 성능 조회를 하는 로직에서 Set에 같은 이름으로 fixture가 만들어지니 ^.^ 

해결방법으로 생각해 낸 게
fixture에 이름 생성시 메뉴이름 + count를 붙여 메뉴1, 메뉴2, 메뉴3 ... 이런 식으로 생성하게 고쳐보자꾸나 

fixture를 고쳤으니 올라가서 hashSetLookup 도 수정해야지

잘 만들어지고 있니? 

+ 동일한 fixture로 비교해야 하기 때문에 map에도 이름 뒤 count를 추가 하여 성능을 테스트 하였다. 

 

💡 계층 별 예외처리 

어느 계층에서 (특히 service에서) 어떤 예외처리를 하였는지 이걸 명확하게 정하지 않고 해서 controller에서 이 예외처리가 필요한가? 하고 확인하게 된다. 

repository - db와의 상호작용에서 정합성이 깨지지 않도록

service - 비즈니스 로직에서 발생

controller - 입력 값 등 클라이언트와의 상호작용에서 발생

[before]

위 로직의 유효성 검증은 controller로 옮기고 아래 처럼 비즈니스 로직에서 발생하는 예외 상황을 처리하자 

그런데 repository에서 Optional로 반환려다가 

null을 반환하면 에러를 유발할 가능성이 있는 경우 사용을 하자. 

그래서 지금 Menu를 조회할 때 리턴타입이 Menu인 경우와 List<Menu>인 경우, 이 두가지로 나뉘는데 
Menu인 경우 값이 없으면 NPE가 발생 / List<Menu> 인 경우 빈리스트를 반환