Feat/긴급도 레벨 제거 및 난이도 레벨 추가#20
Hidden character warning
Conversation
There was a problem hiding this comment.
Pull request overview
이 PR은 일정 관리 시스템에서 "긴급도(urgency)" 개념을 "난이도(difficulty)"로 변경하는 작업입니다. 기존 1-9 범위의 긴급도 레벨을 피보나치 수열 기반의 난이도 레벨(1, 2, 3, 5, 8, 13, 21)로 교체합니다.
주요 변경 사항:
- 도메인 모델에서 긴급도 필드 및 검증 로직을 난이도로 변경하고 피보나치 수열 검증 추가
- API 요청/응답 DTO에서 urgency 필드를 difficulty로 변경
- 테스트 코드 및 문서(README)의 관련 내용 업데이트
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/main/java/me/gg/pinit/pinittask/domain/schedule/vo/ImportanceConstraint.java | urgency_level 컬럼을 difficulty_level로 변경하고, 피보나치 수열 기반의 난이도 검증 로직 추가 |
| src/main/java/me/gg/pinit/pinittask/domain/schedule/model/Schedule.java | changeUrgency 메서드를 changeDifficulty로 변경하여 난이도 변경 기능 제공 |
| src/main/java/me/gg/pinit/pinittask/domain/schedule/patch/SchedulePatch.java | urgency 필드를 difficulty로 변경하여 패치 객체에 반영 |
| src/main/java/me/gg/pinit/pinittask/application/schedule/dto/ScheduleDependencyAdjustCommand.java | urgency 파라미터를 difficulty로 변경하고 필드에 final 수식어 추가하여 불변성 강화 |
| src/main/java/me/gg/pinit/pinittask/interfaces/dto/ScheduleRequest.java | urgency 요청 필드를 difficulty로 변경하고 API 스키마 문서 업데이트 |
| src/main/java/me/gg/pinit/pinittask/interfaces/dto/ScheduleResponse.java | urgency 응답 필드를 difficulty로 변경하여 클라이언트에 난이도 정보 제공 |
| src/test/java/me/gg/pinit/pinittask/application/schedule/service/ScheduleAdjustmentServiceTest.java | 테스트에서 urgency 검증을 difficulty로 변경 |
| README.md | 프로젝트 문서에서 긴급도 언급을 난이도로 업데이트 |
| @NotNull | ||
| @Min(1) | ||
| @Max(9) | ||
| @Schema(description = "긴급도 (1~9)", example = "7") | ||
| Integer urgency, | ||
| @Schema(description = "난이도 (21 이하의 피보나치 수)", example = "3") | ||
| Integer difficulty, |
There was a problem hiding this comment.
(1) 문제점: 난이도 필드의 검증 어노테이션이 실제 도메인 규칙과 일치하지 않습니다. @Min(1), @Max(9)로 설정되어 있지만, ImportanceConstraint는 피보나치 수열(1, 2, 3, 5, 8, 13, 21)만 허용합니다.
(2) 영향: 21이 유효한 값인데 @Max(9)로 인해 거부되고, 4, 6, 7, 9 같은 유효하지 않은 값들이 Bean Validation을 통과할 수 있습니다. API 계층의 검증과 도메인 계층의 검증이 불일치합니다.
(3) 수정 제안: 커스텀 Validator를 작성하여 피보나치 수열 값만 허용하도록 하거나, Bean Validation을 제거하고 도메인 계층에서만 검증하도록 수정해야 합니다.
| private void validateDifficultyLevel(int difficulty) { | ||
| if (!VALID_DIFFICULTY_LEVELS.contains(difficulty)) { | ||
| throw new IllegalArgumentException("난이도 레벨은 1, 2, 3, 5, 8, 13, 21 중 하나여야 합니다."); | ||
| } | ||
| } |
There was a problem hiding this comment.
(1) 문제점: 새로운 난이도 검증 로직(validateDifficultyLevel)과 changeDifficultyLevel 메서드에 대한 테스트 커버리지가 없습니다.
(2) 영향: 피보나치 수열 검증이 제대로 작동하는지 확인할 수 없으며, 유효하지 않은 값(예: 4, 6, 7, 9 등)이 입력되었을 때 예외가 올바르게 발생하는지 검증되지 않습니다.
(3) 수정 제안: 다음 테스트 케이스를 추가해야 합니다:
- 유효한 피보나치 수(1, 2, 3, 5, 8, 13, 21) 입력 시 성공하는 테스트
- 유효하지 않은 값(4, 6, 7, 9, 10 등) 입력 시 IllegalArgumentException이 발생하는 테스트
changeDifficultyLevel메서드의 정상 동작 테스트
| public ImportanceConstraint(int importance, int difficulty) { | ||
| this.importance = importance; | ||
| this.urgency = urgency; | ||
| this.difficulty = difficulty; | ||
| } |
There was a problem hiding this comment.
(1) 문제점: 생성자에서 난이도 값에 대한 유효성 검증이 누락되어 있습니다. changeDifficultyLevel 메서드에서는 validateDifficultyLevel을 호출하지만, 생성자에서는 호출하지 않습니다.
(2) 영향: 생성자를 통해 유효하지 않은 난이도 값(예: 4, 6, 7 등)으로 객체를 생성할 수 있어 데이터 무결성이 깨질 수 있습니다. ScheduleDependencyAdjustCommand.getTemporalSchedule()에서 이 생성자를 사용하므로, API를 통해 잘못된 값이 입력될 수 있습니다.
(3) 수정 제안: 생성자에서도 중요도와 난이도 값의 유효성을 검증하도록 수정해야 합니다.
변경된 점