[ TIL ] 주특기 심화_Day 5

오늘 한 공부 🧐 

• 개인 과제 3단계 끝내기
• 개인 과제 4단계 도전
• 스탠다드반 트랜잭션 세션 복습
• TIL 블로그 작성

 

오늘 얻은 내용 정리 ✏️ 

Lv 3. 추가 기능 개선

먼저 주어진 GitHub Repository로 들어가서 Fork 기능을 활용해서 내 Repository로 복사해서 가져온다.

1. 코드 개선 퀴즈: Early Return

조건에 맞지 않는 경우 즉시 리턴해서, 불필요한 로직의 실행을 방지하고 성능을 향상시킨다.

• AuthService 클래스 안에 있는 signup( ) 메서드 내의 코드 일부의 위치를 리팩토링해서 passwordEncoder의 encode() 동작이 불필요하게 일어나지 않게 코드를 개선할 수 있었다.

if (userRepository.existsByEmail(signupRequest.getEmail())) {
    throw new InvalidRequestException("이미 존재하는 이메일입니다.");
}

2. 리팩토링 퀴즈: 불필요한 if-else 피하기

복잡한 if-else 구조는 코드의 가독성을 떨어뜨리고 유지보수를 어렵게 만든다. 불필요한 else 블록을 없애 코드를 간결하게 한다.

• WeatherClient 클래스에 있는 getTodayWeather() 메서드 내의 if-else문을 리팩토링해서 불필요한 if-else문을 피할 수 있다.

WeatherDto[] weatherArray = responseEntity.getBody(); 
if (!HttpStatus.OK.equals(responseEntity.getStatusCode())) { 
	throw new ServerException("날씨 데이터를 가져오는데 실패했습니다. 상태 코드: " + responseEntity.getStatusCode());
} else { 
	if (weatherArray == null || weatherArray.length == 0) { 
		throw new ServerException("날씨 데이터가 없습니다."); 
    } 
}

• 수정 후

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

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

3. 코드 클린업: 불필요한 주석 제거, 코드 포맷팅, 일관된 네이밍 컨벤션 적용

• 불필요한 주석 제거
  • 코드가 명확하게 이해될 수 있도록 불필요한 주석은 제거합니다.
    • 주석의 추상화 수준과 코드의 추상화 수준의 동일한 경우
    • 주석이 코드의 내용을 중복하는 경우 제거
    • 설명이 불명확하거나 혼란스러운 주석 삭제
    • 코드의 동작을 설명하기보다는 '왜' 해당 코드를 작성했는지를 설명하는 주석은 남김 → 주석을 통한 의사소통을 위해 사용한다.
• 코드 포맷팅
  • 일관된 코드 스타일을 유지하기 위해 코드 포맷팅을 적용합니다.
    • 각 클래스, 메서드, 변수에 대한 적절한 공백 및 줄바꿈 적용
    • 2칸 또는 4칸의 스페이스(탭) 사용, 팀 내 합의된 방식에 따름
    • 괄호 {}는 다음 줄에 위치시키거나 같은 줄에 위치시키는 규칙을 팀 내에서 정하고 적용
    • 한 줄의 최대 길이는 80~120자로 제한
    • 메서드 인자와 파라미터 목록 간의 공백 적용
    • 코드 정렬 및 정리(예: import 문 정리)
    • Hint! google-java-formatter, ktlint 와 같은 린트도 찾아서 활용해보세요!
• 일관된 네이밍 컨벤션 적용
  • 변수명, 메서드명, 클래스명 등 모든 네이밍에 대해 일관된 규칙을 적용합니다.
    • 클래스 이름은 대문자로 시작하는 파스칼 케이스(PascalCase) 사용
    • 메서드 이름 및 변수 이름은 소문자로 시작하는 카멜 케이스(camelCase) 사용
    • 상수 이름은 모두 대문자로 작성하고 단어 사이에 언더스코어(_) 사용 (예: MAX_LENGTH)
    • 이름이 그 행위를 충분히 설명하고 있는지? 네이밍은 의미를 명확히 전달하도록 작성 (예: getUserById는 findUserById로 변경 가능)
    • 접두사 또는 접미사를 통한 일관성 유지 (예: DTO는 UserDTO, Service는 UserService 등)

4. 중복 코드 제거: 반복적으로 사용되는 코드의 재사용성 향상

• 중복 코드 식별
  • 프로젝트 내에서 반복적으로 사용되는 코드를 찾아냅니다.
    • 유사한 로직이 여러 곳에서 사용되는지 확인
    • 동일한 기능을 수행하는 코드 블록을 검색
    • 메서드 내의 반복적인 코드나 클래스 간의 중복 코드 파악
• 메서드로 추출
  • 중복된 코드를 유틸리티 메서드로 추출하여 재사용성을 높입니다.
    • 중복 코드의 기능을 분석하고, 재사용 가능한 메서드를 생성
    • 메서드 이름은 기능을 명확히 전달할 수 있도록 작성
    • 메서드는 단일 책임 원칙(SRP)을 준수해야 하며, 한 가지 기능만 수행하도록 구현

Lv 4. N+1 문제 개선하기

차이점을 찾고 적용하는 이유까지 생각해보기

Fetch join

• SQL Join의 종류는 아니다.
• JPQL에서 성능 최적화를 위해 제공하는 기능이다.
• 연관된 Entity나 컬렉션을 SQL 한 번에 함께 조회하는 기능이다.
• join fetch 를 사용한다.
• [LEFT [OUTER] | INNER] JOIN FETCH 조인경로
• 예시
  • JPQL: SELECT m FROM Member m JOIN FETCH m.team
  • SQL: SELECT m.*, t.* FROM Member m INNER JOIN TEAM t ON m.team_id = t.id
• Fetch Join를 써야하는 이유
  • Fetch Join을 쓸 경우, join fetch 로 설정된 연관관계 엔티티의 정보까지 한 번의 쿼리로 다 가져오게 된다. (프록시 객체로 두지 않는다.)
  • 모든 팀 정보들이 한번에 조회되고, 영속성 컨텍스트 1차 캐시에 저장되어 쿼리 전송 없이 바로 활용될 수 있다.

@EntityGraph

스탠다드반 트랜잭션 세션 복습

 

오늘 하루 정리 ✏️

 

내일 계획 ⏰

• 개인 과제 4단계 끝내기
• 스탠다드반 트랜잭션 블로그 정리
• TIL 블로그 작성

+추가 계획이 생길 수도 있습니다~_~