Skip to content

Conversation

@nayonsoso
Copy link
Collaborator

@nayonsoso nayonsoso commented Jul 23, 2025

관련 이슈

작업 내용

너무 오래된 이슈라 자괴감이 드는 이슈입니다 🥲

  • (히스토리 설명) 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 함수를 디스코드에 제안드렸습니다!
    검토 부탁드립니다.

특이 사항

  • 기본적으로 argumentResolver는 Object 형식을 반환합니다.
    그리고 사용자가 선언한 형식으로 형변환하여 넣어주는 구조입니다.
    따라서 long 형태로 선언한다면, NPE가 발생할 위험이 있습니다.
    이를 방지하기 위해 타입이 원시타입이면 required = true로 여기게 하는 코드를 작성했습니다.

@nayonsoso nayonsoso self-assigned this Jul 23, 2025
@coderabbitai
Copy link

coderabbitai bot commented Jul 23, 2025

"""

Walkthrough

  1. 컨트롤러 및 서비스 계층에서 인증 사용자 파라미터 변경
      - 모든 컨트롤러와 서비스 계층에서 기존에 @AuthorizedUser SiteUser로 주입받던 인증 사용자를 @AuthorizedUser long siteUserId 또는 Long siteUserId로 변경하였습니다.
      - 이에 따라 서비스 계층 메서드 시그니처도 일제히 SiteUser 객체 대신 사용자 ID(primitive 혹은 래퍼 타입)를 받도록 수정되었습니다.
      - 컨트롤러에서 서비스 호출 시에도 객체가 아닌 ID만 전달합니다.

  2. 인증 사용자 리졸버(AuthorizedUserResolver) 리팩토링
      - 리졸버가 더 이상 SiteUser 객체를 반환하지 않고, 인증된 사용자의 ID(Long)만 반환하도록 변경되었습니다.
      - 파라미터 타입이 long/Long일 때만 동작하며, primitive 타입의 경우 항상 필수(required)로 간주합니다.
      - 내부적으로 인증 정보에서 사용자 ID만 추출합니다.

  3. 서비스 계층에서 사용자 조회 및 예외 처리 추가
      - 서비스 계층에서 사용자 ID를 받아 직접 SiteUserRepository로부터 사용자를 조회합니다.
      - 사용자가 존재하지 않을 경우 CustomException(USER_NOT_FOUND)를 발생시킵니다.
      - 이 패턴은 커뮤니티, 뉴스, 멘토, 점수, 지원 등 모든 도메인 서비스에 일괄 적용되었습니다.

  4. 테스트 코드 전체 일괄 반영
      - 테스트 코드 내 모든 서비스/컨트롤러 호출에서 SiteUser 객체 대신 user.getId()를 전달하도록 변경하였습니다.
      - 인증 사용자 리졸버 테스트는 실제 리플렉션 기반으로 파라미터 정보를 얻도록 개선되었으며, primitive 타입 처리 케이스가 추가되었습니다.
      - 각 도메인별 서비스 테스트, 컨트롤러 테스트, 동시성 테스트, 예외 테스트 등 전반적으로 동일한 방식으로 수정되었습니다.

  5. 기타
      - 더 이상 사용하지 않는 SiteUser import 구문이 모두 제거되었습니다.
      - 일부 테스트에서는 사용자 객체 대신 ID를 사용하도록 필드 타입이 변경되었습니다.
      - 서비스 내부에서 ID 기반으로만 로직이 동작하도록 관련 코드가 일관되게 수정되었습니다.

Estimated code review effort

4 (~90분)

  • 전체적으로 컨트롤러, 서비스, 리졸버, 테스트 등 다수의 파일과 메서드 시그니처가 변경되었습니다.
  • 변경 범위는 넓으나, 패턴이 일관되고 로직 자체의 복잡도는 높지 않습니다.
  • 리뷰 시 메서드 호출 체인, 예외 처리, 인증 리졸버 동작, 테스트 케이스의 일관성 등을 꼼꼼히 확인해야 하므로 60~120분 정도의 시간이 소요될 것으로 예상됩니다.

Suggested reviewers

  • wibaek
  • Gyuhyeok99
  • whqtker
    """

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0840718 and f31acca.

📒 Files selected for processing (1)
  • src/main/java/com/example/solidconnection/community/board/controller/BoardController.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/main/java/com/example/solidconnection/community/board/controller/BoardController.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
✨ Finishing Touches
  • 📝 Generate Docstrings

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need 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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@nayonsoso nayonsoso changed the title Refactor/299 pass site user refactor: 인증된 사용자 정보를 넘겨주는 argumentResolver가 long id를 주입하도록 Jul 23, 2025
@nayonsoso nayonsoso changed the title refactor: 인증된 사용자 정보를 넘겨주는 argumentResolver가 long id를 주입하도록 refactor: 인증된 사용자 정보를 주는 argumentResolver가 long id를 주입하도록 Jul 23, 2025
Copy link

@coderabbitai coderabbitai bot left a 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: 서비스 계층 리팩토링이 올바르게 구현되었습니다.

다음 변경사항들이 정확히 적용되었습니다:

  1. 메서드 시그니처에서 SiteUser 파라미터를 long siteUserId로 변경
  2. SiteUserRepository 의존성 추가 및 USER_NOT_FOUND 에러 코드 임포트
  3. 각 메서드에서 사용자 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

📥 Commits

Reviewing files that changed from the base of the PR and between 60ee7b9 and a176925.

📒 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: 동시성 테스트에서도 리팩토링이 완벽하게 적용되었네요! ⚡

  1. likePost 메서드 호출 시 사용자 ID 전달로 변경
  2. dislikePost 메서드 호출 시 사용자 ID 전달로 변경

동시성 테스트의 핵심 로직은 그대로 유지하면서 서비스 메서드 시그니처 변경에만 깔끔하게 대응했습니다.

src/test/java/com/example/solidconnection/application/service/ApplicationSubmissionServiceTest.java (1)

84-84: 지원서 제출 서비스 테스트 전체에 리팩토링이 체계적으로 적용되었습니다! 📝

  1. 정상 지원서 제출 테스트
  2. 미승인 GPA 점수 예외 테스트
  3. 미승인 어학성적 예외 테스트
  4. 지원서 수정 횟수 초과 예외 테스트

모든 테스트 케이스에서 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: 대학 추천 서비스 테스트에서 완벽한 리팩토링이 이루어졌습니다! 🎯

  1. 관심 지역 기반 추천 테스트
  2. 관심 국가 기반 추천 테스트
  3. 지역과 국가 모두 설정된 사용자 추천 테스트
  4. 관심사 미설정 사용자 일반 추천 테스트

모든 시나리오에서 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: 지원서 조회 서비스 테스트에서 가장 포괄적인 리팩토링이 완료되었습니다! 🔍

  1. 전체 지원자 조회 테스트
  2. 특정 지역 지원자 조회 테스트
  3. 대학명 필터링 조회 테스트
  4. 이전 학기 지원자 제외 테스트
  5. 최신 지원서만 조회 테스트
  6. 경쟁자 목록 조회 테스트

getApplicantsgetApplicantsByUserApplications 두 메서드 모두에서 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: 마이페이지 서비스 테스트가 완전히 업데이트되었습니다.

다음 변경사항들이 일관되게 적용되었습니다:

  1. 서비스 메서드 호출 시 사용자 ID 전달 방식으로 변경
  2. Mock 검증에서도 userId 매개변수 기대값으로 수정 (line 137)
  3. 모든 테스트 시나리오에서 일관된 패턴 적용

리팩토링 목표에 부합하는 완성도 높은 변경입니다.

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: 게시글 커맨드 서비스 테스트가 체계적으로 업데이트되었습니다.

다음과 같이 포괄적인 변경이 이루어졌습니다:

  1. 게시글 생성/수정/삭제 모든 시나리오에서 사용자 ID 전달 방식 적용
  2. 정상 케이스와 예외 케이스 모두 일관되게 수정
  3. 권한 검증 테스트에서도 올바른 사용자 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: 테스트 메서드 시그니처 변경이 올바르게 적용되었습니다!

  1. GPA 점수 상태 조회 테스트들이 user.getId()를 사용하도록 변경
  2. 어학 시험 점수 상태 조회 테스트들이 user.getId()를 사용하도록 변경
  3. 점수 등록 테스트들이 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: 댓글 서비스 테스트의 메서드 시그니처 변경이 완벽하게 적용되었습니다!

  1. 댓글 조회 테스트들이 user1.getId() 사용으로 변경
  2. 댓글 생성 테스트들이 user1.getId(), user2.getId() 사용으로 변경
  3. 댓글 수정 테스트들이 사용자 ID 기반으로 변경
  4. 댓글 삭제 테스트들이 사용자 ID 기반으로 변경
  5. 예외 처리 테스트들까지 모두 일관되게 적용

모든 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 메서드가 올바르게 리팩토링되었습니다!

  1. 메서드 시그니처가 SiteUser 객체에서 long siteUserId로 변경
  2. USER_NOT_FOUND 에러 코드 import 추가
  3. 표준 패턴의 사용자 조회 및 예외 처리 구현: siteUserRepository.findById().orElseThrow()

DIP 원칙을 준수하면서 코드 중복을 줄이는 일관된 패턴이 적용되었습니다.

Also applies to: 113-115

src/test/java/com/example/solidconnection/mentor/service/MentorQueryServiceTest.java (1)

66-66: 멘토 조회 서비스 테스트의 메서드 시그니처 변경이 완벽하게 구현되었습니다!

  1. getMentorDetails 메서드 호출이 siteUser.getId() 사용으로 변경
  2. getMentorPreviews 메서드 호출이 currentUser.getId() 사용으로 변경
  3. 성공 및 실패 시나리오 테스트 모두 일관되게 적용
  4. 복잡한 멀티 사용자 테스트 시나리오도 안전하게 유지

멘토링 관련 모든 조회 기능이 새로운 아키텍처에 맞춰 체계적으로 업데이트되었습니다.

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: 탈퇴 테스트가 더욱 견고하게 개선되었습니다!

  1. quit 메서드 호출이 user.getId() 사용으로 변경되어 새로운 시그니처에 맞춰짐
  2. 테스트 검증 로직이 개선됨: 데이터베이스에서 엔티티를 다시 로드하여 실제 영속성 상태를 확인
  3. 메모리 상의 객체가 아닌 실제 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: 리팩터링이 깔끔하게 적용되었습니다!

  1. 메서드 시그니처가 도메인 객체에서 기본형으로 변경되어 DIP 원칙을 준수합니다
    • SiteUserlong siteUserId로 변경
  2. 레포지토리 호출 시 사용자 ID를 직접 전달하도록 수정되었습니다
    • 별도의 SiteUser 엔티티 조회가 불필요하여 효율적입니다
src/main/java/com/example/solidconnection/news/service/NewsCommandService.java (3)

5-5: 필요한 에러 코드가 추가되었습니다.

사용자 조회 실패 시 사용할 USER_NOT_FOUND 에러 코드를 적절히 임포트했습니다.


19-19: 의존성 주입이 올바르게 추가되었습니다.

  1. SiteUserRepository 임포트 추가
  2. 서비스 내에서 사용자 엔티티 조회를 위한 의존성 주입

서비스 계층에서 사용자 검증을 담당하는 구조로 변경되었습니다.

Also applies to: 32-32


83-85: 메서드 시그니처 변경과 사용자 검증 로직이 적절합니다.

  1. 파라미터가 도메인 객체에서 기본형으로 변경됨
    • SiteUser siteUserlong siteUserId
  2. 서비스 내에서 사용자 엔티티 조회 및 검증 수행
    • USER_NOT_FOUND 예외로 적절한 에러 처리

DIP 원칙을 준수하면서도 기존 로직의 무결성을 유지합니다.

src/main/java/com/example/solidconnection/community/post/service/PostQueryService.java (2)

57-59: 메서드 시그니처 변경과 사용자 검증 로직이 일관성 있게 적용되었습니다.

  1. 파라미터 타입 변경으로 DIP 원칙 준수
    • SiteUser siteUserlong siteUserId
  2. 서비스 내부에서 사용자 엔티티 조회 및 존재성 검증
    • 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: 사용자 조회를 위한 의존성이 올바르게 추가되었습니다.

  1. SiteUserRepository 임포트 및 의존성 주입 추가
  2. 서비스 계층에서 사용자 엔티티 조회 담당하는 구조로 변경

아키텍처 개선 목표와 일치합니다.

Also applies to: 38-38


46-48: 리팩터링 패턴이 일관되게 적용되었습니다.

  1. 메서드 파라미터가 도메인 객체에서 기본형으로 변경
    • DIP 원칙 준수로 계층 간 의존성 개선
  2. 서비스 내부에서 사용자 엔티티 조회 및 검증 수행
    • 중앙화된 사용자 검증 로직

전체 코드베이스에서 일관된 패턴이 적용되고 있습니다.

src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java (4)

5-5: 에러 처리를 위한 상수가 적절히 추가되었습니다.

사용자 조회 실패 시 사용할 USER_NOT_FOUND 에러 코드를 임포트했습니다.


15-15: 사용자 엔티티 조회를 위한 의존성이 추가되었습니다.

  1. SiteUserRepository 임포트 추가
  2. 서비스 의존성 주입으로 사용자 검증 기능 구현

리팩터링 목표에 맞는 변경사항입니다.

Also applies to: 30-30


33-35: getMentorMyPage 메서드가 올바르게 리팩터링되었습니다.

  1. 파라미터 타입 변경으로 DIP 원칙 준수
    • SiteUser siteUserlong siteUserId
  2. 서비스 내부에서 사용자 엔티티 조회 및 검증
    • 응답 생성에 필요한 SiteUser 객체를 안전하게 획득

42-44: updateMentorMyPage 메서드가 효율적으로 리팩터링되었습니다.

  1. 파라미터가 기본형으로 변경되어 DIP 원칙 준수
    • SiteUser siteUserlong siteUserId
  2. 멘토 조회 시 사용자 ID를 직접 사용하여 효율적 구현
    • 별도 SiteUser 엔티티 조회 불필요

각 메서드의 요구사항에 맞게 적절히 최적화되었습니다.

src/main/java/com/example/solidconnection/siteuser/service/MyPageService.java (3)

37-39: ✅ 리팩토링 패턴이 올바르게 적용되었습니다

  1. 메서드 시그니처가 SiteUser 객체에서 long siteUserId로 정확히 변경되었습니다
  2. 서비스 내부에서 사용자 조회와 예외 처리가 적절히 구현되었습니다

48-50: ✅ 일관된 리팩토링 패턴 적용 확인

updateMyPageInfo 메서드도 동일한 패턴으로 올바르게 변경되었습니다.


62-62: ✅ S3Service 호출부도 일관되게 수정되었습니다

s3Service.deleteExProfile(user.getId())로 변경되어 전체 리팩토링과 일치합니다.

src/main/java/com/example/solidconnection/community/post/service/PostLikeService.java (3)

4-4: ✅ 필요한 의존성과 임포트가 올바르게 추가되었습니다

  1. USER_NOT_FOUND ErrorCode 임포트 추가
  2. 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 계층이 올바르게 리팩토링되었습니다

  1. @AuthorizedUser long siteUserId 파라미터로 정확히 변경
  2. 서비스 호출시 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가 일관된 패턴으로 리팩토링되었습니다

  1. @AuthorizedUser long siteUserId 파라미터 변경
  2. 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 메서드가 효율적으로 리팩토링되었습니다

  1. 파라미터가 long currentUserId로 변경
  2. 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: 의존성 추가가 적절하게 처리되었습니다

다음과 같은 변경사항들이 올바르게 구현되었습니다:

  1. USER_NOT_FOUND 에러 코드 import 추가
  2. SiteUserRepository 의존성 주입 추가
  3. 리포지토리 필드 선언

이러한 변경으로 사용자 검증 로직이 서비스 계층으로 적절히 이동되었습니다.

Also applies to: 25-25, 41-41


47-50: 사용자 검증 로직이 명확하게 개선되었습니다

createPost 메서드에서 다음과 같은 개선사항을 확인할 수 있습니다:

  1. 메서드 시그니처가 SiteUser 객체에서 long siteUserId로 변경
  2. 명시적인 사용자 존재 확인 및 예외 처리
  3. DIP 원칙 준수를 통한 계층 간 결합도 감소

이 접근 방식은 도메인 객체를 직접 전달하는 것보다 더 안전하고 명확합니다.


67-70: 업데이트 메서드의 일관된 리팩토링

updatePost 메서드도 동일한 패턴으로 개선되었습니다:

  1. 원시 타입 매개변수 사용
  2. 동일한 사용자 검증 로직 적용
  3. 기존 비즈니스 로직 유지

전체 서비스에서 일관된 접근 방식을 유지하고 있어 좋습니다.


99-101: 삭제 메서드의 완전한 통합

deletePostById 메서드도 완벽하게 리팩토링되었습니다:

  1. 동일한 매개변수 타입 변경
  2. 일관된 사용자 검증 패턴
  3. 코드 중복 최소화

모든 메서드가 동일한 검증 패턴을 따르고 있어 유지보수성이 크게 향상되었습니다.

src/main/java/com/example/solidconnection/mentor/controller/MentorController.java (2)

32-32: 멘토 상세 조회 메서드의 깔끔한 리팩토링

다음과 같은 개선사항이 적용되었습니다:

  1. @AuthorizedUser SiteUser에서 @AuthorizedUser long siteUserId로 매개변수 타입 변경
  2. 서비스 호출 시 사용자 ID만 전달하도록 수정

컨트롤러 계층에서 도메인 객체 의존성이 제거되어 더 깔끔한 아키텍처가 구현되었습니다.

Also applies to: 35-35


41-41: 멘토 목록 조회 메서드의 일관된 변경

getMentorPreviews 메서드도 동일한 패턴으로 개선되었습니다:

  1. 원시 타입 매개변수 사용
  2. 서비스 메서드 호출 방식 통일
  3. 전체 컨트롤러의 일관성 유지

모든 메서드가 동일한 접근 방식을 따르고 있어 코드의 일관성이 훌륭합니다.

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 메서드가 다음과 같이 개선되었습니다:

  1. SiteUser 매개변수를 long siteUserId로 변경
  2. 명시적인 사용자 존재 확인 로직 추가
  3. 기존 댓글 필터링 및 응답 생성 로직 유지

사용자 검증이 메서드 초기에 수행되어 더 안전한 구조가 되었습니다.


89-91: 댓글 생성 메서드의 일관된 패턴 적용

createComment 메서드도 동일한 리팩토링 패턴이 적용되었습니다:

  1. 원시 타입 매개변수 사용
  2. 동일한 사용자 검증 로직
  3. 비즈니스 로직의 완전한 보존

전체 서비스에서 통일된 접근 방식이 유지되고 있습니다.


113-115: 수정 및 삭제 메서드의 완전한 통합

updateCommentdeleteCommentById 메서드들이 모두 일관되게 리팩토링되었습니다:

  1. 동일한 매개변수 타입 변경 패턴
  2. 통일된 사용자 검증 로직
  3. 복잡한 댓글 삭제 로직도 안전하게 보존

모든 메서드가 동일한 검증 패턴을 따르면서도 각각의 고유한 비즈니스 로직은 완벽히 유지되었습니다.

Also applies to: 132-134

src/main/java/com/example/solidconnection/university/service/LikedUnivApplyInfoService.java (4)

34-35: 좋아요 목록 조회의 효율적인 개선

getLikedUnivApplyInfos 메서드가 다음과 같이 최적화되었습니다:

  1. SiteUser 객체 대신 long siteUserId 직접 사용
  2. 불필요한 사용자 엔티티 조회 제거
  3. 더 간결하고 효율적인 데이터 접근

사용자 ID만 필요한 로직에서는 이 방식이 성능상 더 유리합니다.


45-45: 좋아요 추가 메서드의 깔끔한 단순화

addUnivApplyInfoLike 메서드가 효율적으로 리팩토링되었습니다:

  1. 매개변수 타입을 원시 long으로 변경
  2. 리포지토리 조회에서 직접 사용자 ID 활용
  3. 엔티티 생성 시에도 ID 직접 사용

전체 로직이 더 직관적이고 성능상 이점이 있는 구조로 개선되었습니다.

Also applies to: 48-48, 55-55


64-64: 좋아요 취소 메서드의 일관된 적용

cancelUnivApplyInfoLike 메서드도 동일한 최적화 패턴이 적용되었습니다:

  1. 원시 타입 매개변수 사용
  2. 직접적인 ID 기반 리포지토리 조회
  3. 불필요한 객체 변환 제거

전체 서비스의 일관성과 효율성이 모두 향상되었습니다.

Also applies to: 67-67


79-79: 좋아요 상태 확인의 완벽한 통합

isUnivApplyInfoLiked 메서드가 완전히 리팩토링되었습니다:

  1. 동일한 매개변수 타입 변경
  2. 일관된 ID 기반 처리 방식
  3. 간결한 boolean 반환 로직

모든 메서드가 통일된 접근 방식을 따르면서도 각각의 목적에 최적화된 구조를 갖추었습니다.

Also applies to: 81-81

src/main/java/com/example/solidconnection/score/service/ScoreService.java (4)

3-3: 의존성 및 import 추가가 완벽하게 처리됨

다음과 같은 변경사항들이 올바르게 구현되었습니다:

  1. USER_NOT_FOUND 에러 코드 import 추가
  2. CustomException import 추가
  3. SiteUserRepository 의존성 주입 추가
  4. 리포지토리 필드 선언

모든 필수 의존성이 적절히 추가되어 사용자 검증 로직을 지원합니다.

Also applies to: 7-7, 22-22, 37-37


40-42: GPA 점수 제출 메서드의 안전한 리팩토링

submitGpaScore 메서드가 다음과 같이 개선되었습니다:

  1. SiteUser 매개변수를 long siteUserId로 변경
  2. 명시적인 사용자 존재 확인 및 예외 처리
  3. 파일 업로드 및 엔티티 생성 로직 완전 보존

사용자 검증이 비즈니스 로직 실행 전에 수행되어 더 안전한 구조가 되었습니다.


51-53: 언어 시험 점수 제출의 일관된 패턴

submitLanguageTestScore 메서드도 동일한 리팩토링 패턴이 적용되었습니다:

  1. 원시 타입 매개변수 사용
  2. 동일한 사용자 검증 로직
  3. 복잡한 파일 업로드 로직 안전하게 보존

전체 서비스에서 통일된 접근 방식이 유지되고 있습니다.


63-65: 점수 상태 조회 메서드들의 완전한 통합

getGpaScoreStatusgetLanguageTestScoreStatus 메서드들이 모두 일관되게 리팩토링되었습니다:

  1. 동일한 매개변수 타입 변경 패턴
  2. 통일된 사용자 검증 로직
  3. 복잡한 응답 생성 로직도 완벽히 보존

모든 메서드가 동일한 검증 패턴을 따르면서도 각각의 고유한 비즈니스 로직은 완전히 유지되었습니다.

Also applies to: 76-78

src/main/java/com/example/solidconnection/community/comment/controller/CommentController.java (1)

30-30: 인증 사용자 파라미터 리팩토링이 올바르게 적용되었습니다.

다음 변경사항들이 정확히 구현되었습니다:

  1. @AuthorizedUser SiteUser siteUser에서 @AuthorizedUser long siteUserId로 파라미터 타입 변경
  2. 서비스 메서드 호출 시 도메인 객체 대신 ID 값 전달
  3. 컨트롤러 계층에서 도메인 객체 의존성 제거

이러한 변경으로 의존성 역전 원칙(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의 모든 메서드에서 다음 변경사항들이 일관되게 구현되었습니다:

  1. 인증 사용자 파라미터를 SiteUser 객체에서 long siteUserId로 변경
  2. 서비스 계층 호출 시 일관되게 사용자 ID 전달
  3. 도메인 객체 직접 전달 방식 제거

특히 권한 검증이 필요한 메서드들에서도 동일한 패턴이 적용된 것이 좋습니다.

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: 인증 사용자 리졸버 리팩토링이 매우 잘 구현되었습니다.

다음 핵심 개선사항들이 탁월하게 적용되었습니다:

  1. longLong 타입 모두 지원하는 유연한 파라미터 타입 처리
  2. 인증 컨텍스트에서 사용자 ID만 추출하는 깔끔한 로직
  3. 특히 우수한 점: primitive 타입에 대한 NPE 방지 로직 구현
  4. 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: 멘토링 컨트롤러의 리팩토링이 완벽하게 완료되었습니다.

모든 컨트롤러 메서드에서 일관된 변경이 적용되었습니다:

  1. 5개 메서드 모두에서 @AuthorizedUser SiteUser@AuthorizedUser long siteUserId로 변경
  2. 권한 검증이 필요한 메서드들(@RequireRoleAccess)에서도 동일한 패턴 적용
  3. 서비스 호출 시 일관되게 사용자 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: 인증 사용자 파라미터 타입 변경이 적절히 적용되었습니다

다음과 같은 개선점들이 잘 구현되었습니다:

  1. 선택적 인증 처리: @AuthorizedUser(required = false) Long siteUserId로 nullable 타입 사용
  2. 적절한 null 체크: 인증되지 않은 사용자를 위한 일반 추천과 개인화 추천을 구분 처리
  3. 서비스 호출 단순화: SiteUser 객체 대신 siteUserId를 직접 전달

이는 DIP 원칙을 준수하면서도 코드의 가독성을 높이는 좋은 구현입니다.


46-49: 필수 인증이 필요한 엔드포인트의 primitive long 사용이 적절합니다

좋아요 목록 조회는 반드시 로그인된 사용자만 접근할 수 있으므로 @AuthorizedUser long siteUserId 사용이 맞습니다. 이는 ArgumentResolver에서 인증 실패 시 예외를 발생시켜 안전성을 보장합니다.


54-67: 좋아요 관련 엔드포인트들의 일관된 리팩터링

다음 항목들이 일관성 있게 적용되었습니다:

  1. 매개변수 타입 통일: 모든 좋아요 관련 메서드에서 long siteUserId 사용
  2. 서비스 호출 단순화: 객체 전달 대신 ID만 전달하여 의존성 역전 원칙 준수
  3. 메서드 시그니처 일관성: 조회, 추가, 삭제 모든 액션에서 동일한 패턴 적용

코드 중복을 줄이면서도 계층 간 결합도를 낮추는 좋은 설계입니다.

src/test/java/com/example/solidconnection/common/resolver/AuthorizedUserResolverTest.java (3)

46-56: 테스트 검증 로직이 새로운 resolver 동작에 맞게 잘 업데이트되었습니다

다음과 같은 개선점들이 적절히 반영되었습니다:

  1. 반환 타입 변경: SiteUser 객체 대신 Long 타입의 사용자 ID 검증
  2. 실제 값 비교: user.getId()resolvedUserId 직접 비교로 정확성 향상
  3. null 안전성: 반환된 ID가 null이 아님을 먼저 확인하는 방어적 코딩

이는 리팩터링된 AuthorizedUserResolver의 새로운 동작을 정확히 테스트합니다.


61-70: primitive 타입 파라미터에 대한 새로운 예외 처리 테스트가 잘 추가되었습니다

중요한 보안 검증 로직이 제대로 테스트되고 있습니다:

  1. primitive long 파라미터: 인증 실패 시 NullPointerException 방지를 위한 예외 발생 검증
  2. 적절한 예외 타입: CustomExceptionAUTHENTICATION_FAILED 메시지 확인
  3. 안전성 보장: required가 기본값인 primitive 타입의 안전한 처리 확인

ArgumentResolver의 핵심 보안 로직에 대한 테스트 커버리지가 훌륭합니다.


100-123: reflection 기반 MethodParameter 생성으로 테스트 현실성이 크게 향상되었습니다

다음과 같은 장점들을 제공합니다:

  1. 실제 어노테이션 사용: 수동 mock 대신 실제 @AuthorizedUser 어노테이션 활용
  2. 다양한 파라미터 타입 지원: Long, long, required=true/false 등 모든 케이스 커버
  3. 유지보수성 향상: TestController의 메서드 시그니처 변경만으로 테스트 케이스 확장 가능
  4. 예외 처리 단순화: checked exception을 unchecked로 변환하여 테스트 코드 가독성 향상

테스트의 정확성과 유지보수성을 동시에 개선한 훌륭한 리팩터링입니다.

src/main/java/com/example/solidconnection/score/controller/ScoreController.java (2)

30-36: 성적 관련 엔드포인트의 인증 사용자 파라미터 리팩터링이 잘 적용되었습니다

다음과 같은 일관된 패턴이 적용되었습니다:

  1. primitive long 사용: 모든 성적 관련 기능은 필수 인증이므로 적절함
  2. 서비스 호출 단순화: siteUser 객체 대신 siteUserId만 전달
  3. 계층간 결합도 감소: Controller에서 Service로 도메인 객체를 직접 전달하지 않음

성적 제출이라는 민감한 기능에 대해 안전하고 일관된 인증 처리가 구현되었습니다.


41-65: 모든 성적 관리 메서드에서 일관된 리팩터링 패턴 적용

각 메서드별로 다음과 같이 적절히 수정되었습니다:

  1. 어학성적 제출 (line 41-46): siteUserId 파라미터로 변경 및 서비스 호출 업데이트
  2. 학점 상태 조회 (line 52-55): 동일한 패턴으로 사용자 ID 기반 조회
  3. 어학성적 상태 조회 (line 61-64): 일관된 파라미터 처리

모든 성적 관리 기능에서 DIP 원칙을 준수하면서도 코드 가독성을 유지한 좋은 구현입니다.

src/main/java/com/example/solidconnection/news/controller/NewsController.java (3)

49-55: 뉴스 생성 엔드포인트의 인증 사용자 처리가 적절히 개선되었습니다

다음과 같은 개선 사항들이 잘 구현되었습니다:

  1. Role 기반 접근제어 유지: @RequireRoleAccess 어노테이션은 그대로 보존
  2. 파라미터 단순화: SiteUser 객체 대신 long siteUserId로 간소화
  3. 서비스 레이어 분리: 도메인 객체 전달 대신 ID만 전달하여 계층 간 결합도 감소

ADMIN과 MENTOR만 뉴스를 생성할 수 있다는 보안 요구사항을 유지하면서도 코드 구조를 개선했습니다.


59-71: 뉴스 수정 및 삭제 엔드포인트의 일관된 리팩터링

권한이 필요한 작업들에 대해 일관된 개선이 이루어졌습니다:

  1. 수정 기능 (line 59-71): siteUserId 파라미터 적용 및 서비스 호출 단순화
  2. 삭제 기능 (line 75-81): 동일한 패턴으로 사용자 ID 기반 처리
  3. 보안 일관성: 두 기능 모두 ADMIN/MENTOR 권한과 인증 사용자 검증 유지

중요한 데이터 변경 작업에서 보안성을 유지하면서도 코드 품질을 개선한 좋은 구현입니다.


84-108: 뉴스 좋아요 관련 기능들의 체계적인 리팩터링

사용자 상호작용 기능들이 일관되게 개선되었습니다:

  1. 좋아요 상태 확인 (line 84-90): siteUserId로 간소화된 사용자 식별
  2. 좋아요 추가 (line 92-99): 동일한 패턴으로 서비스 호출 최적화
  3. 좋아요 취소 (line 101-108): 일관된 사용자 ID 기반 처리

모든 좋아요 관련 기능에서 DIP 원칙을 준수하면서도 API 일관성을 유지한 훌륭한 설계입니다.

src/main/java/com/example/solidconnection/community/post/controller/PostController.java (4)

42-51: 게시글 생성 엔드포인트의 사용자 인증 처리가 효율적으로 개선되었습니다

다음과 같은 개선점들이 적절히 구현되었습니다:

  1. 파라미터 단순화: SiteUser 객체 대신 long siteUserId 사용으로 간소화
  2. 파일 업로드 로직 보존: 이미지 파일 처리 로직은 그대로 유지하여 기능 안정성 확보
  3. 서비스 호출 최적화: 도메인 객체 전달 없이 ID만 전달하여 계층 간 결합도 감소

게시글 작성이라는 핵심 기능에서 보안성과 효율성을 동시에 개선했습니다.


54-67: 게시글 수정 기능의 체계적인 리팩터링

수정 기능에 대해 일관된 개선이 이루어졌습니다:

  1. 사용자 인증: long siteUserId로 간소화된 사용자 식별
  2. 서비스 파라미터: 다중 파라미터 전달에서 사용자 ID 부분만 깔끔하게 변경
  3. 파일 처리 유지: 이미지 업로드 로직의 안정성 보장

복잡한 수정 로직에서도 사용자 관련 처리만 선별적으로 개선한 좋은 접근입니다.


70-85: 게시글 조회 및 삭제 기능의 일관된 사용자 처리

읽기와 삭제 작업에 대해 통일된 패턴이 적용되었습니다:

  1. 조회 기능 (line 70-76): 인증된 사용자 기준 게시글 상세 조회 최적화
  2. 삭제 기능 (line 78-85): 동일한 siteUserId 패턴으로 권한 검증 단순화
  3. 응답 일관성: 기존 응답 구조 유지하면서 내부 처리만 개선

사용자 권한이 중요한 작업들에서 안전성을 유지하면서 코드 품질을 향상시켰습니다.


88-103: 게시글 좋아요/싫어요 기능의 완전한 리팩터링

사용자 상호작용 기능들이 체계적으로 개선되었습니다:

  1. 좋아요 추가 (line 88-94): siteUserId 기반의 간소화된 처리
  2. 좋아요 취소 (line 96-103): 일관된 패턴으로 사용자 식별 및 서비스 호출
  3. API 일관성: 두 기능 모두 동일한 사용자 인증 처리 방식 적용

커뮤니티의 핵심 기능인 좋아요 시스템에서 DIP 원칙을 준수하면서도 사용자 경험을 보장하는 훌륭한 구현입니다.

@nayonsoso nayonsoso force-pushed the refactor/299-pass-site-user-id branch from a176925 to 727ebc3 Compare July 23, 2025 02:07
@nayonsoso nayonsoso changed the title refactor: 인증된 사용자 정보를 주는 argumentResolver가 long id를 주입하도록 refactor: 인증 정보 argumentResolver가 long siteUserId를 주입하도록 Jul 23, 2025
Copy link
Member

@whqtker whqtker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

고생하셨습니다 ~ 익숙치 않아서 그런가 인증 인가가 쉽지 않네요 .. ㅠㅠ
BoardControllerSiteUser 를 인자로 받고 있는 부분이 있어, 해당 부분만 수정하면 완벽한 것 같습니다 !

return true;
}
AuthorizedUser authorizedUser = parameter.getParameterAnnotation(AuthorizedUser.class);
return authorizedUser != null && authorizedUser.required();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

일반적인 경우라면 authorizedUsernull 이 아니지만 작성하신 것처럼 authorizedUser != null 를 추가하는 거 좋은 것 같습니다 !

@nayonsoso
Copy link
Collaborator Author

고생하셨습니다 ~ 익숙치 않아서 그런가 인증 인가가 쉽지 않네요 .. ㅠㅠ

ㅠㅠ 처음 보셨다면 코드리뷰 하기 어려우셨을 것 같아요..
제가 다음 개발 회의에서 인증/인가 발표(?)를 해보겠습니다!
코드리뷰 하시느라 고생하셨어요~ 🪭🪭

BoardControllerSiteUser 를 인자로 받고 있는 부분이 있어, 해당 부분만 수정하면 완벽한 것 같습니다 !

수정했습니다! 꼼꼼한 확인 감사드려요 😊

Copy link
Member

@whqtker whqtker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

변경사항 확인했습니다 !

Copy link
Contributor

@lsy1307 lsy1307 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

헉 서비스단까지 다 수정해주셨네요 ㅜㅜ 고생하셨습니다 진짜

@nayonsoso nayonsoso merged commit a08689c into solid-connection:develop Jul 24, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

refactor: 컨트롤러에서 SiteUser를 인자로 받지 않도록 한다.

3 participants