---

📖 과제 개요

---

이번 개인 과제는 예제를 가져와
코드를 개선하고, 테스트 코드를 작성해보고, 리팩터링 해보는 과제였다

✔️ 개발 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ
• Spring Frame Work : 3.4.4
• API 테스트 도구 : postman

🌟 Git Hub 링크

---

📖 코드 리뷰

---

📌 [Lv 1] 코드 개선하기

✅ 1. Early Return

    @Transactional
    public SignupResponse signup(SignupRequest signupRequest) {

       if (userRepository.existsByEmail(signupRequest.getEmail())) {
            throw new InvalidRequestException("이미 존재하는 이메일입니다.");
        } // 💡 수정한 위치

        String encodedPassword = passwordEncoder.encode(signupRequest.getPassword());
      
        //if (userRepository.existsByEmail(signupRequest.getEmail())) {
        //   throw new InvalidRequestException("이미 존재하는 이메일입니다.");
        //} 기존 위치
       
        UserRole userRole = UserRole.of(signupRequest.getUserRole());

		...

✔️ 배운점

• 불필요한 로직 실행을 줄이고, 코드 가독성을 높일 수 있다
• 특히 passwordEncoder.encode()와 같은 큰 연산을 줄일 수 있어 효율적이다

✅ 2. 불필요한 if-else문 줄여 리팩토링

if (!HttpStatus.OK.equals(responseEntity.getStatusCode())) {
    throw new ServerException("날씨 데이터를 가져오는데 실패했습니다. 상태 코드: " + responseEntity.getStatusCode());

if (weatherArray == null || weatherArray.length == 0) {
    throw new ServerException("날씨 데이터가 없습니다.");
    }
}

✔️ 배운점

• 불필요한 else나 중첩을 줄이자

✅ 3. Validation

UserService 클래스

if (userChangePasswordRequest.getNewPassword().length() < 8 ||
        !userChangePasswordRequest.getNewPassword().matches(".*\\d.*") ||
        !userChangePasswordRequest.getNewPassword().matches(".*[A-Z].*")) {
    throw new InvalidRequestException("새 비밀번호는 8자 이상이어야 하고, 숫자와 대문자를 포함해야 합니다.");
}

UserChangePasswordRequest 클래스

 @NotBlank
    @Pattern(regexp = "^(?=.*[0-9])(?=.*[A-Z])[A-Za-z\\d]{9,}$", message = "새 비밀번호는 8자 이상이어야 하고, 숫자와 대문자를 포함해야 합니다.")
    private String newPassword;

✔️ 배운점

• 정규식 쓰는 것이 어려웠다. 기존에 있는 클래스,메서드들을 잘 활용하자

---

📌 [Lv 2] N+1 문제

✅ N+1을 방지하는 기능을 찾고, @EntityGraph 기반 구현으로 수정

기존	fetch join을 사용해 연관된 데이터를 즉시 로딩
수정	JPA의 @EntityGraph로 리팩토링

---

📌 [Lv 3] 테스트코드 연습

✅ 1. 성공 케이스

✔️ 문제

---

✔️ 해결

• passwordEncoder.matches()
• 해싱 알고리즘을 비교할때는 비교 대상이 앞에, 해싱된 암호가 뒤에 와야한다

✅ 2. 예외 처리 성공 케이스

	✔️ 문제	✔️ 해결
1
2
3

• 알맞은 Exception으로 변경해 테스트 코드 실행시 성공하도록 수정했다

---

📌 Level 4. API 로깅

Interceptor와 AOP를 활용한 API 로깅

양이 방대해서 따로 썼다..🤯

✅ Interceptor 사용

• Interceptor를 사용해 요청 정보 사전 처리
• 인증 성공 시, 요청 시각과 URL을 로깅
• 어드민 인증 여부 확인

✔️ 작성한 코드

✅ AOP 사용

• @Around를 사용해 어드민 API 실행 전후에 로깅
• 로깅 내용: 요청한 사용자 ID, API 요청 시각, 요청 URL, 요청 본문 (RequestBody), 응답 본문 (ResponseBody)
• 요청/응답 바디는 JSON 형태로 기록
• Logger 클래스 활용

✔️ 어려웠던점 + 배운점

1. 본문을 JSON으로 불러올 것
   • request.getInputStream() 등으로는 한 번만 읽을 수 있음
   • Tomcat이 먼저 읽으면 바디는 null로 나옴
   • 해결책: ContentCachingRequestWrapper를 필터로 감싸 요청 바디를 캐싱

2. 왜 필터를 만들어야 하는가?
   • AOP나 일반 클래스에서는 이미 Tomcat이 읽은 뒤라 감싸도 무용지물
   • 필터로 가장 먼저 요청을 가로채고 감싸야 이후 AOP에서 꺼내 읽을 수 있음
   • 그래서 OncePerRequestFilter를 구현한 필터로 직접 감쌈

3. 캐싱해서 감싸져 있는지 instanceof로 확인
   • request가 내가 감싼 ContentCachingRequestWrapper 객체인지 체크해야 함
   • 그렇지 않으면 getContentAsByteArray() 호출 자체가 불가능
   • instanceof 검사 후 → 바이트 배열 → 문자열 변환 → 로깅

---

📖 나의 회고

• 필수단계만 착실히 하던 나에게 쉬어가는 느낌의 이번 필수 단계들..
  덕분에 시간이 남아서 도전단계까지 해보게 되었는데..! 정말 오래 걸렸다..^^
• 일단 다른 사람이 작성한 코드를 보는게 얼마나 힘든지 깨달았다.
  지금 강의 수준에 맞춰 작성한 코드를 주신걸 텐데도 내가 작성한게 아니다보니 어려웠다
• API 명세서의 중요성을 깨달았다
  레벨 4 구현을 위해 테스트 코드가 아닌 어플리케이션 전체를 실행하는데..
  요청시 뭐가 들어가야하는지 Path가 뭔지 컨트롤러 DTO 다 눌러보고 하나씩 확인하며 테스트했다
  나도 이런데 정말 엔지니어가 아닌 팀과 협업해야 한다면? API 명세서는 상세할 수록 좋은거구나~
• AOP를 알게되고 재밌어서(?) 홀린 듯 블로그를 뒤지며 따라해봤다..
  모든곳에 공통으로 적용해야할 작업이라던지 이런 부분들을 내가 커스텀해서 사용할 수 있을 것 같다
• 이번에도 시간을 잘 분배하지 못했다. 내가 게으르고 느린걸까 아님 할일이 너무 많은걸까?
  여기까지 오니 중간에 하차하신 분들이 꽤 보이는데.. 잠깐씩 부럽기도 했다
  이런 생각하지 않도록 꾸준하게 열심히 하자 !