sideDish 피드백-2

이 부분은 oauth를 적용시킨 이후의 피드백 부분과 이전 부분이 혼합되어 있습니다.

 

item이 너무 많은 필드를 가지고 있긴 했다. 

나중에 table상이나 java코드 상으로 분리를 진행해보려 했는데 oauth에서 시간을 많이 써서 하지는 못했다.

delivery부분을 emembedded로 빼버리려 했다.

 

N+1 쿼리가 발생하는 부분이다. item 한번 가져오면 거의 15번의 쿼리가 나가니..

직접 sql문을 짜서 resultSet으로 긁어 오면 되지만 spring data jdbc로 했을 경우는 어떻게 해야 할지 모르겠다.

예외처리 부분이다. 지금은 처리가 다 똑같이 그냥 예외 message만 보내주고 있다. 

미래에 다른 처리를 위해 분리하는 것이 나은 것인지. 지금은 같으니 합치는 것이 나은 건지.

 

이 부분도 고민을 했다. static으로 하면 많은 부분이 쉬워진다. 만능이니까. 근데 이러면 객체지향적이지 않고 정말 많은 static이 있음 메모리 문제도 있을 수 있으니..

위와 같이 한 이유는 service에서 코드를 한 줄이라도 줄여보기 위함이었다.

변명을 해보자면.. 머지가 되지 않은 상태에서 계속 작업을 하다 보니 중간중간 실험작들이 올라갔다.

일단 동작을 확인하고 리팩토링을 진행할 생각이었다. 그렇기에 controller에 있음 안 되는 검증 로직이 있었다.

위의 로직은 비즈니스 로직이라 생각을 해서 service에 있어야 한다. 

또 특정한 url에만 검증을 함으로 인터셉터로 빼버렸다.

 

인텔리제이의 cleanCode 기능 중 바뀌지 않는 부분이 있으면 final을 다 붙여버리는 옵션이 있었다. 

그래서 오류도 많이 나서 꺼버렸다.

VO 같은 경우는 final을 붙이는 것이 맞지만 DTO의 성격을 봤을 때는 final을 붙이지 않아도 된다는 것이다.

물론 기능의 문제가 생기는 것은 아니지만 DTO의 정보가 중간에 바뀔 수도 있다는 뜻일까?

 

jwtToken이 있을 때 또 login요청을 하면 jwtToken을 발행한다. 

이 부분에 대해서는 DB에서 저장을 해야 하나 말아야 하나 고민을 했었다.

다음 미션에서 다시 한번 고민해야 하는 부분이다.

 

user에서 파라미터를 짧게 하고 싶어서 DTO를 받았다. 

빌더를 사용하던가 하는 것이 맞아 보인다. 위와 같은 경우는 user를 만들려면 DTO를 먼저 만들어야 하는 상황이기 때문이다. 협력을 줄이자.

 

urlConstant는 상수 class로 되어있다. enum으로 바꾸면 물론 해당 class는 깔끔해지지만 

매번 사용할 때마다. getUrl()을 쓰는 것은 깔끔해 보이지 않았다.

그래서 다시 변경하였다.