Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dongjoon1251
approved these changes
Jul 1, 2025
| import org.springframework.boot.autoconfigure.SpringBootApplication; | ||
|
|
||
| @SpringBootApplication | ||
| @EnableAdminServer |
| finalizedBy jacocoTestReport | ||
| } | ||
|
|
||
| jacocoTestReport { |
Comment on lines
+96
to
+176
| /** | ||
| * 민감한 정보를 제거하고 파라미터를 문자열로 변환 | ||
| */ | ||
| private String sanitizeArguments(Object[] args) { | ||
| if (args == null || args.length == 0) { | ||
| return "없음"; | ||
| } | ||
|
|
||
| return Arrays.stream(args) | ||
| .map(arg -> { | ||
| if (arg == null) { | ||
| return "null"; | ||
| } | ||
|
|
||
| String argStr = arg.toString(); | ||
| String className = arg.getClass().getSimpleName(); | ||
|
|
||
| // 민감한 정보가 포함된 클래스들은 클래스명만 표시 | ||
| if (className.toLowerCase().contains("password") || | ||
| className.toLowerCase().contains("request") || | ||
| className.toLowerCase().contains("multipart")) { | ||
| return className; | ||
| } | ||
|
|
||
| // UUID는 앞 8자리만 표시 | ||
| if (arg instanceof UUID) { | ||
| return argStr.substring(0, 8) + "..."; | ||
| } | ||
|
|
||
| // 문자열이 너무 길면 자르기 | ||
| if (argStr.length() > 50) { | ||
| return argStr.substring(0, 50) + "..."; | ||
| } | ||
|
|
||
| return argStr; | ||
| }) | ||
| .reduce((a, b) -> a + ", " + b) | ||
| .orElse("없음"); | ||
| } | ||
|
|
||
| /** | ||
| * 주요 식별자 추출 (UUID, ID 등) | ||
| */ | ||
| private String extractIdentifier(Object[] args) { | ||
| if (args == null || args.length == 0) { | ||
| return "미지정"; | ||
| } | ||
|
|
||
| for (Object arg : args) { | ||
| if (arg instanceof UUID) { | ||
| return "ID:" + arg.toString().substring(0, 8) + "..."; | ||
| } | ||
| if (arg != null && arg.getClass().getSimpleName().toLowerCase().contains("request")) { | ||
| // Request 객체에서 username이나 email 등을 추출할 수 있음 | ||
| return "Request:" + arg.getClass().getSimpleName(); | ||
| } | ||
| } | ||
|
|
||
| return "ID:미지정"; | ||
| } | ||
|
|
||
|
|
||
| /** | ||
| * 메소드명으로부터 작업 유형 추출 | ||
| */ | ||
| private String getOperationType(String methodName) { | ||
| if (methodName.startsWith("create")) { | ||
| return "생성"; | ||
| } | ||
| if (methodName.startsWith("update")) { | ||
| return "수정"; | ||
| } | ||
| if (methodName.startsWith("delete")) { | ||
| return "삭제"; | ||
| } | ||
| if (methodName.startsWith("find")) { | ||
| return "조회"; | ||
| } | ||
| return "처리"; | ||
| } | ||
| } |
There was a problem hiding this comment.
이부분은 유틸성 메소드로 보입니다. 해당 로직을 테스트하기 용이하도록 별도 클래스로 분리해보면 어떨까요?
그리고 메소드 하나에 포함되는 라인수가 줄어들도록 더 작은 메소드들로 잘게 나누어보는 리팩토링을 진행해보면 어떨까요?
| @Aspect | ||
| @Component | ||
| public class LoggingAspect { | ||
|
|
There was a problem hiding this comment.
AOP를 이용하여 로깅과 관련된 공통 로직을 잘 분리해주셨습니다.
다만, 서비스별로 디버깅을 위해 봐야하는 특정 값들이 다를 수 있습니다. 서비스중에 디버깅에 도움이 될 만한 로깅을 일부 서비스에 추가로 남겨보면 어떨까요?
Comment on lines
+15
to
+16
| username: discodeit_user | ||
| password: discodeit1234 |
There was a problem hiding this comment.
production 환경에서는 해당 정보들이 노출되지 않도록 환경변수로 주입받도록 하면 좀더 안전해지지 않을까요?
Comment on lines
+50
to
+53
| ErrorCode errorCode = ErrorCode.VALIDATION_FAILED; | ||
| return ResponseEntity.badRequest() | ||
| .body(new ErrorResponse(Instant.now(), errorCode.getCode(), errorCode.getMessage(), | ||
| errors, e.getClass().getSimpleName(), errorCode.getHttpStatus().value())); |
There was a problem hiding this comment.
ErrorCode를 파라미터로 받아서 ErrorResponse를 생성하는 정적 생성자를 만들어보면 어떨까요?
이펙티브 자바에서는 생성자 대신 정적 생성자(정적 팩터리 메서드, static factory method)를 사용하라고 권장합니다. 그 이유와 주요 장점은 다음과 같습니다.
정적 팩터리 메서드의 장점
-
의미 있는 이름을 가질 수 있다
- 생성자는 클래스 이름과 같아야 하지만, 정적 팩터리 메서드는 이름을 자유롭게 정할 수 있어, 반환 객체의 특성을 명확하게 드러낼 수 있습니다.
-
호출할 때마다 새로운 객체를 생성하지 않아도 된다
- 내부적으로 캐싱된 객체를 반환하거나, 기존 객체를 재사용할 수 있어 불필요한 객체 생성을 줄이고 성능을 높일 수 있습니다.
-
반환 타입의 하위 타입 객체를 반환할 수 있다
- 반환 타입이 인터페이스나 추상 클래스라면, 실제 구현체를 숨기고 유연하게 객체를 반환할 수 있습니다. 예를 들어, 컬렉션 팩터리 메서드는 내부적으로 비공개 클래스를 반환하기도 합니다.
-
입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다
- 입력 값이나 상황에 따라 최적화된 하위 타입 객체를 반환할 수 있습니다. 클라이언트는 반환 객체의 구체 타입을 몰라도 되므로, API를 유연하게 설계할 수 있습니다.
-
반환할 객체의 클래스를 나중에 추가할 수 있다
- 정적 팩터리 메서드 작성 시점에 반환할 객체의 클래스가 없어도 되고, 추후에 추가할 수 있어 확장성이 높습니다.
단점
-
상속이 어렵다
- public 또는 protected 생성자가 없으면 하위 클래스를 만들 수 없습니다.
-
API에서 찾기 어렵다
- 생성자와 달리, 정적 팩터리 메서드는 명명 규칙이 필요하며, 문서화와 네이밍이 중요합니다.
대표적인 네이밍 패턴
- of: 여러 매개변수로 객체 생성
- from: 하나의 값을 변환해 객체 생성
- valueOf: 변환 또는 캐싱된 객체 반환
- getInstance: 인스턴스 반환(기존 객체일 수도 있음)
- newInstance: 항상 새로운 인스턴스 반환
- with: 일부 속성만 변경한 새 객체 생성
정리하면, 정적 팩터리 메서드는 생성자보다 더 많은 유연성과 명확성을 제공하므로, 객체 생성이 필요한 경우 먼저 정적 팩터리 메서드 사용을 고려하는 것이 이펙티브 자바의 권장 사항입니다.
| @Query("SELECT DISTINCT m FROM Message m JOIN FETCH m.channel WHERE m.channel.id = :channelId") | ||
| List<Message> findAllByChannelId(@Param("channelId") UUID channelId); | ||
| @Query("SELECT m FROM Message m " | ||
| + "LEFT JOIN FETCH m.author a " |
There was a problem hiding this comment.
fetch join이 동작하는지 테스트해볼 수 있을까요?
Hibernate.isInitialized(Object proxy) 는 Hibernate에서 프록시 객체나 지연 로딩(lazy loading) 컬렉션이 실제로 초기화(로딩)되었는지 여부를 확인하는 정적 메소드입니다. 이 메소드는 다음과 같은 상황에서 주로 사용됩니다.
- 지연 로딩(lazy loading) 필드나 컬렉션이 실제 DB에서 로딩되었는지(초기화되었는지) 확인할 때
- 세션이 닫힌 후 LazyInitializationException이 발생하지 않도록, 접근 전에 초기화 여부를 미리 체크할 때
동작 방식
- proxy 또는 persistent collection 객체가 전달되면,
- 이미 초기화(로딩)된 경우
true반환 - 아직 초기화되지 않은 경우
false반환 - 일반 객체(프록시나 컬렉션이 아닌 경우)는 항상
true반환
- 이미 초기화(로딩)된 경우
public static boolean isInitialized(java.lang.Object proxy)
Check if the proxy or persistent collection is initialized.
Returns: true if the argument is already initialized, or is not a proxy or collection.
예시 코드
if (!Hibernate.isInitialized(entity.getLazyCollection())) {
Hibernate.initialize(entity.getLazyCollection());
}- 위 예시처럼, 컬렉션이나 연관 엔티티가 초기화되지 않았다면
Hibernate.initialize()로 강제 초기화할 수 있습니다.
활용 시 주의사항
- Detached 상태(세션이 닫힌 후)에서는 초기화할 수 없으므로, 반드시 세션이 열려 있을 때 사용해야 합니다.
- 컬렉션의 경우, 컬렉션 객체 자체의 초기화 여부만 판단합니다. 컬렉션 내부의 요소까지 모두 초기화되었는지는 보장하지 않습니다.
요약
- **Hibernate.isInitialized(obj)**는 해당 객체(프록시, 컬렉션)가 실제로 DB에서 로딩되었는지 확인하는 메소드입니다.
- Lazy Loading 환경에서 안전하게 객체 접근이 필요한 경우, 이 메소드로 초기화 여부를 확인 후 사용하세요.
| User user = userRepository.findByUsername(username) | ||
| .orElseThrow( | ||
| () -> new UserNotFoundException(ErrorCode.USER_NOT_FOUND, | ||
| Map.of("로그인 시도한 사용자의 아이디 정보", username))); |
There was a problem hiding this comment.
상수로 쓰이는 문자열들은 private static 멤버변수로 분리해서 사용해보면 어떨까요? 아니면 해당 정보를 커스텀한 예외 클래스에서 갖게 하면 어떨까요?
Comment on lines
+53
to
+89
| UUID channelId = messageCreateRequest.channelId(); | ||
| UUID authorId = messageCreateRequest.authorId(); | ||
|
|
||
| Channel channel = channelRepository.findById(channelId) | ||
| .orElseThrow( | ||
| () -> new ChannelNotFoundException(ErrorCode.CHANNEL_NOT_FOUND, | ||
| Map.of("생성하고자 하는 메세지의 채널 ID", channelId))); | ||
| User author = userRepository.findById(authorId) | ||
| .orElseThrow( | ||
| () -> new UserNotFoundException(ErrorCode.USER_NOT_FOUND, | ||
| Map.of("생성하고자 하는 메세지의 유저 ID", authorId)) | ||
| ); | ||
|
|
||
| List<BinaryContent> attachments = binaryContentCreateRequests.stream() | ||
| .map(attachmentRequest -> { | ||
| String fileName = attachmentRequest.fileName(); | ||
| String contentType = attachmentRequest.contentType(); | ||
| byte[] bytes = attachmentRequest.bytes(); | ||
|
|
||
| BinaryContent binaryContent = new BinaryContent(fileName, (long) bytes.length, | ||
| contentType); | ||
| binaryContentRepository.save(binaryContent); | ||
| binaryContentStorage.put(binaryContent.getId(), bytes); | ||
| return binaryContent; | ||
| }) | ||
| .toList(); | ||
|
|
||
| String content = messageCreateRequest.content(); | ||
| Message message = new Message( | ||
| content, | ||
| channel, | ||
| author, | ||
| attachments | ||
| ); | ||
|
|
||
| messageRepository.save(message); | ||
| return messageMapper.toDto(message); |
There was a problem hiding this comment.
가독성을 높이기 위해서 메소드 내의 코드들을 더 작은 메소드들로 분리해보면 어떨까요?
Comment on lines
+9
to
+10
| # DB_CLOSE_DELAY: 테스트 종료 후 데이터베이스 연결 유지 시간 (음수 값은 연결 유지) | ||
| # DB_CLOSE_ON_EXIT: 프로그램 종료 시 데이터베이스 연결 닫기 여부 |
There was a problem hiding this comment.
사용하지 않는 코드는 과감히 삭제해주세요!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Spring Boot 고급 설정 및 테스트 구현
기본 요구사항
1. 프로파일 기반 설정 관리
프로파일 구성
application-dev.yaml,application-prod.yaml파일을 생성하세요.2. 로그 관리
기본 로깅 설정
@Slf4j어노테이션을 활용해 로깅을 쉽게 추가할 수 있도록 구성하세요.application.yaml에 기본 로깅 레벨을 설정하세요.info레벨로 설정합니다.debug, 운영 환경에서는info레벨로 설정합니다.Logback 설정
logback-spring.xml파일을 생성하세요.로그 출력 예시
로그 파일 관리
{프로젝트 루트}/.logs경로에 저장되도록 설정하세요.서비스 및 컨트롤러 로깅
ERROR,WARN,INFO,DEBUG3. 예외 처리 고도화
커스텀 예외 설계
com.sprint.mission.discodeit.exception[.{도메인}]ErrorCode Enum 클래스
ErrorCodeEnum 클래스를 통해 예외 코드명과 메시지를 정의하세요.아래는 예시입니다. 필요하다고 판단되는 다양한 코드를 정의하세요.
DiscodeitException 클래스
DiscodeitException클래스를 정의하세요.클래스 다이어그램
details는 예외 발생 상황에 대한 추가정보를 저장하기 위한 속성입니다.도메인별 예외 클래스
DiscodeitException을 상속하는 주요 도메인 별 메인 예외 클래스를 정의하세요.UserException,ChannelException등UserNotFoundException,UserAlreadyExistException등 필요한 예외를 정의하세요.기존 예외 대체
NoSuchElementExceptionIllegalArgumentExceptionErrorResponse 정의
ErrorResponse를 통해 일관된 예외 응답을 정의하세요.클래스 다이어그램
int status: HTTP 상태코드String exceptionType: 발생한 예외의 클래스 이름전역 예외 핸들러
ErrorResponse와@RestControllerAdvice를 활용해 예외를 처리하는 예외 핸들러를 구현하세요.ErrorResponse)을 가져야 합니다.4. 유효성 검사
Spring Validation 설정
@NotNull,@NotBlank,@Size,@Email등@Valid를 사용해 요청 데이터를 검증하세요.MethodArgumentNotValidException을 전역 예외 핸들러에서 처리하세요.5. Actuator
Actuator 설정
health,info,metrics,loggers애플리케이션 정보 설정
Actuator 확인
/actuator/info/actuator/metrics/actuator/health/actuator/loggers테스트 구현
1. 단위 테스트
서비스 레이어 테스트
UserService: create, update, delete 메소드ChannelService: create(PUBLIC, PRIVATE), update, delete, findByUserId 메소드MessageService: create, update, delete, findByChannelId 메소드2. 슬라이스 테스트
레포지토리 테스트
@DataJpaTest를 활용해 테스트를 구현하세요.테스트 환경 구성
application-test.yaml을 생성하세요.@EnableJpaAuditing을 추가하세요.레포지토리 테스트 케이스
컨트롤러 테스트
@WebMvcTest를 활용해 테스트를 구현하세요.@Import를 활용해 추가하세요.예시
MockMvc를 활용해 컨트롤러를 테스트하세요.3. 통합 테스트
통합 테스트 환경 구성
@SpringBootTest를 활용해 Spring 애플리케이션 컨텍스트를 로드하세요.통합 테스트 케이스
@Transactional을 활용해 독립적으로 실행하세요.심화 요구사항
1. MDC를 활용한 로깅 고도화
MDC 인터셉터 구현
MDCLoggingInterceptorcom.**.discodeit.configDiscodeit-Request-ID인터셉터 등록
WebMvcConfigurer를 통해MDCLoggingInterceptor를 등록하세요.WebMvcConfigcom.**.discodeit.configLogback MDC 패턴
로그 출력 예시
2. Spring Boot Admin을 활용한 메트릭 가시화
Admin 서버 모듈 생성
Admin 서버 설정
admin모듈의 메인 클래스에@EnableAdminServer어노테이션을 추가하고, 서버는 9090번 포트로 설정합니다.Admin 서버 확인
admin서버 실행 후 localhost:9090/applications 에 접속해봅니다.Admin Client 설정
Admin 대시보드 확인
3. 테스트 커버리지 관리
JaCoCo 플러그인 설정
커버리지 분석
build/reports/jacoco경로에서 확인할 수 있습니다.com.sprint.mission.discodeit.service.basic패키지에 대해서 60% 이상의 코드 커버리지를 달성하세요.체크리스트 요약
기본 요구사항 체크리스트
테스트 구현 체크리스트
심화 요구사항 체크리스트
참고사항
src/main/resources디렉토리에 위치해야 합니다.src/test/resources디렉토리에 위치해야 합니다.스크린샷