[멋쟁이사자처럼] 코드리뷰 2주차

1주차는 긴장을 풀기위한 시간이였고 2주차부터 본격적으로 시작되었다.

 

 

점수에 따라 면접기회를 준다는데 개인적으로 면접 보다는 다들 어떻게 요즘 개발하는지에 대해 궁금증이 더 커 신청한것도 있어 평소에 하듯 코드를 작성했다.

 

그 중 리뷰 받은 거은 어떤 것이고 어떻게 해결하였는지 정리하는 시간을 가져 보았다.

 

1. pull Request 실수

 

 

알고 봤더니 급한 나머지 처음에 pull Request한것을 Merge 후 새로운걸을 올렸어야 했는데, Request를 다시 올려 모든 코드를 다시 리뷰 받았다.

 

 

잊지 말아야겠다 ㅠㅠ

 

2. MVC 파라미터값 체크

 

 

평소에 MVC 패턴에서 유효값을 체크할 때, @Valid와 여기서도 유효성 검사가 힘든것은 validate를 만들어 사용했다.

 

근데 내가 하는 로직에는 문제점이 있었다.

 

@Controller안에 validate가 있으니 요청값과 응답값을 받아 처리하는 Controller단 말고 다른곳에 있었으면 하는 마음이 있었다.

그것을 리뷰에서 정확히 봐주신것같았다.

 

리뷰하신 분께서 @initBinder를 사용해보는것이 어떠냐고 하여서 분리를 시켰다.

 

 

3.  Schema.sql , data.sql 삭제

 

profile test로 테스트를 하면 table이 다시 생성되는 환경이 였다.

필수로 DB에 필요로 한 값이 있어서 쉽게 테스트 할려고 넣어놨었다.

 

 

sql문을 직접적으로 넣는거라 에러도 없고 미션지에 있는 pdf에 그대로 넣어주면 되는 쉬운 방법이다.

하지만 코드레벨쪽에서 진행을 하게 되면 내가 연관관계나 SQL문에 썼던것보다 더 간략하게 넣을 수 있어 그런것으로 바꾸었다.

 

 

@PostConstruct를 사용하여 DB가 생성 된 후, 실행을 하였고 @Profile에 test를 추가하여 test profile때에서만 실행되게 수정을 하였다.

 

 

4. N+1 문제

 

 

JPA를 사용하면 연관관계가 잘 연결되어 있으면 findByid 로 찾아도 Item -> ItemImage -> delivery 등 한번에 사용할 수 있는 쉬운 점이 있다.

하지만 여기서도 문제가 있다.

내가 만약 1개의 쿼리를 찾았다면 1+1 총 2개가 조회가 되고, 1000 을 찾으면 1000 + 1000 가 찾아지는 안좋은 문제 점이 있다.

 

 

JPQL로 필요한 값들을 dto안에 넣어사용하거나

 

 

 

join fetch 를 사용하여 조회속도를 더 향상 시켰였다.

 

 

5. 네이밍

 

 

상품 테이블에 일대다 연관 관계에 있는 ItemImage라는 테이블이 있었다.

어떻게든 이름을 지울려고 한 흔적이 있었다.

 

패키지가 Item이나깐 Item을 지우고 ItemIamge를 넣어야지? 라는 생각으로 넣었었다.

하지만 Image라는 것이 너무 포관적이였다.

또, 다른곳에도 Image라는 것이 들어갈 확률이 높아 ItemImage인지 UserImage인지 알 수가 없기 때문에 좋지 못한 네이밍이라고 리뷰를 받았었다.

 

총평, 솔직히 코드보다는 네이밍에 관해 너무 적는것이 어렵다는 것을 느겼다.

직관적이고 명확한 단어가 무엇이 있을까? 짧은것보다 긴것이 어느때는 더 좋은 네이밍이라고 느껴 항상 HashMap를 사용하여 메소드를 작성한던 날이 초라해지는 시간이였다.