feat: 유저의 멘토 지원서 신청 이력 조회 기능 추가 #603
Conversation
* refactor: long 타입을 Long 으로 수정
* test: MentorApplicationFixtureBuilder 에 rejectedReason 필드 및 빌더 메서드 추가
sukangpunch
requested review from
Gyuhyeok99,
Hexeong,
JAEHEE25,
lsy1307,
whqtker and
wibaek
as code owners
Walkthrough
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java (1)
79-85: 엔드포인트 경로 설계 개선을 고려해보세요.기능은 정상적으로 작동하지만, 현재 경로 구조가 RESTful 설계 관점에서 다소 혼란스러울 수 있습니다.
현재:
/admin/mentor-applications/{site-user-id}/mentor-application-history
- 경로 상
mentor-applications리소스 하위에site-user-id가 위치하여, 특정 멘토 신청서의 하위 리소스처럼 보입니다.- 실제로는 특정 사용자의 전체 멘토 지원서 이력을 조회하는 기능입니다.
다음과 같은 대안을 고려해보세요:
/admin/site-users/{site-user-id}/mentor-application-history(리소스 중심)/admin/mentor-application-history/{site-user-id}(기능 중심)이는 설계 선호도의 문제이며, 팀 내 REST API 설계 가이드라인이 있다면 그에 따라 결정하시면 됩니다.
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (1)
91-110: 지원서 이력 조회 로직이 잘 구현되었으나, ID 사용의 일관성 개선이 필요합니다.전체적인 로직은 명확하고 올바르게 구현되었습니다:
- ✅ 유저 존재 여부 검증 (lines 92-93)
- ✅ 총 지원서 개수 조회 (line 95)
- ✅ 최신 5개 지원서 조회 (line 97)
- ✅ 지원서 순번 계산 로직 (
totalCount - index)이 정확합니다다만, line 95와 97에서 사용하는 ID가 일관되지 않습니다:
- Line 95:
siteUserId(파라미터, Long 타입) 사용- Line 97:
siteUser.getId()(엔티티의 ID, long 타입) 사용Line 92에서 이미
SiteUser엔티티를 조회했으므로, 두 repository 호출 모두siteUser.getId()를 사용하는 것이 더 일관되고 명확합니다.🔎 일관성 개선을 위한 제안
@Transactional(readOnly = true) public List<MentorApplicationHistoryResponse> findMentorApplicationHistory(Long siteUserId) { SiteUser siteUser = siteUserRepository.findById(siteUserId) .orElseThrow(() -> new CustomException(USER_NOT_FOUND)); - long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId); + long totalCount = mentorApplicationRepository.countBySiteUserId(siteUser.getId()); List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId()); return IntStream.range(0, mentorApplications.size()) .mapToObj(index -> { MentorApplication app = mentorApplications.get(index); return new MentorApplicationHistoryResponse( app.getId(), app.getMentorApplicationStatus(), app.getRejectedReason(), app.getCreatedAt(), (int) totalCount - index ); }).toList(); }
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.javasrc/main/java/com/example/solidconnection/mentor/repository/MentorApplicationRepository.javasrc/main/resources/secretsrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.javasrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.javasrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🧬 Code graph analysis (1)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationResponse.java (1)
MentorApplicationResponse(7-20)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (9)
src/main/resources/secret (1)
1-1: 서브모듈 업데이트 - 상세 코드 리뷰 불가제공된 파일이 서브모듈 커밋 포인터 업데이트만 포함하고 있으므로, PR의 핵심 구현 코드에 대한 상세한 코드 리뷰를 진행할 수 없습니다.
다음 파일들이 리뷰에 필요합니다:
Controller 계층
AdminMentorApplicationController: 멘토 지원서 이력 조회 엔드포인트 구현Service 계층
AdminMentorApplicationService: 사이트 유저 유효성 검사, 총 신청 건수 조회, 상위 5개 항목 조회, DTO 매핑 로직Repository 계층
MentorApplicationRepository:findTop5BySiteUserIdOrderByCreatedAtDesc(),countBySiteUserId()쿼리 메서드DTO & Model
MentorApplicationHistoryResponse: 응답 구조 및 필드 정의테스트
AdminMentorApplicationServiceTest: 정렬, 제한, 빈 이력, 필드 검증, 존재하지 않는 유저 처리이 실제 구현 파일들이 포함된 전체 코드 리뷰를 요청드립니다.
src/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.java (1)
21-21: 거절 사유 상수 추가가 깔끔합니다.테스트에서 사용할 거절 사유를 상수로 정의하여 fixture에서 일관되게 사용하고 있어 좋습니다. 테스트 데이터의 일관성이 확보되었습니다.
Also applies to: 68-68
src/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.java (1)
24-24: Fixture 빌더 확장이 잘 구현되었습니다.
rejectedReason필드와 빌더 메서드가 기존 패턴과 일관되게 추가되었고,create()메서드에서 null 체크 후 reflection으로 값을 설정하는 방식도 적절합니다. 테스트 목적의 reflection 사용은 합당합니다.Also applies to: 62-65, 88-90
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
6-12: 이력 조회용 DTO 설계가 간결하고 적절합니다.멘토 지원서 이력 조회에 필요한 핵심 정보만 포함하여 깔끔합니다.
applicationOrder필드를 통해 전체 지원 순서를 파악할 수 있도록 한 점이 좋습니다. 기존MentorApplicationResponse보다 단순화된 구조로 용도에 맞게 설계되었습니다.src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java (1)
79-85: 사용자 존재 여부 검증이 서비스 레이어에서 처리되고 있습니다.컨트롤러에서 별도로
siteUserId검증을 하지 않지만, 테스트 코드(Line 611-613)를 확인한 결과 서비스 레이어에서USER_NOT_FOUND예외를 던지고 있어 적절하게 처리되고 있습니다.src/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.java (1)
515-615: 멘토 지원서 이력 조회 테스트가 매우 포괄적입니다.새로운 이력 조회 기능에 대한 테스트가 다음 시나리오를 모두 커버하고 있어 훌륭합니다:
기본 이력 조회 및 정렬 검증 (Lines 519-540)
- 최신 생성 내림차순 정렬 확인
- applicationOrder 필드 검증
5개 제한 검증 (Lines 543-568)
- 7개 생성 시 최신 5개만 반환되는지 확인
빈 이력 처리 (Lines 571-580)
- 지원서가 없을 때 빈 리스트 반환
응답 필드 검증 (Lines 583-603)
- 상태값과 거절 사유가 올바르게 포함되는지 확인
에러 처리 (Lines 606-614)
- 존재하지 않는 사용자 조회 시 예외 발생 검증
applicationOrder가 반환된 목록 내 순위가 아닌 전체 지원 이력에서의 순서를 나타내는 점도 잘 검증되었습니다.src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (2)
33-33: 새로운 의존성 주입이 적절합니다.유저 존재 여부 검증을 위해
SiteUserRepository가 추가되었습니다. 새로 추가된 히스토리 조회 기능에 필요한 의존성이며, 기존 패턴과 일관되게 구성되어 있습니다.
52-55: 파라미터 타입 변경은 호환성 문제가 없습니다.검토 결과:
메서드 구현:
rejectMentorApplication(Long mentorApplicationId, ...)파라미터는 이미 박싱된Long타입입니다.호출 지점 확인:
- 컨트롤러에서는
@PathVariable("mentor-application-id") Long mentorApplicationId로 받은Long타입을 그대로 전달합니다.- 테스트에서는 원시
long타입을 사용하나, Java의 오토박싱이 자동으로Long으로 변환합니다.결론: 모든 호출자가 이미 호환되어 있으므로 추가 조정은 필요하지 않습니다.
src/main/java/com/example/solidconnection/mentor/repository/MentorApplicationRepository.java (1)
18-20: 새로운 쿼리 메서드 구현이 완벽합니다.추가된 두 메서드는 Spring Data JPA 3.1.5의 query derivation 규칙을 정확하게 따르고 있습니다:
findTop5BySiteUserIdOrderByCreatedAtDesc
- 생성일 기준 내림차순으로 상위 5개를 조회하는 명확한 의도
countBySiteUserId
- 특정 유저의 지원서 총 개수를 카운트
기존 메서드들과 동일하게 primitive
long타입을 사용하여 코드의 일관성도 잘 유지되고 있습니다.
whqtker
left a comment
whqtker
left a comment
There was a problem hiding this comment.
고생하셨습니다 ~! 역시 어드민 담당하신 분 리뷰까지 받고 머지하면 좋을 거 같습니다 !
| return ResponseEntity.ok().build(); | ||
| } | ||
|
|
||
| @GetMapping("/{site-user-id}/mentor-application-history") |
There was a problem hiding this comment.
엔드포인트 이름이 조금 긴 것 같습니다 ! 어차피 prefix가 /admin/mentor-applications이므로 mentor-application-history 대신 history를 사용하면 어떨까요 ?
| void 응답에_지원서_상태와_거절_사유가_포함된다() { | ||
| // given | ||
| SiteUser user = siteUserFixture.사용자(); | ||
| University university = universityFixture.메이지_대학(); |
There was a problem hiding this comment.
현재 사용자, 메이지 대학 생성이 중복되고 있는데 BeforeEach 에서 생성하도록 해도 좋을 거 같습니다.
* test: 멘토 지원서 이력 조회 에서 user와 university 재사용 * refactor: 긴 uri 를 짧게 수정
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java (1)
79-85: 엔드포인트 구현이 깔끔합니다!이전 리뷰에서 요청한 URI 단축이 반영되어
/{site-user-id}/history로 간결하게 구성되었습니다. GET 메서드를 사용한 조회 작업이고, 서비스 레이어로 적절히 위임하고 있습니다.다만 선택적으로 고려해볼 아키텍처 관점의 의견을 드립니다: 현재 경로는
/admin/mentor-applications/{site-user-id}/history인데, 다른 엔드포인트들은 모두{mentor-application-id}를 사용하고 있어 리소스 타입이 혼재되어 있습니다.대안으로는:
/admin/site-users/{site-user-id}/mentor-application-history/admin/mentor-applications/history?siteUserId={id}(쿼리 파라미터 방식)현재 방식도 멘토 지원서 관련 관리 기능을 한 곳에 모은다는 장점이 있으니, 팀의 API 설계 방향에 따라 선택하시면 됩니다.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (2)
src/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.java (2)
68-69: 이전 리뷰 피드백이 잘 반영되었습니다!사용자와 대학 픽스처를
BeforeEach에서 생성하도록 리팩토링하여 테스트 코드의 중복을 제거했습니다. 멘토 지원서 이력 조회 테스트들에서 이 공통 픽스처를 재사용할 수 있게 되었습니다.Also applies to: 92-94
520-615: 멘토 지원서 이력 조회 테스트가 매우 잘 작성되었습니다!다음 항목들을 체계적으로 검증하고 있습니다:
- 정렬 순서: 생성일 기준 내림차순으로 조회되는지 확인 (525-544라인)
- 개수 제한: 5개를 초과할 경우 최신 5개만 조회되는지 확인 (547-570라인)
- 빈 이력 처리: 지원서가 없는 경우 빈 목록 반환 확인 (573-582라인)
- 응답 필드 검증: 상태, 거절 사유, applicationOrder 필드가 올바르게 포함되는지 확인 (585-603라인)
- 예외 처리: 존재하지 않는 사용자 조회 시 적절한 예외 발생 확인 (606-614라인)
테스트 커버리지가 충분하며, 이슈 #600의 모든 요구사항을 검증하고 있습니다.
Gyuhyeok99
left a comment
Gyuhyeok99
left a comment
There was a problem hiding this comment.
저는 5개만 잘라서 7, 6, 5, 4, 3으로 보이는 게 좀 어색한 거 같아서 그냥 page나 slice 쓰는 게 어떨가 조심스레 의견드립니다..!
고생 많으셨습니다~~
There was a problem hiding this comment.
이 시크릿 해시코드는 현재 최신버전과 다른 거 같습니다.
추가로 현재 yml쪽은 수정하시지 않은 거 같은데 제거 부탁드려요~
There was a problem hiding this comment.
서브모듈 어렵네요... 바로 되돌리겠습니다
| MentorApplicationStatus mentorApplicationStatus, | ||
| String rejectedReason, | ||
| ZonedDateTime createdAt, | ||
| int applicationOrder |
There was a problem hiding this comment.
id가 1, 2, 3, 4, 5, 6, 7로 생성되었으면
7, 6, 5, 4, 3으로 응답되는 게 맞는거죠?
차라리 slice나 page로 5개씩 조회해오는 게 나을 거 같은데 어떤가요?
There was a problem hiding this comment.
7 6 5 4 3 으로 응답되는게 맞습니다!
디자인으로 봤을 때, 페이징 조회를 염두에 둔 건지 애매해서 한번 제대로 여쭈어 봐야겠네요!
| ); | ||
| }).toList(); | ||
| } | ||
| } |
There was a problem hiding this comment.
여기 pr과 관련없지만 보여가지고 ㅎㅎ.. 개행 하나만 지워주실 수 있나요
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (3)
4-4: 새로운 기능 구현을 위한 import 추가가 적절합니다.추가된 import들이 모두 새로운 메서드 구현에서 사용되고 있습니다.
Also applies to: 7-7, 15-16, 19-20
33-33: SiteUserRepository 의존성 추가가 적절합니다.사용자 존재 여부 검증을 위해 필요한 의존성입니다.
52-53: 파라미터 타입을 Long으로 변경하여 일관성이 개선되었습니다.다른 메서드들(예:
approveMentorApplication)과 동일하게 wrapper 타입을 사용하여 코드 일관성이 향상되었습니다.
| long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId); | ||
| List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId()); |
There was a problem hiding this comment.
파라미터 사용의 일관성을 개선해주세요.
1️⃣ 95번 라인에서는 siteUserId를 직접 사용하고 있습니다.
2️⃣ 96번 라인에서는 siteUser.getId()를 사용하고 있습니다.
두 라인 모두 동일한 값을 참조하므로, 일관성을 위해 같은 방식으로 사용하는 것이 좋습니다.
🔎 일관성 개선을 위한 제안
long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId);
- List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId());
+ List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUserId);🤖 Prompt for AI Agents
In
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
around lines 95-96, the code uses siteUserId on line 95 but siteUser.getId() on
line 96; make the parameter usage consistent by using the same variable for both
calls (replace siteUser.getId() with siteUserId or vice versa); update the
second repository call to use siteUserId so both lines reference the same
identifier consistently.
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
Show resolved
Hide resolved
* refactor: 개행 지우기
sukangpunch
force-pushed
the
feat/600-admin-mentor-application-history
branch
from
336e7f0 to
1d44b1e
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (1)
90-109: 멘토 지원 이력 조회 로직이 잘 구현되었습니다!이전 리뷰에서 제기된 오버플로우 문제가
applicationOrder를long타입으로 변경하여 완전히 해결되었습니다.구현 내용을 정리하면:
- 사용자 검증: 존재하지 않는 사용자에 대해
USER_NOT_FOUND예외 처리- 전체 지원 횟수 조회: 전체 카운트를 통해 정확한 차수 계산
- 최신 5개 조회: 생성 시간 기준 내림차순 정렬
- 차수 계산:
totalCount - index로 정확한 N차 값 산출다만, 사용자 존재를 이미 검증했으므로 lines 95-96에서
siteUser.getId()대신siteUserId를 직접 사용하면 미세하게 더 간결합니다.♻️ 파라미터 직접 사용으로 간소화 (선택사항)
- long totalCount = mentorApplicationRepository.countBySiteUserId(siteUser.getId()); - List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId()); + long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId); + List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUserId);
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🔇 Additional comments (2)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
6-12: 레코드 구조가 깔끔하고 명확합니다!멘토 지원 이력 응답 DTO가 필요한 모든 정보를 잘 담고 있습니다. 특히
applicationOrder를long타입으로 정의하여 이전 리뷰에서 제기된 오버플로우 가능성을 근본적으로 해결한 점이 좋습니다.src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (1)
33-33: 사용자 검증을 위한 의존성 추가가 적절합니다.멘토 지원 이력 조회 시 사용자 존재 여부를 확인하기 위해
SiteUserRepository가 필요하므로 의존성 추가가 타당합니다.
- 순서를 나타내고, 해당 값이 21억을 넘길 수 없다 판단하여 더 적합한 int 자료형으로 복구 * test: long type 을 기대하던 테스트 에러 해결
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
6-14: 전반적으로 잘 구현되었습니다!레코드 구조가 명확하고 필드 타입도 적절합니다. 다만
applicationOrder필드의 의미(예: "N차 멘토 신청"의 N 값)를 Javadoc으로 문서화하면 코드 가독성이 더욱 향상될 것입니다.📝 Javadoc 추가 예시
+/** + * 멘토 지원서 이력 조회 응답 + * + * @param id 지원서 ID + * @param mentorApplicationStatus 지원서 상태 + * @param rejectedReason 거절 사유 (거절된 경우에만 존재) + * @param createdAt 지원서 생성 시간 + * @param applicationOrder 지원 순서 (N차 멘토 신청의 N 값) + */ public record MentorApplicationHistoryResponse( long id, MentorApplicationStatus mentorApplicationStatus, String rejectedReason, ZonedDateTime createdAt, int applicationOrder ) {src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (1)
95-96: 파라미터 사용을 더 간결하게 개선할 수 있습니다.현재 두 라인 모두
siteUser.getId()를 사용하여 일관성은 확보되었습니다. 다만 메서드 파라미터로 이미siteUserId를 받았고 존재 여부도 검증 완료했으므로,siteUser.getId()대신siteUserId를 직접 사용하면 코드가 더 간결해집니다.♻️ 간결한 코드로 개선
- long totalCount = mentorApplicationRepository.countBySiteUserId(siteUser.getId()); - List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId()); + long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId); + List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUserId);
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (3)
33-33: 의존성 추가가 적절합니다.사용자 존재 여부 검증을 위해 필요한 의존성이 올바르게 추가되었습니다.
90-93: 사용자 검증 로직이 잘 구현되었습니다.존재하지 않는 사용자에 대한 방어적 검증이 적절하게 구현되어 있으며, readOnly 트랜잭션 설정도 올바릅니다.
98-108: 매핑 로직이 정확하게 구현되었습니다!
IntStream을 활용한 매핑이 깔끔하고,applicationOrder계산 로직도 요구사항에 정확히 부합합니다.계산 예시:
1️⃣ 전체 지원서 7개, 최신 5개 조회 시
2️⃣ 결과: 7차 → 6차 → 5차 → 4차 → 3차이는 생성 시간 기준 내림차순으로 정렬된 지원서에 올바른 순서 번호를 부여합니다.
4 participants
관련 이슈
작업 내용
특이 사항
MentorApplicationHistoryResponse 의 applicationOrder 부분은
"N차 멘토 신청" 에서 N 부분을 나타내었습니다.
리뷰 요구사항 (선택)
현재 데이터를 조회 할 때, 지원서 생성 시간 기준으로 내림차순 조회 및 5개 limit 을 걸고 조회를 합니다.
생성 시간 기준 내림차순으로 조회해서 가져오는 부분은 스스로 판단한 부분인데 혹시 더 좋은 방법이나, 해당 방식에 어색함이 있다면 수정하거나 다시 명확한 기획을 요청 드리겠습니다!