-
Notifications
You must be signed in to change notification settings - Fork 8
refactor: 인증 정보 argumentResolver가 long siteUserId를 주입하도록 #396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: 인증 정보 argumentResolver가 long siteUserId를 주입하도록 #396
Conversation
- 추가로, 반복되던 mocking 으로 가독성을 해치던 것을 해결
|
""" Walkthrough
Estimated code review effort4 (~90분)
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ 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)
✨ 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/com/example/solidconnection/siteuser/service/MyPageService.java (1)
38-39: 💡 코드 중복 개선 제안을 고려해보세요현재
siteUserRepository.findById().orElseThrow(() -> new CustomException(USER_NOT_FOUND))패턴이 반복되고 있습니다. PR 목표에서 언급한findByIdOrThrow()디폴트 메서드 추가를 통해 이런 중복을 줄일 수 있겠습니다.// SiteUserRepository에 추가할 디폴트 메서드 예시 default SiteUser findByIdOrThrow(Long id) { return findById(id).orElseThrow(() -> new CustomException(USER_NOT_FOUND)); }Also applies to: 49-50
src/main/java/com/example/solidconnection/application/service/ApplicationQueryService.java (1)
4-4: 서비스 계층 리팩토링이 올바르게 구현되었습니다.다음 변경사항들이 정확히 적용되었습니다:
- 메서드 시그니처에서
SiteUser파라미터를long siteUserId로 변경SiteUserRepository의존성 추가 및USER_NOT_FOUND에러 코드 임포트- 각 메서드에서 사용자 ID로
SiteUser조회 로직 추가현재
siteUserRepository.findById().orElseThrow(USER_NOT_FOUND)패턴이 반복되고 있는데, PR 목표에서 언급한findByIdOrThrow()기본 레포지토리 메서드가 추가되면 코드 중복을 효과적으로 해결할 수 있을 것입니다.Also applies to: 13-13, 37-37, 44-47, 62-64, 128-130
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (45)
src/main/java/com/example/solidconnection/application/controller/ApplicationController.java(2 hunks)src/main/java/com/example/solidconnection/application/service/ApplicationQueryService.java(5 hunks)src/main/java/com/example/solidconnection/application/service/ApplicationSubmissionService.java(3 hunks)src/main/java/com/example/solidconnection/auth/controller/AuthController.java(1 hunks)src/main/java/com/example/solidconnection/auth/service/AuthService.java(3 hunks)src/main/java/com/example/solidconnection/common/resolver/AuthorizedUserResolver.java(1 hunks)src/main/java/com/example/solidconnection/community/comment/controller/CommentController.java(1 hunks)src/main/java/com/example/solidconnection/community/comment/service/CommentService.java(5 hunks)src/main/java/com/example/solidconnection/community/post/controller/PostController.java(2 hunks)src/main/java/com/example/solidconnection/community/post/service/PostCommandService.java(5 hunks)src/main/java/com/example/solidconnection/community/post/service/PostLikeService.java(4 hunks)src/main/java/com/example/solidconnection/community/post/service/PostQueryService.java(2 hunks)src/main/java/com/example/solidconnection/mentor/controller/MentorController.java(1 hunks)src/main/java/com/example/solidconnection/mentor/controller/MentorMyPageController.java(1 hunks)src/main/java/com/example/solidconnection/mentor/controller/MentoringController.java(1 hunks)src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java(3 hunks)src/main/java/com/example/solidconnection/mentor/service/MentorQueryService.java(1 hunks)src/main/java/com/example/solidconnection/news/controller/NewsController.java(2 hunks)src/main/java/com/example/solidconnection/news/service/NewsCommandService.java(4 hunks)src/main/java/com/example/solidconnection/s3/controller/S3Controller.java(1 hunks)src/main/java/com/example/solidconnection/s3/service/S3Service.java(2 hunks)src/main/java/com/example/solidconnection/score/controller/ScoreController.java(1 hunks)src/main/java/com/example/solidconnection/score/service/ScoreService.java(6 hunks)src/main/java/com/example/solidconnection/siteuser/controller/MyPageController.java(1 hunks)src/main/java/com/example/solidconnection/siteuser/service/MyPageService.java(3 hunks)src/main/java/com/example/solidconnection/university/controller/UnivApplyInfoController.java(1 hunks)src/main/java/com/example/solidconnection/university/service/LikedUnivApplyInfoService.java(4 hunks)src/main/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendService.java(1 hunks)src/test/java/com/example/solidconnection/application/service/ApplicationQueryServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/application/service/ApplicationSubmissionServiceTest.java(4 hunks)src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/common/resolver/AuthorizedUserResolverTest.java(4 hunks)src/test/java/com/example/solidconnection/community/comment/service/CommentServiceTest.java(15 hunks)src/test/java/com/example/solidconnection/community/post/service/PostCommandServiceTest.java(11 hunks)src/test/java/com/example/solidconnection/community/post/service/PostLikeServiceTest.java(4 hunks)src/test/java/com/example/solidconnection/community/post/service/PostQueryServiceTest.java(1 hunks)src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java(1 hunks)src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java(2 hunks)src/test/java/com/example/solidconnection/mentor/service/MentorMyPageServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/mentor/service/MentorQueryServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/news/service/NewsCommandServiceTest.java(1 hunks)src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java(6 hunks)src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java(6 hunks)src/test/java/com/example/solidconnection/university/service/LikedUnivApplyInfoServiceTest.java(9 hunks)src/test/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendServiceTest.java(4 hunks)
🧠 Learnings (3)
src/test/java/com/example/solidconnection/mentor/service/MentorMyPageServiceTest.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
src/main/java/com/example/solidconnection/mentor/controller/MentorMyPageController.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
🧰 Additional context used
🧠 Learnings (3)
src/test/java/com/example/solidconnection/mentor/service/MentorMyPageServiceTest.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
src/main/java/com/example/solidconnection/mentor/controller/MentorMyPageController.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java (1)
Learnt from: nayonsoso
PR: #375
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:47-53
Timestamp: 2025-07-05T17:54:42.475Z
Learning: MentorMyPageService에서 PUT 메서드 구현 시 전체 채널을 새로 생성하여 교체하는 방식을 사용하는 것이 PUT의 의미론적 특성과 일치하며, 트랜잭션 로킹 관점에서도 합리적인 접근이다.
⏰ 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 (87)
src/test/java/com/example/solidconnection/news/service/NewsCommandServiceTest.java (1)
305-305: 리팩토링이 일관성 있게 적용되었습니다! 👍서비스 메서드 시그니처 변경에 맞춰
SiteUser객체 대신user.getId()를 전달하도록 테스트 코드가 올바르게 수정되었습니다. 도메인 객체를 계층 간에 직접 전달하지 않는 설계 원칙을 잘 따르고 있습니다.src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java (1)
77-78: 동시성 테스트에서도 리팩토링이 완벽하게 적용되었네요! ⚡
likePost메서드 호출 시 사용자 ID 전달로 변경dislikePost메서드 호출 시 사용자 ID 전달로 변경동시성 테스트의 핵심 로직은 그대로 유지하면서 서비스 메서드 시그니처 변경에만 깔끔하게 대응했습니다.
src/test/java/com/example/solidconnection/application/service/ApplicationSubmissionServiceTest.java (1)
84-84: 지원서 제출 서비스 테스트 전체에 리팩토링이 체계적으로 적용되었습니다! 📝
- 정상 지원서 제출 테스트
- 미승인 GPA 점수 예외 테스트
- 미승인 어학성적 예외 테스트
- 지원서 수정 횟수 초과 예외 테스트
모든 테스트 케이스에서
SiteUser객체 대신user.getId()를 일관되게 전달하도록 수정되어 있으며, 각 테스트의 검증 로직은 그대로 유지되어 완벽합니다.Also applies to: 118-118, 138-138, 157-157, 162-162
src/test/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendServiceTest.java (1)
83-83: 대학 추천 서비스 테스트에서 완벽한 리팩토링이 이루어졌습니다! 🎯
- 관심 지역 기반 추천 테스트
- 관심 국가 기반 추천 테스트
- 지역과 국가 모두 설정된 사용자 추천 테스트
- 관심사 미설정 사용자 일반 추천 테스트
모든 시나리오에서
getPersonalRecommends(user.getId())형태로 일관되게 변경되었으며, 각 추천 로직의 검증은 그대로 유지되어 테스트 품질이 보장됩니다.Also applies to: 102-102, 120-120, 138-138
src/test/java/com/example/solidconnection/application/service/ApplicationQueryServiceTest.java (1)
135-135: 지원서 조회 서비스 테스트에서 가장 포괄적인 리팩토링이 완료되었습니다! 🔍
- 전체 지원자 조회 테스트
- 특정 지역 지원자 조회 테스트
- 대학명 필터링 조회 테스트
- 이전 학기 지원자 제외 테스트
- 최신 지원서만 조회 테스트
- 경쟁자 목록 조회 테스트
getApplicants와getApplicantsByUserApplications두 메서드 모두에서user1.getId()형태로 일관되게 수정되어 있으며, 복잡한 조회 로직과 검증 과정이 모두 완벽하게 보존되었습니다.Also applies to: 187-187, 237-237, 267-267, 307-307, 357-357, 401-401
src/test/java/com/example/solidconnection/community/post/service/PostLikeServiceTest.java (1)
74-74: 테스트 메서드 시그니처 변경이 일관되게 적용되었습니다.PostLikeService의 리팩토링에 맞춰 모든 테스트에서
user객체 대신user.getId()를 전달하도록 수정되었습니다. 변경사항이 일관되고 올바르게 적용되었습니다.Also applies to: 89-89, 94-94, 108-108, 112-112, 129-129
src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java (1)
78-78: 마이페이지 서비스 테스트가 완전히 업데이트되었습니다.다음 변경사항들이 일관되게 적용되었습니다:
- 서비스 메서드 호출 시 사용자 ID 전달 방식으로 변경
- Mock 검증에서도 userId 매개변수 기대값으로 수정 (line 137)
- 모든 테스트 시나리오에서 일관된 패턴 적용
리팩토링 목표에 부합하는 완성도 높은 변경입니다.
Also applies to: 104-104, 119-119, 134-134, 137-137, 157-157, 174-174
src/test/java/com/example/solidconnection/community/post/service/PostQueryServiceTest.java (1)
156-156: 게시글 조회 서비스 테스트 업데이트가 정확합니다.
findPostById메서드 호출에서 사용자 객체 대신 사용자 ID를 전달하도록 올바르게 수정되었습니다.src/test/java/com/example/solidconnection/mentor/service/MentorMyPageServiceTest.java (1)
70-70: 멘토 마이페이지 서비스 테스트가 일관되게 업데이트되었습니다.멘토 관련 서비스 메서드 호출에서도 동일한 패턴으로
mentorUser.getId()를 전달하도록 수정되어, 전체 리팩토링과 일관성을 유지하고 있습니다.Also applies to: 93-93, 113-113
src/test/java/com/example/solidconnection/community/post/service/PostCommandServiceTest.java (1)
116-116: 게시글 커맨드 서비스 테스트가 체계적으로 업데이트되었습니다.다음과 같이 포괄적인 변경이 이루어졌습니다:
- 게시글 생성/수정/삭제 모든 시나리오에서 사용자 ID 전달 방식 적용
- 정상 케이스와 예외 케이스 모두 일관되게 수정
- 권한 검증 테스트에서도 올바른 사용자 ID 전달 확인
테스트 커버리지를 유지하면서 리팩토링 목표에 완벽히 부합하는 변경입니다.
Also applies to: 137-137, 150-150, 163-163, 187-187, 215-215, 233-233, 251-251, 273-273, 292-292, 304-304
src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java (1)
73-73: 테스트 메서드 시그니처 변경이 올바르게 적용되었습니다!
- GPA 점수 상태 조회 테스트들이
user.getId()를 사용하도록 변경- 어학 시험 점수 상태 조회 테스트들이
user.getId()를 사용하도록 변경- 점수 등록 테스트들이
user.getId()를 사용하도록 변경아키텍처 리팩토링에 맞춰 일관되게 적용되었고, 테스트 로직과 검증은 그대로 유지되어 안전한 변경입니다.
Also applies to: 82-82, 97-97, 106-106, 121-121, 137-137
src/test/java/com/example/solidconnection/community/comment/service/CommentServiceTest.java (1)
88-88: 댓글 서비스 테스트의 메서드 시그니처 변경이 완벽하게 적용되었습니다!
- 댓글 조회 테스트들이
user1.getId()사용으로 변경- 댓글 생성 테스트들이
user1.getId(),user2.getId()사용으로 변경- 댓글 수정 테스트들이 사용자 ID 기반으로 변경
- 댓글 삭제 테스트들이 사용자 ID 기반으로 변경
- 예외 처리 테스트들까지 모두 일관되게 적용
모든 CRUD 작업과 예외 시나리오를 포함하여 체계적으로 리팩토링되었습니다. 테스트 로직의 무결성이 유지되어 안전합니다.
Also applies to: 125-125, 144-144, 174-174, 201-201, 221-221, 244-244, 260-260, 278-278, 300-300, 317-317, 338-338, 358-358, 384-384, 407-407
src/main/java/com/example/solidconnection/s3/service/S3Service.java (1)
8-8: S3Service의 deleteExProfile 메서드가 올바르게 리팩토링되었습니다!
- 메서드 시그니처가
SiteUser객체에서long siteUserId로 변경USER_NOT_FOUND에러 코드 import 추가- 표준 패턴의 사용자 조회 및 예외 처리 구현:
siteUserRepository.findById().orElseThrow()DIP 원칙을 준수하면서 코드 중복을 줄이는 일관된 패턴이 적용되었습니다.
Also applies to: 113-115
src/test/java/com/example/solidconnection/mentor/service/MentorQueryServiceTest.java (1)
66-66: 멘토 조회 서비스 테스트의 메서드 시그니처 변경이 완벽하게 구현되었습니다!
getMentorDetails메서드 호출이siteUser.getId()사용으로 변경getMentorPreviews메서드 호출이currentUser.getId()사용으로 변경- 성공 및 실패 시나리오 테스트 모두 일관되게 적용
- 복잡한 멀티 사용자 테스트 시나리오도 안전하게 유지
멘토링 관련 모든 조회 기능이 새로운 아키텍처에 맞춰 체계적으로 업데이트되었습니다.
Also applies to: 88-89, 108-108, 138-138, 162-162, 176-176, 185-185
src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java (2)
15-15: SiteUserRepository 의존성 주입이 적절히 추가되었습니다!테스트에서 사용자 엔티티의 영속성 상태를 검증하기 위해 필요한 리포지토리 의존성이 올바르게 주입되었습니다.
Also applies to: 43-44
71-71: 탈퇴 테스트가 더욱 견고하게 개선되었습니다!
quit메서드 호출이user.getId()사용으로 변경되어 새로운 시그니처에 맞춰짐- 테스트 검증 로직이 개선됨: 데이터베이스에서 엔티티를 다시 로드하여 실제 영속성 상태를 확인
- 메모리 상의 객체가 아닌 실제 DB 저장 상태를 검증하는 더 정확한 테스트 패턴
이는 단순한 리팩토링을 넘어서 테스트의 신뢰성을 높이는 훌륭한 개선입니다!
Also applies to: 76-76, 78-78
src/main/java/com/example/solidconnection/auth/service/AuthService.java (3)
4-4: 새로운 에러 코드 import 추가 승인USER_NOT_FOUND 에러 코드를 추가하여 사용자 조회 실패 시 일관된 예외 처리가 가능해졌습니다.
11-11: SiteUserRepository 의존성 주입 승인서비스 레이어에서 직접 사용자 정보를 조회하기 위한 repository 의존성 추가가 적절합니다.
Also applies to: 23-23
43-48: 메서드 시그니처 변경 및 사용자 조회 로직 승인다음 변경사항들이 DIP 원칙을 준수하며 올바르게 구현되었습니다:
1. 매개변수가 `SiteUser` 객체에서 `long siteUserId`로 변경 2. 내부에서 repository를 통한 사용자 조회 로직 추가 3. 일관된 예외 처리 패턴 적용이는 컨트롤러에서 도메인 객체를 직접 전달하지 않는 올바른 아키텍처 패턴입니다.
src/test/java/com/example/solidconnection/university/service/LikedUnivApplyInfoServiceTest.java (1)
60-60: 테스트 메서드 호출 패턴 변경 승인다음 변경사항들이 새로운 서비스 메서드 시그니처에 맞춰 올바르게 적용되었습니다:
1. `likedUnivApplyInfoService.getLikedUnivApplyInfos(user.getId())` 호출 방식 변경 2. `likedUnivApplyInfoService.addUnivApplyInfoLike(user.getId(), ...)` 패턴 일관 적용 3. `likedUnivApplyInfoService.cancelUnivApplyInfoLike(user.getId(), ...)` 패턴 일관 적용 4. `likedUnivApplyInfoService.isUnivApplyInfoLiked(user.getId(), ...)` 패턴 일관 적용모든 테스트 메서드가
SiteUser객체 대신user.getId()를 전달하도록 일관되게 변경되어 비즈니스 로직 테스트에 집중할 수 있습니다.Also applies to: 73-73, 87-87, 102-102, 113-113, 125-125, 136-136, 145-145, 157-157
src/main/java/com/example/solidconnection/auth/controller/AuthController.java (1)
106-111: 컨트롤러 메서드 매개변수 및 서비스 호출 변경 승인다음 변경사항들이 새로운 아키텍처 패턴에 맞춰 올바르게 구현되었습니다:
1. `@AuthorizedUser SiteUser siteUser`에서 `@AuthorizedUser long siteUserId`로 매개변수 변경 2. `authService.quit(siteUser, accessToken)`에서 `authService.quit(siteUserId, accessToken)`로 호출 방식 변경컨트롤러에서 도메인 객체를 직접 전달하지 않음으로써 DIP 원칙을 준수하는 좋은 변경입니다.
src/main/java/com/example/solidconnection/s3/controller/S3Controller.java (1)
47-47: S3 컨트롤러 메서드 매개변수 및 서비스 호출 변경 승인다음 변경사항들이 새로운 아키텍처 패턴과 일치하게 적용되었습니다:
1. `@AuthorizedUser SiteUser siteUser`에서 `@AuthorizedUser long siteUserId`로 매개변수 타입 변경 2. `s3Service.deleteExProfile(siteUser)`에서 `s3Service.deleteExProfile(siteUserId)`로 호출 방식 변경전체 리팩토링과 일관된 패턴으로 구현되어 코드베이스의 일관성이 향상되었습니다.
Also applies to: 51-51
src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java (2)
35-35: 테스트 필드 및 초기화 로직 변경 승인다음 변경사항들이 새로운 서비스 메서드 시그니처에 맞춰 적절히 구현되었습니다:
1. `SiteUser user` 필드에서 `long siteUserId` 필드로 변경 2. `setUp()` 메서드에서 `siteUserFixture.사용자().getId()`로 ID만 저장하도록 변경테스트 로직의 본질은 유지하면서 새로운 매개변수 타입에 맞춰 올바르게 적응되었습니다.
Also applies to: 39-39
55-57: 동시성 테스트의 서비스 호출 패턴 변경 승인모든
applicationQueryService.getApplicants호출이siteUserId를 전달하도록 일관되게 변경되었습니다:1. 빈 필터 조건 테스트: `getApplicants(siteUserId, "", "")` 2. 지역 필터 테스트: `getApplicants(siteUserId, "ASIA", "")` 3. 대학명 필터 테스트: `getApplicants(siteUserId, "", "추오")`ThunderingHerd 문제 해결을 위한 동시성 테스트의 핵심 로직은 그대로 유지하면서 새로운 서비스 인터페이스에 맞춰 정확히 적응되었습니다.
src/main/java/com/example/solidconnection/university/service/UnivApplyInfoRecommendService.java (1)
35-38: 리팩터링이 깔끔하게 적용되었습니다!
- 메서드 시그니처가 도메인 객체에서 기본형으로 변경되어 DIP 원칙을 준수합니다
SiteUser→long siteUserId로 변경- 레포지토리 호출 시 사용자 ID를 직접 전달하도록 수정되었습니다
- 별도의
SiteUser엔티티 조회가 불필요하여 효율적입니다src/main/java/com/example/solidconnection/news/service/NewsCommandService.java (3)
5-5: 필요한 에러 코드가 추가되었습니다.사용자 조회 실패 시 사용할
USER_NOT_FOUND에러 코드를 적절히 임포트했습니다.
19-19: 의존성 주입이 올바르게 추가되었습니다.
SiteUserRepository임포트 추가- 서비스 내에서 사용자 엔티티 조회를 위한 의존성 주입
서비스 계층에서 사용자 검증을 담당하는 구조로 변경되었습니다.
Also applies to: 32-32
83-85: 메서드 시그니처 변경과 사용자 검증 로직이 적절합니다.
- 파라미터가 도메인 객체에서 기본형으로 변경됨
SiteUser siteUser→long siteUserId- 서비스 내에서 사용자 엔티티 조회 및 검증 수행
USER_NOT_FOUND예외로 적절한 에러 처리DIP 원칙을 준수하면서도 기존 로직의 무결성을 유지합니다.
src/main/java/com/example/solidconnection/community/post/service/PostQueryService.java (2)
57-59: 메서드 시그니처 변경과 사용자 검증 로직이 일관성 있게 적용되었습니다.
- 파라미터 타입 변경으로 DIP 원칙 준수
SiteUser siteUser→long siteUserId- 서비스 내부에서 사용자 엔티티 조회 및 존재성 검증
USER_NOT_FOUND예외 처리로 안전성 확보리팩터링 패턴이 일관되게 적용되었습니다.
71-71: 하위 서비스 호출이 올바르게 업데이트되었습니다.댓글 서비스 호출 시
SiteUser객체 대신 사용자 ID를 전달하도록 수정되어, 전체 리팩터링과 일관성을 유지합니다.src/main/java/com/example/solidconnection/application/service/ApplicationSubmissionService.java (3)
8-8: 필요한 에러 코드 임포트가 추가되었습니다.사용자 검증 실패 시 사용할
USER_NOT_FOUND에러 코드가 적절히 추가되었습니다.
22-22: 사용자 조회를 위한 의존성이 올바르게 추가되었습니다.
SiteUserRepository임포트 및 의존성 주입 추가- 서비스 계층에서 사용자 엔티티 조회 담당하는 구조로 변경
아키텍처 개선 목표와 일치합니다.
Also applies to: 38-38
46-48: 리팩터링 패턴이 일관되게 적용되었습니다.
- 메서드 파라미터가 도메인 객체에서 기본형으로 변경
- DIP 원칙 준수로 계층 간 의존성 개선
- 서비스 내부에서 사용자 엔티티 조회 및 검증 수행
- 중앙화된 사용자 검증 로직
전체 코드베이스에서 일관된 패턴이 적용되고 있습니다.
src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java (4)
5-5: 에러 처리를 위한 상수가 적절히 추가되었습니다.사용자 조회 실패 시 사용할
USER_NOT_FOUND에러 코드를 임포트했습니다.
15-15: 사용자 엔티티 조회를 위한 의존성이 추가되었습니다.
SiteUserRepository임포트 추가- 서비스 의존성 주입으로 사용자 검증 기능 구현
리팩터링 목표에 맞는 변경사항입니다.
Also applies to: 30-30
33-35: getMentorMyPage 메서드가 올바르게 리팩터링되었습니다.
- 파라미터 타입 변경으로 DIP 원칙 준수
SiteUser siteUser→long siteUserId- 서비스 내부에서 사용자 엔티티 조회 및 검증
- 응답 생성에 필요한
SiteUser객체를 안전하게 획득
42-44: updateMentorMyPage 메서드가 효율적으로 리팩터링되었습니다.
- 파라미터가 기본형으로 변경되어 DIP 원칙 준수
SiteUser siteUser→long siteUserId- 멘토 조회 시 사용자 ID를 직접 사용하여 효율적 구현
- 별도
SiteUser엔티티 조회 불필요각 메서드의 요구사항에 맞게 적절히 최적화되었습니다.
src/main/java/com/example/solidconnection/siteuser/service/MyPageService.java (3)
37-39: ✅ 리팩토링 패턴이 올바르게 적용되었습니다
- 메서드 시그니처가
SiteUser객체에서long siteUserId로 정확히 변경되었습니다- 서비스 내부에서 사용자 조회와 예외 처리가 적절히 구현되었습니다
48-50: ✅ 일관된 리팩토링 패턴 적용 확인updateMyPageInfo 메서드도 동일한 패턴으로 올바르게 변경되었습니다.
62-62: ✅ S3Service 호출부도 일관되게 수정되었습니다
s3Service.deleteExProfile(user.getId())로 변경되어 전체 리팩토링과 일치합니다.src/main/java/com/example/solidconnection/community/post/service/PostLikeService.java (3)
4-4: ✅ 필요한 의존성과 임포트가 올바르게 추가되었습니다
USER_NOT_FOUNDErrorCode 임포트 추가SiteUserRepository의존성 주입 및 임포트 추가리팩토링에 필요한 모든 요소가 적절히 구성되었습니다.
Also applies to: 14-14, 26-26
29-31: ✅ likePost 메서드가 올바르게 리팩토링되었습니다메서드 시그니처와 사용자 조회 로직이 일관된 패턴으로 구현되었습니다.
43-45: ✅ dislikePost 메서드도 동일한 패턴으로 적용되었습니다두 메서드 모두 일관성 있게 리팩토링되어 유지보수성이 향상되었습니다.
src/main/java/com/example/solidconnection/siteuser/controller/MyPageController.java (2)
25-25: ✅ Controller 계층이 올바르게 리팩토링되었습니다
@AuthorizedUser long siteUserId파라미터로 정확히 변경- 서비스 호출시
siteUserId전달로 일관성 유지Also applies to: 27-27
33-33: ✅ updateMyPageInfo 메서드도 동일한 패턴으로 적용되었습니다Controller에서 Service로의 호출이 일관되게 사용자 ID 기반으로 변경되었습니다.
Also applies to: 37-37
src/main/java/com/example/solidconnection/mentor/controller/MentorMyPageController.java (2)
28-28: ✅ Mentor Controller가 일관된 패턴으로 리팩토링되었습니다
@AuthorizedUser long siteUserId파라미터 변경mentorMyPageService.getMentorMyPage(siteUserId)호출 업데이트보안 어노테이션(
@RequireRoleAccess)도 올바르게 유지되었습니다.Also applies to: 30-30
37-37: ✅ updateMentorMyPage 메서드도 올바르게 적용되었습니다PUT 메서드의 리팩토링이 일관성 있게 처리되었으며, 이전 학습 내용에 따라 PUT의 의미론적 특성도 잘 유지되고 있습니다.
Also applies to: 40-40
src/main/java/com/example/solidconnection/mentor/service/MentorQueryService.java (3)
34-34: ✅ getMentorDetails 메서드가 효율적으로 리팩토링되었습니다
- 파라미터가
long currentUserId로 변경currentUserId를 직접 사용하여 불필요한 객체 조회 제거사용자 ID만 필요한 경우의 좋은 리팩토링 예시입니다.
Also applies to: 39-39
45-45: ✅ getMentorPreviews 메서드도 일관되게 적용되었습니다파라미터와 메서드 호출이 모두 사용자 ID 기반으로 올바르게 변경되었습니다.
Also applies to: 48-48
53-53: ✅ 프라이빗 헬퍼 메서드까지 일관성 있게 수정되었습니다
getMentorPreviewResponses메서드도 동일한 패턴으로 업데이트되어 전체적인 일관성이 유지되었습니다.Also applies to: 55-55
src/main/java/com/example/solidconnection/community/post/service/PostCommandService.java (4)
7-7: 의존성 추가가 적절하게 처리되었습니다다음과 같은 변경사항들이 올바르게 구현되었습니다:
USER_NOT_FOUND에러 코드 import 추가SiteUserRepository의존성 주입 추가- 리포지토리 필드 선언
이러한 변경으로 사용자 검증 로직이 서비스 계층으로 적절히 이동되었습니다.
Also applies to: 25-25, 41-41
47-50: 사용자 검증 로직이 명확하게 개선되었습니다
createPost메서드에서 다음과 같은 개선사항을 확인할 수 있습니다:
- 메서드 시그니처가
SiteUser객체에서long siteUserId로 변경- 명시적인 사용자 존재 확인 및 예외 처리
- DIP 원칙 준수를 통한 계층 간 결합도 감소
이 접근 방식은 도메인 객체를 직접 전달하는 것보다 더 안전하고 명확합니다.
67-70: 업데이트 메서드의 일관된 리팩토링
updatePost메서드도 동일한 패턴으로 개선되었습니다:
- 원시 타입 매개변수 사용
- 동일한 사용자 검증 로직 적용
- 기존 비즈니스 로직 유지
전체 서비스에서 일관된 접근 방식을 유지하고 있어 좋습니다.
99-101: 삭제 메서드의 완전한 통합
deletePostById메서드도 완벽하게 리팩토링되었습니다:
- 동일한 매개변수 타입 변경
- 일관된 사용자 검증 패턴
- 코드 중복 최소화
모든 메서드가 동일한 검증 패턴을 따르고 있어 유지보수성이 크게 향상되었습니다.
src/main/java/com/example/solidconnection/mentor/controller/MentorController.java (2)
32-32: 멘토 상세 조회 메서드의 깔끔한 리팩토링다음과 같은 개선사항이 적용되었습니다:
@AuthorizedUser SiteUser에서@AuthorizedUser long siteUserId로 매개변수 타입 변경- 서비스 호출 시 사용자 ID만 전달하도록 수정
컨트롤러 계층에서 도메인 객체 의존성이 제거되어 더 깔끔한 아키텍처가 구현되었습니다.
Also applies to: 35-35
41-41: 멘토 목록 조회 메서드의 일관된 변경
getMentorPreviews메서드도 동일한 패턴으로 개선되었습니다:
- 원시 타입 매개변수 사용
- 서비스 메서드 호출 방식 통일
- 전체 컨트롤러의 일관성 유지
모든 메서드가 동일한 접근 방식을 따르고 있어 코드의 일관성이 훌륭합니다.
Also applies to: 51-51
src/main/java/com/example/solidconnection/community/comment/service/CommentService.java (4)
6-6: 에러 코드 import 추가가 적절히 처리됨
USER_NOT_FOUND에러 코드가 올바르게 추가되어 일관된 예외 처리가 가능해졌습니다.
40-42: 댓글 조회 메서드의 안전한 리팩토링
findCommentsByPostId메서드가 다음과 같이 개선되었습니다:
SiteUser매개변수를long siteUserId로 변경- 명시적인 사용자 존재 확인 로직 추가
- 기존 댓글 필터링 및 응답 생성 로직 유지
사용자 검증이 메서드 초기에 수행되어 더 안전한 구조가 되었습니다.
89-91: 댓글 생성 메서드의 일관된 패턴 적용
createComment메서드도 동일한 리팩토링 패턴이 적용되었습니다:
- 원시 타입 매개변수 사용
- 동일한 사용자 검증 로직
- 비즈니스 로직의 완전한 보존
전체 서비스에서 통일된 접근 방식이 유지되고 있습니다.
113-115: 수정 및 삭제 메서드의 완전한 통합
updateComment와deleteCommentById메서드들이 모두 일관되게 리팩토링되었습니다:
- 동일한 매개변수 타입 변경 패턴
- 통일된 사용자 검증 로직
- 복잡한 댓글 삭제 로직도 안전하게 보존
모든 메서드가 동일한 검증 패턴을 따르면서도 각각의 고유한 비즈니스 로직은 완벽히 유지되었습니다.
Also applies to: 132-134
src/main/java/com/example/solidconnection/university/service/LikedUnivApplyInfoService.java (4)
34-35: 좋아요 목록 조회의 효율적인 개선
getLikedUnivApplyInfos메서드가 다음과 같이 최적화되었습니다:
SiteUser객체 대신long siteUserId직접 사용- 불필요한 사용자 엔티티 조회 제거
- 더 간결하고 효율적인 데이터 접근
사용자 ID만 필요한 로직에서는 이 방식이 성능상 더 유리합니다.
45-45: 좋아요 추가 메서드의 깔끔한 단순화
addUnivApplyInfoLike메서드가 효율적으로 리팩토링되었습니다:
- 매개변수 타입을 원시
long으로 변경- 리포지토리 조회에서 직접 사용자 ID 활용
- 엔티티 생성 시에도 ID 직접 사용
전체 로직이 더 직관적이고 성능상 이점이 있는 구조로 개선되었습니다.
Also applies to: 48-48, 55-55
64-64: 좋아요 취소 메서드의 일관된 적용
cancelUnivApplyInfoLike메서드도 동일한 최적화 패턴이 적용되었습니다:
- 원시 타입 매개변수 사용
- 직접적인 ID 기반 리포지토리 조회
- 불필요한 객체 변환 제거
전체 서비스의 일관성과 효율성이 모두 향상되었습니다.
Also applies to: 67-67
79-79: 좋아요 상태 확인의 완벽한 통합
isUnivApplyInfoLiked메서드가 완전히 리팩토링되었습니다:
- 동일한 매개변수 타입 변경
- 일관된 ID 기반 처리 방식
- 간결한 boolean 반환 로직
모든 메서드가 통일된 접근 방식을 따르면서도 각각의 목적에 최적화된 구조를 갖추었습니다.
Also applies to: 81-81
src/main/java/com/example/solidconnection/score/service/ScoreService.java (4)
3-3: 의존성 및 import 추가가 완벽하게 처리됨다음과 같은 변경사항들이 올바르게 구현되었습니다:
USER_NOT_FOUND에러 코드 import 추가CustomExceptionimport 추가SiteUserRepository의존성 주입 추가- 리포지토리 필드 선언
모든 필수 의존성이 적절히 추가되어 사용자 검증 로직을 지원합니다.
Also applies to: 7-7, 22-22, 37-37
40-42: GPA 점수 제출 메서드의 안전한 리팩토링
submitGpaScore메서드가 다음과 같이 개선되었습니다:
SiteUser매개변수를long siteUserId로 변경- 명시적인 사용자 존재 확인 및 예외 처리
- 파일 업로드 및 엔티티 생성 로직 완전 보존
사용자 검증이 비즈니스 로직 실행 전에 수행되어 더 안전한 구조가 되었습니다.
51-53: 언어 시험 점수 제출의 일관된 패턴
submitLanguageTestScore메서드도 동일한 리팩토링 패턴이 적용되었습니다:
- 원시 타입 매개변수 사용
- 동일한 사용자 검증 로직
- 복잡한 파일 업로드 로직 안전하게 보존
전체 서비스에서 통일된 접근 방식이 유지되고 있습니다.
63-65: 점수 상태 조회 메서드들의 완전한 통합
getGpaScoreStatus와getLanguageTestScoreStatus메서드들이 모두 일관되게 리팩토링되었습니다:
- 동일한 매개변수 타입 변경 패턴
- 통일된 사용자 검증 로직
- 복잡한 응답 생성 로직도 완벽히 보존
모든 메서드가 동일한 검증 패턴을 따르면서도 각각의 고유한 비즈니스 로직은 완전히 유지되었습니다.
Also applies to: 76-78
src/main/java/com/example/solidconnection/community/comment/controller/CommentController.java (1)
30-30: 인증 사용자 파라미터 리팩토링이 올바르게 적용되었습니다.다음 변경사항들이 정확히 구현되었습니다:
@AuthorizedUser SiteUser siteUser에서@AuthorizedUser long siteUserId로 파라미터 타입 변경- 서비스 메서드 호출 시 도메인 객체 대신 ID 값 전달
- 컨트롤러 계층에서 도메인 객체 의존성 제거
이러한 변경으로 의존성 역전 원칙(DIP)을 준수하게 되었습니다.
Also applies to: 33-33, 39-39, 43-43, 49-49, 52-52
src/main/java/com/example/solidconnection/application/controller/ApplicationController.java (1)
33-33: 일관된 리팩토링 패턴이 잘 적용되었습니다.ApplicationController의 모든 메서드에서 다음 변경사항들이 일관되게 구현되었습니다:
- 인증 사용자 파라미터를
SiteUser객체에서long siteUserId로 변경- 서비스 계층 호출 시 일관되게 사용자 ID 전달
- 도메인 객체 직접 전달 방식 제거
특히 권한 검증이 필요한 메서드들에서도 동일한 패턴이 적용된 것이 좋습니다.
Also applies to: 36-36, 45-45, 49-50, 57-57, 59-60
src/main/java/com/example/solidconnection/common/resolver/AuthorizedUserResolver.java (1)
24-25: 인증 사용자 리졸버 리팩토링이 매우 잘 구현되었습니다.다음 핵심 개선사항들이 탁월하게 적용되었습니다:
long및Long타입 모두 지원하는 유연한 파라미터 타입 처리- 인증 컨텍스트에서 사용자 ID만 추출하는 깔끔한 로직
- 특히 우수한 점: primitive 타입에 대한 NPE 방지 로직 구현
isRequired메서드를 통한 세밀한 필수값 검증 처리primitive 타입을 required로 간주하여 null 값으로 인한 NullPointerException을 사전에 방지하는 설계가 매우 신중하고 실용적입니다.
Also applies to: 33-37, 40-48, 50-56
src/main/java/com/example/solidconnection/mentor/controller/MentoringController.java (1)
37-37: 멘토링 컨트롤러의 리팩토링이 완벽하게 완료되었습니다.모든 컨트롤러 메서드에서 일관된 변경이 적용되었습니다:
- 5개 메서드 모두에서
@AuthorizedUser SiteUser를@AuthorizedUser long siteUserId로 변경- 권한 검증이 필요한 메서드들(
@RequireRoleAccess)에서도 동일한 패턴 적용- 서비스 호출 시 일관되게 사용자 ID 전달 방식 사용
멘토링 도메인의 복잡한 권한 구조에서도 리팩토링 패턴이 일관되게 적용된 것이 인상적입니다.
Also applies to: 40-40, 47-47, 49-49, 56-56, 60-60, 67-67, 70-70, 77-77, 79-79
src/main/java/com/example/solidconnection/university/controller/UnivApplyInfoController.java (3)
34-40: 인증 사용자 파라미터 타입 변경이 적절히 적용되었습니다다음과 같은 개선점들이 잘 구현되었습니다:
- 선택적 인증 처리:
@AuthorizedUser(required = false) Long siteUserId로 nullable 타입 사용- 적절한 null 체크: 인증되지 않은 사용자를 위한 일반 추천과 개인화 추천을 구분 처리
- 서비스 호출 단순화:
SiteUser객체 대신siteUserId를 직접 전달이는 DIP 원칙을 준수하면서도 코드의 가독성을 높이는 좋은 구현입니다.
46-49: 필수 인증이 필요한 엔드포인트의 primitive long 사용이 적절합니다좋아요 목록 조회는 반드시 로그인된 사용자만 접근할 수 있으므로
@AuthorizedUser long siteUserId사용이 맞습니다. 이는 ArgumentResolver에서 인증 실패 시 예외를 발생시켜 안전성을 보장합니다.
54-67: 좋아요 관련 엔드포인트들의 일관된 리팩터링다음 항목들이 일관성 있게 적용되었습니다:
- 매개변수 타입 통일: 모든 좋아요 관련 메서드에서
long siteUserId사용- 서비스 호출 단순화: 객체 전달 대신 ID만 전달하여 의존성 역전 원칙 준수
- 메서드 시그니처 일관성: 조회, 추가, 삭제 모든 액션에서 동일한 패턴 적용
코드 중복을 줄이면서도 계층 간 결합도를 낮추는 좋은 설계입니다.
src/test/java/com/example/solidconnection/common/resolver/AuthorizedUserResolverTest.java (3)
46-56: 테스트 검증 로직이 새로운 resolver 동작에 맞게 잘 업데이트되었습니다다음과 같은 개선점들이 적절히 반영되었습니다:
- 반환 타입 변경:
SiteUser객체 대신Long타입의 사용자 ID 검증- 실제 값 비교:
user.getId()와resolvedUserId직접 비교로 정확성 향상- null 안전성: 반환된 ID가 null이 아님을 먼저 확인하는 방어적 코딩
이는 리팩터링된 AuthorizedUserResolver의 새로운 동작을 정확히 테스트합니다.
61-70: primitive 타입 파라미터에 대한 새로운 예외 처리 테스트가 잘 추가되었습니다중요한 보안 검증 로직이 제대로 테스트되고 있습니다:
- primitive long 파라미터: 인증 실패 시 NullPointerException 방지를 위한 예외 발생 검증
- 적절한 예외 타입:
CustomException과AUTHENTICATION_FAILED메시지 확인- 안전성 보장: required가 기본값인 primitive 타입의 안전한 처리 확인
ArgumentResolver의 핵심 보안 로직에 대한 테스트 커버리지가 훌륭합니다.
100-123: reflection 기반 MethodParameter 생성으로 테스트 현실성이 크게 향상되었습니다다음과 같은 장점들을 제공합니다:
- 실제 어노테이션 사용: 수동 mock 대신 실제
@AuthorizedUser어노테이션 활용- 다양한 파라미터 타입 지원:
Long,long,required=true/false등 모든 케이스 커버- 유지보수성 향상: TestController의 메서드 시그니처 변경만으로 테스트 케이스 확장 가능
- 예외 처리 단순화: checked exception을 unchecked로 변환하여 테스트 코드 가독성 향상
테스트의 정확성과 유지보수성을 동시에 개선한 훌륭한 리팩터링입니다.
src/main/java/com/example/solidconnection/score/controller/ScoreController.java (2)
30-36: 성적 관련 엔드포인트의 인증 사용자 파라미터 리팩터링이 잘 적용되었습니다다음과 같은 일관된 패턴이 적용되었습니다:
- primitive long 사용: 모든 성적 관련 기능은 필수 인증이므로 적절함
- 서비스 호출 단순화:
siteUser객체 대신siteUserId만 전달- 계층간 결합도 감소: Controller에서 Service로 도메인 객체를 직접 전달하지 않음
성적 제출이라는 민감한 기능에 대해 안전하고 일관된 인증 처리가 구현되었습니다.
41-65: 모든 성적 관리 메서드에서 일관된 리팩터링 패턴 적용각 메서드별로 다음과 같이 적절히 수정되었습니다:
- 어학성적 제출 (line 41-46):
siteUserId파라미터로 변경 및 서비스 호출 업데이트- 학점 상태 조회 (line 52-55): 동일한 패턴으로 사용자 ID 기반 조회
- 어학성적 상태 조회 (line 61-64): 일관된 파라미터 처리
모든 성적 관리 기능에서 DIP 원칙을 준수하면서도 코드 가독성을 유지한 좋은 구현입니다.
src/main/java/com/example/solidconnection/news/controller/NewsController.java (3)
49-55: 뉴스 생성 엔드포인트의 인증 사용자 처리가 적절히 개선되었습니다다음과 같은 개선 사항들이 잘 구현되었습니다:
- Role 기반 접근제어 유지:
@RequireRoleAccess어노테이션은 그대로 보존- 파라미터 단순화:
SiteUser객체 대신long siteUserId로 간소화- 서비스 레이어 분리: 도메인 객체 전달 대신 ID만 전달하여 계층 간 결합도 감소
ADMIN과 MENTOR만 뉴스를 생성할 수 있다는 보안 요구사항을 유지하면서도 코드 구조를 개선했습니다.
59-71: 뉴스 수정 및 삭제 엔드포인트의 일관된 리팩터링권한이 필요한 작업들에 대해 일관된 개선이 이루어졌습니다:
- 수정 기능 (line 59-71):
siteUserId파라미터 적용 및 서비스 호출 단순화- 삭제 기능 (line 75-81): 동일한 패턴으로 사용자 ID 기반 처리
- 보안 일관성: 두 기능 모두 ADMIN/MENTOR 권한과 인증 사용자 검증 유지
중요한 데이터 변경 작업에서 보안성을 유지하면서도 코드 품질을 개선한 좋은 구현입니다.
84-108: 뉴스 좋아요 관련 기능들의 체계적인 리팩터링사용자 상호작용 기능들이 일관되게 개선되었습니다:
- 좋아요 상태 확인 (line 84-90):
siteUserId로 간소화된 사용자 식별- 좋아요 추가 (line 92-99): 동일한 패턴으로 서비스 호출 최적화
- 좋아요 취소 (line 101-108): 일관된 사용자 ID 기반 처리
모든 좋아요 관련 기능에서 DIP 원칙을 준수하면서도 API 일관성을 유지한 훌륭한 설계입니다.
src/main/java/com/example/solidconnection/community/post/controller/PostController.java (4)
42-51: 게시글 생성 엔드포인트의 사용자 인증 처리가 효율적으로 개선되었습니다다음과 같은 개선점들이 적절히 구현되었습니다:
- 파라미터 단순화:
SiteUser객체 대신long siteUserId사용으로 간소화- 파일 업로드 로직 보존: 이미지 파일 처리 로직은 그대로 유지하여 기능 안정성 확보
- 서비스 호출 최적화: 도메인 객체 전달 없이 ID만 전달하여 계층 간 결합도 감소
게시글 작성이라는 핵심 기능에서 보안성과 효율성을 동시에 개선했습니다.
54-67: 게시글 수정 기능의 체계적인 리팩터링수정 기능에 대해 일관된 개선이 이루어졌습니다:
- 사용자 인증:
long siteUserId로 간소화된 사용자 식별- 서비스 파라미터: 다중 파라미터 전달에서 사용자 ID 부분만 깔끔하게 변경
- 파일 처리 유지: 이미지 업로드 로직의 안정성 보장
복잡한 수정 로직에서도 사용자 관련 처리만 선별적으로 개선한 좋은 접근입니다.
70-85: 게시글 조회 및 삭제 기능의 일관된 사용자 처리읽기와 삭제 작업에 대해 통일된 패턴이 적용되었습니다:
- 조회 기능 (line 70-76): 인증된 사용자 기준 게시글 상세 조회 최적화
- 삭제 기능 (line 78-85): 동일한
siteUserId패턴으로 권한 검증 단순화- 응답 일관성: 기존 응답 구조 유지하면서 내부 처리만 개선
사용자 권한이 중요한 작업들에서 안전성을 유지하면서 코드 품질을 향상시켰습니다.
88-103: 게시글 좋아요/싫어요 기능의 완전한 리팩터링사용자 상호작용 기능들이 체계적으로 개선되었습니다:
- 좋아요 추가 (line 88-94):
siteUserId기반의 간소화된 처리- 좋아요 취소 (line 96-103): 일관된 패턴으로 사용자 식별 및 서비스 호출
- API 일관성: 두 기능 모두 동일한 사용자 인증 처리 방식 적용
커뮤니티의 핵심 기능인 좋아요 시스템에서 DIP 원칙을 준수하면서도 사용자 경험을 보장하는 훌륭한 구현입니다.
a176925 to
727ebc3
Compare
whqtker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다 ~ 익숙치 않아서 그런가 인증 인가가 쉽지 않네요 .. ㅠㅠ
BoardController 에 SiteUser 를 인자로 받고 있는 부분이 있어, 해당 부분만 수정하면 완벽한 것 같습니다 !
| return true; | ||
| } | ||
| AuthorizedUser authorizedUser = parameter.getParameterAnnotation(AuthorizedUser.class); | ||
| return authorizedUser != null && authorizedUser.required(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
일반적인 경우라면 authorizedUser 는 null 이 아니지만 작성하신 것처럼 authorizedUser != null 를 추가하는 거 좋은 것 같습니다 !
ㅠㅠ 처음 보셨다면 코드리뷰 하기 어려우셨을 것 같아요..
수정했습니다! 꼼꼼한 확인 감사드려요 😊 |
whqtker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
변경사항 확인했습니다 !
lsy1307
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
헉 서비스단까지 다 수정해주셨네요 ㅜㅜ 고생하셨습니다 진짜
관련 이슈
작업 내용
너무 오래된 이슈라 자괴감이 드는 이슈입니다 🥲
(히스토리 설명) SiteUser 객체를 Controller → Service 로 전달하면, Service 코드에서는
siteUserRepository.findById().orElseThrow(USER_NOT_FOUND);와 같은 중복코드 없이SiteUser를 POJO처럼 다룰 수 있을 것이라 생각했습니다.
하지만 아무리 편리하다고 하더라도, 도메인 객체를 Controller에서 넘겨주는건 DIP 위반입니다.
그리고 양방향 연관계에 대한 리팩터링을 하기 전에는, SiteUser와 연관된 객체에서 LazyInitialization도 발생해 변경의 필요성을 느꼈습니다.
(다행히 LazyInitialization 관련 코드는 수연님이 연관관계 PR에서 없애주셨습니다. 감사합니다🙇🏻♀️)
Controller에서 Service레이어로 전달되던 SiteUser 객체를 long siteUserId로 바꿉니다.
그랬더니 수많은 곳에 siteUserRepository.findById().orElseThrow(USER_NOT_FOUND)라는 중복코드가 발생하더라고요 🥲
대안으로 siteUserRepository.findByIdOrThrow()라는 default 함수를 디스코드에 제안드렸습니다!
검토 부탁드립니다.
특이 사항
그리고 사용자가 선언한 형식으로 형변환하여 넣어주는 구조입니다.
따라서 long 형태로 선언한다면, NPE가 발생할 위험이 있습니다.
이를 방지하기 위해 타입이 원시타입이면
required = true로 여기게 하는 코드를 작성했습니다.