[TIL] 5주차 주특기 심화ㅣ과제 제출과 코드 리뷰

 

주특기 심화 주간 과제

팀 과제 진행 상황

Lv2까지 기능 구현이 전부 완료되었다.
제출해야 될 문서를 다듬고 제출까지 완료!

조원분들과 남은 시간을 어떻게 알차게 보낼 수 있을지 상의해봤는데
'더 나아가기'에 나와있는 추가 기능을 구현하기로 했다.

 

 

이 중 회원 탈퇴, 게시글 카테고리, 게시글 페이징을 각자 맡아 막 구현에 들어가려던 찰나,
기술 매니저님의 순회와 함께 갑작스러운 코드 리뷰가 시작되었다..!😦
그리고 깨달았다.. 지금은 추가 기능이 아니라 리팩토링을 해야 하는 시간인 것을..
기술 매니저님께 받은 코드 리뷰를 토대로 궁금증을 정리해보았다.

 

 

 

오늘의 궁금증

 

update 이후 DB에서 해당 id로 조회해오면 그건 같은 걸까?

@Transactional
    public BaseResponse update(Long id, BoardRequestDto requestDto, User user) {
    
        ...
        
        // 업데이트
        board.update(requestDto);
        
        // id로 DB에서 조회
        Board board = boardRepository.findById(id).orElseThrow(
          () -> new CustomException(NOT_FOUND_BOARD)
        );
        
        ...
    }

놉 아니다.
update만 되어있는 상태는 영속성 컨텍스트 1차 캐시에 저장되어 있는 상태이고,
DB에서 불러오는 건 변경이 적용되기 전이라 다르다고 볼 수 있다.

 

그럼 변경 저장은 언제 될까?

@Transactional이 붙어있으니 로직이 끝나고 커밋이 되는 시점에 변경된다.

 

 

왜 @Repository를 생략해도 되는 건지?

// @Repository 없음!
public interface BoardLikeRepository extends JpaRepository<BoardLike, Long> {
    Optional<BoardLike> findByBoardIdAndUserId(Long boarId, Long userId);
    void deleteByBoardIdAndUserId(Long boardId, Long userId);
}

'JpaRepository를 extends 했기 때문'이라고만 알고 있었는데 원리가 더 궁금해져서 찾아보았다.

 

@NoRepositoryBean

@NoRepositoryBean
public interface JpaRepository<T, ID> extends PagingAndSortingRepository<T, ID>, QueryByExampleExecutor<T> {
...
}

일단 JpaRepository 인터페이스를 뜯어보니 @NoRepositoryBean 이런 어노테이션이 사용되고 있었다.
해당 어노테이션은 Repository 인터페이스를 상속받았기 때문에 실제 빈을 만들지 않도록 하기 위하여 사용되고, 실제 사용되는 Repository가 아님을 의미한다.

그럼 도대체 어디서 빈등록이 이루어지는 걸까?

 

@EnableJpaRepositories

spring-data-jpa의 Repository 빈 등록은 @EnableJpaRepositories 어노테이션에서 이루어진다. Spring Boot에서는 자동 설정되어 생략 가능하다.

 

📚 참고자료

[SpringBoot] spring-data-jpa 사용시 @Repository 어노테이션은 꼭 필요한가?

 

 

이 외에 생각해볼 만한 질문들

• 빌더 패턴
  • 빌더 패턴(Builder Pattern)
• ResponseEntity vs @ResponsStatus
  • ResponseEntity vs @ResponseStatus
• JPA에 exists라는 쿼리 메소드가 있었어..?
  • JPA exists 쿼리 성능 개선

 

 

 

오늘의 나는

사실 요즘 처진 기분이 많이 들었는데,
코드 리뷰를 받는 순간 심장이 약간 두근거렸다.(변태인가;)
내 코드는 좋은 코드일까? 항상 들었던 의문에 '아니! 너 코드 지저분함!'이라는 답을 얻은 꼴이지만
오히려 좋다. 눈에 보이지 않던 부분들이 보이니까 다시 의욕이 생기는 너낌!
그래 이 맛이지.. 수정사항들 고쳐나가면서 다시 페이스를 좀 찾았다.

기술 매니저님은 다음의 내용을 계속 강조하셨다.

• 주석이 없어도 이해 가는 코드가 좋은 코드!
• 메소드는 하나의 역할만!
• 각자의 역할이 명확히 분리되는 것이 중요!

처음 설계할 때부터 고려하면 더 좋을 것 같다.

 

이렇게 심화 주차까지 주특기 주차가 마무리되었다.
아직 구현하지 못한 기능.. 보지 못한 강의.. 이런 게 잔뜩 쌓여있지만
당장 내일부터 시작할 프로젝트가 들어올 자리를 마련해줘야겠지.
잔뜩 기대 중. 빨리 프로젝트하고 싶다! 😛