Conversation
WalkthroughThis update refactors member preference and association management across the codebase, replacing the Changes
Sequence Diagram(s)sequenceDiagram
participant Controller
participant MemberPreferenceServiceImpl
participant MemberRepository
participant PreferredThemeRepository
participant ThemeRepository
Controller->>MemberPreferenceServiceImpl: updateTheme(memberId, requestDTO)
MemberPreferenceServiceImpl->>MemberRepository: getById(memberId)
MemberPreferenceServiceImpl->>ThemeRepository: getByThemeType(themeType)
MemberPreferenceServiceImpl->>PreferredThemeRepository: deleteByMemberId(memberId)
loop for each themeType in requestDTO
MemberPreferenceServiceImpl->>PreferredThemeRepository: save(PreferredTheme.of(member, theme))
end
MemberPreferenceServiceImpl-->>Controller: MemberUpdateDTO
Poem
✨ Finishing Touches
🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (4)
src/main/java/com/example/spot/study/application/StudyCommandServiceImpl.java (3)
252-256: Fix duplicate method call.There's a duplicate call to
study.addMemberStudy(studyMember)on lines 252 and 255, which could cause issues with entity state management.study.addMemberStudy(studyMember); studyMemberRepository.save(studyMember); - - study.addMemberStudy(studyMember);
273-278: Fix duplicate method call.There's a duplicate call to
study.addRegionStudy(studyRegion)on lines 274 and 277, which could cause issues with entity state management.region.addRegionStudy(studyRegion); study.addRegionStudy(studyRegion); studyRegionRepository.save(studyRegion); - - study.addRegionStudy(studyRegion);
294-299: Fix duplicate method call.There's a duplicate call to
study.addStudyTheme(studyTheme)on lines 294 and 298, which could cause issues with entity state management.study.addStudyTheme(studyTheme); theme.addStudyTheme(studyTheme); studyThemeRepository.save(studyTheme); - - study.addStudyTheme(studyTheme);src/main/java/com/example/spot/schedule/application/ScheduleCommandServiceImpl.java (1)
172-196: Potential bug: Missing break statements in switch cases.The switch statement for schedule period validation is missing
breakstatements, causing fall-through behavior. This means all validations will execute regardless of the period type.Add break statements to fix the logic:
switch (scheduleRequestDTO.getSchedulePeriod()) { case DAILY: // 시작일과 종료일이 일치해야 함 if (finishDate.equals(startDate.plusDays(1)) || finishDate.isAfter(startDate.plusDays(1))) { throw new StudyHandler(ErrorStatus._STUDY_SCHEDULE_WRONG_FORMAT); } + break; case WEEKLY: // 시작일과 종료일이 일주일 이상 차이나지 않아야 함 if (finishDate.equals(startDate.plusWeeks(1)) || finishDate.isAfter(startDate.plusWeeks(1))) { throw new StudyHandler(ErrorStatus._STUDY_SCHEDULE_WRONG_FORMAT); } + break; case BIWEEKLY: // 시작일과 종료일이 2주 이상 차이나지 않아야 함 if (finishDate.equals(startDate.plusWeeks(2)) || finishDate.isAfter(startDate.plusWeeks(2))) { throw new StudyHandler(ErrorStatus._STUDY_SCHEDULE_WRONG_FORMAT); } + break; case MONTHLY: // 시작일과 종료일이 한 달 이상 차이나지 않아야 함 if (finishDate.equals(startDate.plusMonths(1)) || finishDate.isAfter(startDate.plusMonths(1))) { throw new StudyHandler(ErrorStatus._STUDY_SCHEDULE_WRONG_FORMAT); } + break; }
🧹 Nitpick comments (8)
src/main/java/com/example/spot/todo/application/impl/ManageToDoUseCaseImpl.java (1)
8-9: Import updated – consider a lighterexists…query forisMember
While the package switch is fine, theisMemberhelper still loads an entireStudyMemberinstance viafindBy…just to test existence. A leanexistsByMemberIdAndStudyIdAndStatusrepository method would avoid mapping overhead and reduce DB traffic.src/main/java/com/example/spot/member/infrastructure/PreferredRegionRepository.java (2)
1-3: Repository interface now lives in infrastructure – double-check layering rulesMoving the repository interface itself (not just the implementation) into
infrastructurebreaks the typical hexagonal / onion layering where the port lives in the domain and only the implementation is placed in infrastructure.
If that architectural principle is still desired elsewhere, consider leaving the interface incom.example.spot.member.domainand providing an@Repositoryimplementation here instead. Otherwise, make sure all teams agree on this new layering convention.
11-15: Return the delete count (optional)
void deleteByMemberId(Long memberId)gives no feedback. Returninglong(rows deleted) is often handy for auditing or quick assertions in tests:- void deleteByMemberId(Long memberId); + long deleteByMemberId(Long memberId);Spring-Data will still generate the same query and wire it automatically.
src/main/java/com/example/spot/member/infrastructure/PreferredStudyRepository.java (1)
1-4: Same layering comment as PreferredRegionRepositoryIf the project intends to follow a clean-architecture style, keep the repository port inside the domain module and place only the implementation in infrastructure.
Otherwise, no functional issue – just confirm team convention.src/main/java/com/example/spot/post/application/command/impl/ManagePostCommentUseCaseImpl.java (1)
30-37: Minor Javadoc nit – align parameter order
@param memberIdis listed beforerequestin the signature but after it in the Javadoc. Swapping lines keeps docs in sync:- * @param request 작성할 댓글 정보 - * @return ... + * @param request 작성할 댓글 정보 + * @return ...src/main/java/com/example/spot/study/domain/association/Theme.java (1)
55-58: Consider renaming method to reflect the new parameter type.The method name
addMemberThememight be misleading since it now accepts aPreferredThemeparameter. Consider renaming toaddPreferredThemefor better clarity.- public void addMemberTheme(PreferredTheme preferredTheme) { + public void addPreferredTheme(PreferredTheme preferredTheme) { preferredThemeList.add(preferredTheme); preferredTheme.setTheme(this); }src/main/java/com/example/spot/member/domain/Member.java (1)
1-124: Excellent architectural decision to remove bidirectional relationships.The removal of all collection fields from the Member entity (as mentioned in the PR summary) is a significant improvement that:
- Reduces coupling between entities
- Prevents N+1 query problems
- Simplifies transaction boundaries
- Makes the domain model more maintainable
Consider documenting this architectural decision in the project's technical documentation or ADR (Architecture Decision Record) for future reference.
src/main/java/com/example/spot/member/application/refactor/impl/MemberPreferenceServiceImpl.java (1)
247-265: Clean validation logic extraction.The validation helper methods properly check for empty results and throw domain-specific exceptions. This maintains consistency across all preference retrieval methods.
Consider creating a generic validation method to further reduce duplication:
+private <T> void validateNotEmpty(List<T> items, ErrorStatus errorStatus) { + if (items.isEmpty()) { + throw new MemberHandler(errorStatus); + } +} private void validatePreferredThemeIsEmpty(List<PreferredTheme> preferredThemes) { - if (preferredThemes.isEmpty()) { - throw new MemberHandler(ErrorStatus._MEMBER_THEME_NOT_FOUND); - } + validateNotEmpty(preferredThemes, ErrorStatus._MEMBER_THEME_NOT_FOUND); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (55)
src/main/java/com/example/spot/auth/application/legacy/AuthServiceImpl.java(20 hunks)src/main/java/com/example/spot/auth/application/refactor/impl/JwtTokenServiceImpl.java(1 hunks)src/main/java/com/example/spot/auth/application/refactor/impl/KakaoAuthServiceImpl.java(1 hunks)src/main/java/com/example/spot/common/application/admin/AdminServiceImpl.java(4 hunks)src/main/java/com/example/spot/common/security/oauth/CustomOAuth2UserService.java(2 hunks)src/main/java/com/example/spot/common/security/oauth/CustomOAuthSuccessHandler.java(3 hunks)src/main/java/com/example/spot/member/application/legacy/MemberServiceImpl.java(3 hunks)src/main/java/com/example/spot/member/application/refactor/impl/MemberInfoServiceImpl.java(1 hunks)src/main/java/com/example/spot/member/application/refactor/impl/MemberPreferenceServiceImpl.java(1 hunks)src/main/java/com/example/spot/member/application/refactor/impl/MemberTestSupportServiceImpl.java(1 hunks)src/main/java/com/example/spot/member/domain/Member.java(2 hunks)src/main/java/com/example/spot/member/domain/association/MemberThemeRepository.java(0 hunks)src/main/java/com/example/spot/member/domain/association/PreferredRegion.java(3 hunks)src/main/java/com/example/spot/member/domain/association/PreferredTheme.java(3 hunks)src/main/java/com/example/spot/member/domain/association/StudyJoinReason.java(3 hunks)src/main/java/com/example/spot/member/domain/validation/validator/ExistMemberValidator.java(2 hunks)src/main/java/com/example/spot/member/infrastructure/MemberRepository.java(2 hunks)src/main/java/com/example/spot/member/infrastructure/PreferredRegionRepository.java(1 hunks)src/main/java/com/example/spot/member/infrastructure/PreferredStudyRepository.java(2 hunks)src/main/java/com/example/spot/member/infrastructure/PreferredThemeRepository.java(1 hunks)src/main/java/com/example/spot/member/infrastructure/StudyJoinReasonRepository.java(1 hunks)src/main/java/com/example/spot/post/application/command/impl/LikePostCommentUseCaseImpl.java(7 hunks)src/main/java/com/example/spot/post/application/command/impl/LikePostUseCaseImpl.java(3 hunks)src/main/java/com/example/spot/post/application/command/impl/ManagePostCommentUseCaseImpl.java(2 hunks)src/main/java/com/example/spot/post/application/command/impl/ManagePostUseCaseImpl.java(5 hunks)src/main/java/com/example/spot/post/application/command/impl/ScrapPostUseCaseImpl.java(4 hunks)src/main/java/com/example/spot/report/application/ReportCommandServiceImpl.java(3 hunks)src/main/java/com/example/spot/schedule/application/ScheduleCommandServiceImpl.java(13 hunks)src/main/java/com/example/spot/schedule/application/ScheduleQueryServiceImpl.java(12 hunks)src/main/java/com/example/spot/story/application/StoryCommandServiceImpl.java(30 hunks)src/main/java/com/example/spot/story/application/StoryQueryServiceImpl.java(5 hunks)src/main/java/com/example/spot/story/domain/Story.java(2 hunks)src/main/java/com/example/spot/study/application/StudyCommandServiceImpl.java(7 hunks)src/main/java/com/example/spot/study/application/StudyMemberCommandServiceImpl.java(8 hunks)src/main/java/com/example/spot/study/application/StudyMemberQueryServiceImpl.java(6 hunks)src/main/java/com/example/spot/study/application/StudyQueryServiceImpl.java(26 hunks)src/main/java/com/example/spot/study/domain/association/Theme.java(2 hunks)src/main/java/com/example/spot/study/domain/repository/RegionRepository.java(1 hunks)src/main/java/com/example/spot/study/domain/repository/ThemeRepository.java(1 hunks)src/main/java/com/example/spot/todo/application/impl/ManageToDoUseCaseImpl.java(1 hunks)src/main/java/com/example/spot/todo/domain/ToDo.java(3 hunks)src/main/java/com/example/spot/vote/application/VoteCommandServiceImpl.java(9 hunks)src/main/java/com/example/spot/vote/application/VoteQueryServiceImpl.java(9 hunks)src/test/java/com/example/spot/service/post/GetPostUseCaseTest.java(10 hunks)src/test/java/com/example/spot/service/post/PostCommandServiceTest.java(19 hunks)src/test/java/com/example/spot/service/schedule/AttendanceCommandServiceTest.java(20 hunks)src/test/java/com/example/spot/service/schedule/AttendanceQueryServiceTest.java(5 hunks)src/test/java/com/example/spot/service/schedule/ScheduleCommandServiceTest.java(8 hunks)src/test/java/com/example/spot/service/schedule/ScheduleQueryServiceTest.java(5 hunks)src/test/java/com/example/spot/service/story/StoryCommandServiceTest.java(22 hunks)src/test/java/com/example/spot/service/story/StoryQueryServiceTest.java(11 hunks)src/test/java/com/example/spot/service/study/StudyCommandServiceTest.java(3 hunks)src/test/java/com/example/spot/service/study/StudyQueryServiceTest.java(66 hunks)src/test/java/com/example/spot/service/study/studymember/StudyMemberCommandServiceTest.java(1 hunks)src/test/java/com/example/spot/service/todo/ToDoCommandServiceTest.java(1 hunks)
💤 Files with no reviewable changes (1)
- src/main/java/com/example/spot/member/domain/association/MemberThemeRepository.java
🧰 Additional context used
🧬 Code Graph Analysis (6)
src/main/java/com/example/spot/story/domain/Story.java (9)
src/main/java/com/example/spot/member/domain/Member.java (1)
Entity(26-123)src/main/java/com/example/spot/report/domain/StoryReport.java (1)
Entity(12-35)src/main/java/com/example/spot/story/domain/association/LikedStory.java (1)
Entity(17-40)src/main/java/com/example/spot/story/domain/association/StoryImage.java (1)
Entity(17-37)src/main/java/com/example/spot/story/domain/association/StoryComment.java (1)
Entity(13-102)src/main/java/com/example/spot/study/domain/Study.java (1)
Entity(30-227)src/main/java/com/example/spot/story/web/dto/request/StoryRequestDTO.java (2)
Getter(10-45)Getter(13-44)src/main/java/com/example/spot/story/web/dto/response/StoryCommentResponseDTO.java (7)
Getter(14-154)Getter(17-37)Getter(39-63)Getter(65-69)Getter(71-87)Getter(89-105)Getter(107-153)src/main/java/com/example/spot/story/web/dto/response/StoryResponseDTO.java (7)
Getter(12-172)Getter(15-29)Getter(31-39)Getter(41-71)Getter(73-111)Getter(113-119)Getter(121-137)
src/main/java/com/example/spot/member/domain/association/PreferredRegion.java (3)
src/main/java/com/example/spot/member/domain/Member.java (1)
Entity(26-123)src/main/java/com/example/spot/member/domain/association/PreferredTheme.java (1)
Entity(23-55)src/main/java/com/example/spot/study/domain/association/Region.java (1)
Entity(15-57)
src/main/java/com/example/spot/study/domain/association/Theme.java (2)
src/main/java/com/example/spot/member/domain/association/PreferredTheme.java (1)
Entity(23-55)src/main/java/com/example/spot/study/domain/association/StudyTheme.java (1)
Entity(13-48)
src/test/java/com/example/spot/service/study/StudyQueryServiceTest.java (1)
src/main/java/com/example/spot/study/presentation/dto/response/SearchResponseDTO.java (1)
SearchResponseDTO(24-132)
src/main/java/com/example/spot/auth/application/legacy/AuthServiceImpl.java (1)
src/main/java/com/example/spot/auth/presentation/dto/token/TokenResponseDTO.java (1)
TokenResponseDTO(5-25)
src/main/java/com/example/spot/study/application/StudyQueryServiceImpl.java (1)
src/main/java/com/example/spot/study/presentation/dto/response/SearchResponseDTO.java (1)
SearchResponseDTO(24-132)
⏰ 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_test
🔇 Additional comments (144)
src/test/java/com/example/spot/service/todo/ToDoCommandServiceTest.java (1)
14-15: Import path looks correct after repository relocation
The test now targetsmember.infrastructure.MemberRepository, matching the new layered split. No other adjustments required.src/test/java/com/example/spot/service/study/studymember/StudyMemberCommandServiceTest.java (1)
11-12: Consistent move to infrastructure layer
The updated import reflects the new repository location. 👍src/main/java/com/example/spot/post/application/command/impl/LikePostUseCaseImpl.java (1)
7-8: Repository import aligned – no functional impact
The only change is the import; business logic remains intact.src/main/java/com/example/spot/member/domain/validation/validator/ExistMemberValidator.java (1)
5-6: Import path updated – validator still behaves identically
Nothing else to flag.src/main/java/com/example/spot/post/application/command/impl/ManagePostUseCaseImpl.java (1)
10-10: Import path update looks correctThe repository moved to
member.infrastructure; the new import compiles and aligns with the refactor.
No further changes needed here.src/main/java/com/example/spot/post/application/command/impl/ScrapPostUseCaseImpl.java (1)
9-9: Import path update acknowledgedSwitching to
member.infrastructure.MemberRepositoryis consistent with the package move.src/main/java/com/example/spot/post/application/command/impl/ManagePostCommentUseCaseImpl.java (1)
11-11: Import path change OKThe new
MemberRepositorylocation compiles and is consistent with the rest of the refactor.src/main/java/com/example/spot/common/application/admin/AdminServiceImpl.java (1)
9-9: LGTM: Repository moved to infrastructure layer.The move of
MemberRepositoryfrom domain to infrastructure package aligns with the architectural refactoring objectives, properly separating domain logic from infrastructure concerns.src/main/java/com/example/spot/common/security/oauth/CustomOAuth2UserService.java (2)
13-13: LGTM: Repository moved to infrastructure layer.Consistent with the architectural refactoring to separate domain logic from infrastructure concerns.
54-56: LGTM: Added braces for better code style.Adding braces around the
ifstatement improves code readability and follows good coding practices, even for single statements.src/main/java/com/example/spot/member/application/legacy/MemberServiceImpl.java (2)
5-5: LGTM: Repository moved to infrastructure layer.Consistent with the architectural refactoring pattern, even for this deprecated service.
41-56: LGTM: Formatting improvements enhance readability.The improved indentation and alignment make the code more readable without changing functionality.
src/main/java/com/example/spot/auth/application/refactor/impl/JwtTokenServiceImpl.java (2)
11-11: LGTM: Repository moved to infrastructure layer.Consistent with the systematic architectural refactoring across the codebase.
54-56: LGTM: Added braces for consistency.Adding braces around the
ifstatement improves code consistency and readability.src/main/java/com/example/spot/story/domain/Story.java (3)
12-32: LGTM: Import reorganization improves code clarity.The explicit imports instead of wildcards make dependencies more visible and improve code maintainability.
131-144: LGTM: Removed member update calls - aligns with decoupling objectives.The removal of
member.updateStudyPost(this)calls fromplusHitNum(),plusLikeNum(), andminusLikeNum()methods aligns with the refactoring objectives to eliminate bidirectional associations. The Story entity now only updates its aggregate root (Study) rather than maintaining bidirectional relationships with Member.This change reduces coupling and complexity while maintaining the necessary state updates on the Study entity.
150-163: LGTM: Consistent removal of member update calls.The
updatePost()method now only callsstudy.updateStudyPost(this), maintaining consistency with the other methods and the architectural refactoring objectives.src/main/java/com/example/spot/study/application/StudyMemberQueryServiceImpl.java (3)
4-4: LGTM: Import reorganization improves code structure.The import statements have been reorganized for better clarity and logical grouping, which enhances code readability.
Also applies to: 7-7, 9-11, 16-16
44-50: LGTM: Consistent braces improve code maintainability.Adding explicit braces to all single-line
ifstatements enhances code consistency and reduces the risk of future bugs when additional statements are added to conditional blocks.Also applies to: 76-78, 85-87, 135-137, 145-147, 172-174
53-58: LGTM: Multi-line parameter formatting enhances readability.Breaking long method calls into multiple lines with proper indentation significantly improves code readability, especially for methods with multiple parameters.
Also applies to: 90-95, 178-179, 204-205
src/main/java/com/example/spot/study/domain/repository/ThemeRepository.java (2)
3-4: LGTM: Appropriate imports for exception handling.The addition of necessary imports for
ErrorStatusandGeneralExceptionsupports the new default method implementation.Also applies to: 7-7
18-21: LGTM: Excellent standardization of repository error handling.The new
getByThemeTypedefault method follows the repository pattern enhancement by centralizing exception handling. This eliminates the need for callers to manually handleOptionalresults and provides consistent error behavior across the application.src/test/java/com/example/spot/service/post/GetPostUseCaseTest.java (3)
3-6: LGTM: Consolidated static imports improve readability.Grouping all static imports for assertions and Mockito at the top creates better import organization and makes dependencies clearer.
174-174: LGTM: Consistent comment formatting enhances test organization.The standardized section divider comments improve test structure and make it easier to navigate through different test categories.
Also applies to: 269-269, 342-342, 426-426, 449-449, 471-471, 508-508, 580-580
592-600: LGTM: Simplified member initialization aligns with domain refactoring.The removal of collection initialization in the
initMember()method reflects the domain model simplification whereMemberentities no longer directly manage collections, aligning with the PR's objective to reduce bidirectional associations.src/main/java/com/example/spot/member/application/refactor/impl/MemberTestSupportServiceImpl.java (2)
14-14: LGTM: Repository package migration to infrastructure layer.Moving
MemberRepositoryfrom domain to infrastructure package aligns with the PR's architectural refactoring objectives and better separates concerns between domain logic and infrastructure implementation.
119-121: LGTM: Added braces improve code consistency.Adding explicit braces to the
ifstatement insaveRefreshTokenmethod enhances code consistency and maintainability, following the same pattern applied throughout the codebase.src/main/java/com/example/spot/member/infrastructure/MemberRepository.java (3)
1-1: LGTM: Repository correctly migrated to infrastructure package.Moving
MemberRepositoryto the infrastructure package aligns with the architectural refactoring objectives, properly separating domain entities from infrastructure concerns.
3-4: LGTM: Appropriate imports for exception handling pattern.The addition of
ErrorStatusandMemberHandlerimports supports the new default method implementation and maintains consistency with other repository interfaces.
34-36: LGTM: Excellent repository pattern standardization.The new
getByIddefault method provides centralized exception handling for member retrieval, eliminating the need for callers to manually handleOptionalresults. This pattern enhances code consistency and reduces boilerplate across the application.src/main/java/com/example/spot/study/domain/repository/RegionRepository.java (2)
3-4: LGTM: Proper imports added for exception handling.The imports for
ErrorStatusandGeneralExceptionare correctly added to support the newgetByCodemethod.
17-20: LGTM: Well-implemented convenience method.The
getByCodemethod follows the established pattern of providing explicit error handling for entity retrieval. This standardizes the error handling approach and simplifies calling code by eliminating the need to handleOptionalmanually.src/main/java/com/example/spot/vote/application/VoteQueryServiceImpl.java (4)
7-7: LGTM: Consistent repository import relocation.The
MemberRepositoryimport has been correctly updated from the domain package to the infrastructure package, aligning with the broader refactoring pattern across the codebase.
17-18: LGTM: Improved import organization.The imports have been properly reordered for better consistency and readability.
38-38: LGTM: Enhanced JavaDoc formatting.The JavaDoc comments have been improved with proper spacing and alignment, enhancing readability while maintaining the same documentation content.
Also applies to: 82-86, 100-101, 113-115, 147-149, 181-182
61-62: LGTM: Improved method call formatting.The method calls have been properly formatted with line breaks for better readability while maintaining the same functionality.
Also applies to: 70-71, 92-93, 95-96, 102-103, 122-123, 182-183, 322-323
src/main/java/com/example/spot/post/application/command/impl/LikePostCommentUseCaseImpl.java (3)
12-12: LGTM: Consistent repository import relocation.The
MemberRepositoryimport has been correctly updated from the domain package to the infrastructure package, maintaining consistency with the broader refactoring pattern.
32-39: LGTM: Enhanced JavaDoc formatting.The JavaDoc comments have been improved with proper spacing and alignment, making the documentation more readable while preserving all content.
Also applies to: 77-84, 117-124, 162-169
97-98: LGTM: Improved method call formatting.The method calls have been properly formatted with line breaks for better readability without affecting functionality.
Also applies to: 182-183
src/main/java/com/example/spot/member/infrastructure/StudyJoinReasonRepository.java (4)
1-1: LGTM: Proper repository relocation.The repository has been correctly moved from the domain package to the infrastructure package, aligning with the architectural refactoring to separate domain entities from infrastructure concerns.
3-4: LGTM: Proper imports for relocated repository.The necessary imports have been correctly added to support the relocated repository interface and new method return type.
9-9: LGTM: Useful method addition.The
findAllByMemberIdmethod provides necessary functionality for retrieving all study join reasons associated with a specific member, supporting the refactored approach of using repositories instead of direct entity associations.
11-13: LGTM: Consistent formatting improvements.The existing methods have been properly formatted for consistency and readability.
src/test/java/com/example/spot/service/schedule/AttendanceQueryServiceTest.java (4)
3-5: LGTM: Improved static imports.The static imports for assertions and Mockito methods improve test readability by eliminating the need for class prefixes.
9-41: LGTM: Well-organized imports.The imports have been properly organized and cleaned up, including the correct import path for
MemberRepositoryfrom the infrastructure package.
92-97: LGTM: Enhanced method call formatting.The method calls have been properly formatted with appropriate line breaks for better readability while maintaining the same test functionality.
Also applies to: 102-103, 122-123, 322-323
239-239: LGTM: Improved comment formatting.The section comment has been properly formatted for better visual separation of utility methods.
src/main/java/com/example/spot/auth/application/refactor/impl/KakaoAuthServiceImpl.java (2)
16-19: Repository imports moved to infrastructure layer - excellent refactoring!The migration of repository imports from
domaintoinfrastructurepackages aligns perfectly with the PR objectives of improving domain architecture and reducing coupling.
49-49: Repository rename from MemberTheme to PreferredTheme improves clarity.The renaming from
MemberThemeRepositorytoPreferredThemeRepositorybetter reflects the domain concept and aligns with the overall refactoring strategy.src/main/java/com/example/spot/schedule/application/ScheduleQueryServiceImpl.java (2)
68-70: Excellent addition of braces to single-line if statements.Adding braces to single-line
ifstatements improves code safety and follows best practices by preventing potential bugs when statements are later modified.Also applies to: 111-113, 138-138, 140-140, 146-146, 148-148, 170-172
151-157: Method formatting improvements enhance readability.The multiline formatting of method calls and parameter lists significantly improves code readability and maintainability.
Also applies to: 186-187, 193-195, 204-206
src/test/java/com/example/spot/service/schedule/ScheduleCommandServiceTest.java (2)
3-8: Explicit static imports improve clarity.Adding explicit static imports at the top makes test dependencies clearer and follows best practices for test organization.
156-158: Method parameter formatting enhances test readability.The multiline formatting of method calls with multiple parameters significantly improves test code readability and maintainability.
Also applies to: 265-267, 268-270, 297-299, 313-315, 329-331
src/main/java/com/example/spot/story/application/StoryQueryServiceImpl.java (2)
170-172: Good addition of braces to single-line if statement.Adding braces to the
ifstatement improves code safety and consistency with coding best practices.
50-57: Javadoc formatting improvements enhance documentation clarity.The improved Javadoc parameter formatting makes the documentation more readable and maintains consistency across the codebase.
Also applies to: 242-244
src/main/java/com/example/spot/member/domain/association/StudyJoinReason.java (3)
5-12: Explicit imports improve code clarity.Replacing wildcard imports with explicit imports makes dependencies clearer and follows best practices for maintainable code.
27-27: Private constructor access improves encapsulation.Making the all-args constructor private enforces controlled instantiation through the static factory method, following good domain design principles.
43-48: Consistent static factory methods across association entities verifiedAll three association classes—StudyJoinReason, PreferredTheme, and PreferredRegion—define a public static of(...) method that delegates to their respective builders. No further changes are needed.
src/test/java/com/example/spot/service/schedule/AttendanceCommandServiceTest.java (3)
3-8: LGTM! Well-organized static imports.The static imports are properly grouped at the top, improving code readability and following Java best practices.
106-111: Good formatting improvement for method readability.Breaking the long method calls into multiple lines enhances readability, especially for method calls with multiple parameters.
656-657: Improved constructor formatting for clarity.The
UsernamePasswordAuthenticationTokenconstructor call is now more readable by being split across multiple lines.src/test/java/com/example/spot/service/schedule/ScheduleQueryServiceTest.java (3)
3-5: Consistent import organization.The static imports are well-organized and consistent with the formatting applied to other test classes in this PR.
85-90: Enhanced readability for method parameters.Breaking long method calls with multiple parameters into separate lines improves code readability and makes the test assertions easier to follow.
319-320: Consistent formatting with authentication setup.The authentication token creation formatting is consistent with other test classes, maintaining code consistency across the test suite.
src/main/java/com/example/spot/member/domain/association/PreferredTheme.java (3)
6-13: Good practice: Explicit imports over wildcards.Using explicit imports instead of wildcards improves dependency clarity and IDE support while avoiding potential naming conflicts.
29-30: Excellent use of factory pattern.Restricting the all-args constructor to private access and providing the static factory method
of()is a great design choice that:
- Encapsulates object creation logic
- Provides a clear, readable API
- Allows for future validation or logic additions
49-54: Well-designed static factory method.The
of()method provides a clean, fluent API for creatingPreferredThemeinstances. This pattern is preferred over direct constructor calls as it's more readable and maintainable.src/main/java/com/example/spot/member/infrastructure/PreferredThemeRepository.java (1)
1-19: Excellent architectural improvement: Repository moved to infrastructure layer.This new repository interface demonstrates several good practices:
- Proper separation of concerns: Moving from domain to infrastructure package aligns with DDD principles
- Clear contract: Well-defined methods for member-scoped operations
- Standard conventions: Follows Spring Data JPA naming patterns
The repository methods appropriately support the domain's needs while maintaining clean architecture boundaries.
src/main/java/com/example/spot/common/security/oauth/CustomOAuthSuccessHandler.java (3)
3-12: Consistent architectural alignment: Repository moved to infrastructure package.The import changes properly reflect the repository layer restructuring, moving
MemberRepositoryfrom domain to infrastructure package. This maintains consistency with the broader refactoring effort.
39-40: Improved method signature readability.Breaking the method signature across multiple lines enhances readability, especially for methods with multiple parameters.
65-66: Minor formatting improvement.The spacing fix in the method call contributes to consistent code formatting across the codebase.
src/main/java/com/example/spot/study/domain/association/Theme.java (3)
4-4: LGTM! Import change aligns with the domain refactoring.The import change from
MemberThemetoPreferredThemeis consistent with the broader refactoring effort to replace bidirectional associations.
6-16: Good practice: Explicit imports improve readability.The change from wildcard imports to explicit Jakarta Persistence imports improves code clarity and makes dependencies more visible.
46-46: LGTM! Field type change aligns with the refactoring.The field rename from
memberThemeListtopreferredThemeListand type change fromList<MemberTheme>toList<PreferredTheme>is consistent with the domain refactoring objectives.src/main/java/com/example/spot/member/domain/association/PreferredRegion.java (3)
4-13: LGTM! Explicit imports improve code clarity.The change from wildcard imports to explicit Jakarta Persistence imports makes dependencies more visible and improves code readability.
29-29: Good practice: Private constructor enforces controlled instantiation.Changing
@AllArgsConstructoraccess level to private prevents direct instantiation and encourages the use of the static factory method, which is a good design pattern.
47-52: LGTM! Static factory method follows consistent pattern.The static factory method
of(Member member, Region region)provides a controlled and consistent way to createPreferredRegioninstances, following the same pattern as other preference entities likePreferredTheme.src/main/java/com/example/spot/vote/application/VoteCommandServiceImpl.java (3)
8-8: LGTM! Repository import moved to infrastructure package.The import change from domain to infrastructure package for
MemberRepositoryaligns with the broader architectural refactoring to properly separate concerns.
21-21: Good addition: Explicit import for List.Adding the explicit import for
java.util.Listimproves code clarity and makes dependencies more visible.
42-42: LGTM! Formatting improvements enhance readability.The addition of blank lines in method documentation and parameter alignment makes the code more readable and follows consistent formatting practices.
Also applies to: 83-83, 104-104, 170-170, 226-226, 265-265
src/main/java/com/example/spot/study/application/StudyCommandServiceImpl.java (2)
6-11: LGTM! Import organization and infrastructure package usage.The import reorganization with explicit imports and moving
MemberRepositoryto the infrastructure package aligns with the architectural refactoring goals and improves code clarity.
66-67: Good formatting improvements for method parameters.The parameter alignment and formatting improvements enhance code readability and follow consistent coding practices.
Also applies to: 84-87, 90-91, 139-140, 183-185
src/test/java/com/example/spot/service/study/StudyQueryServiceTest.java (7)
3-5: LGTM: Import statements properly updated.The static import statements have been updated to be more explicit, which improves code clarity by making it clear which specific assertion methods are being used.
16-24: LGTM: Domain imports correctly updated to reflect refactoring.The imports have been properly updated to use the new
PreferredTheme,PreferredRegion, andPreferredStudyentities along with their corresponding infrastructure repositories. This aligns with the PR objective to move away from bidirectional associations in the Member domain.
89-89: LGTM: Repository mock declaration updated consistently.The mock declaration correctly uses
PreferredThemeRepositoryinstead of the oldMemberThemeRepository, maintaining consistency with the domain refactoring.
107-108: LGTM: Variable names updated to match new entity type.The variable names have been properly renamed from
memberTheme1/2topreferredTheme1/2to reflect the newPreferredThemeentity type.
133-134: LGTM: Entity builder calls updated correctly.The builder calls have been properly updated to use
PreferredTheme.builder()instead of the deprecatedMemberTheme.builder(), maintaining the same construction pattern.
167-168: LGTM: Repository method calls consistently updated throughout the test.All repository method calls have been systematically updated to use
preferredThemeRepositoryinstead ofmemberThemeRepository. The method signatures and test logic remain unchanged, ensuring test functionality is preserved while adapting to the new domain model.Also applies to: 400-401, 435-436, 466-467, 491-492, 601-602, 634-635, 664-665, 704-704, 728-729, 755-756, 781-782, 831-832, 868-869, 899-900, 935-935, 959-959, 985-986, 1012-1013, 1041-1041
247-248: LGTM: Minor formatting improvements enhance readability.The formatting changes improve code readability by properly aligning method parameters and maintaining consistent indentation. These changes don't affect the test logic and follow good coding practices.
Also applies to: 249-250, 309-310, 340-341, 356-356, 367-368, 565-567, 580-580, 582-583, 598-599, 1516-1517, 1518-1519, 1532-1533, 1565-1566, 1567-1568, 1577-1578, 1588-1589, 1609-1610, 1611-1612, 1664-1665, 1666-1667
src/test/java/com/example/spot/service/study/StudyCommandServiceTest.java (3)
4-8: LGTM: Explicit static imports improve code clarity.The change from wildcard static imports to explicit imports for specific Mockito and JUnit methods improves code readability and makes dependencies more transparent.
12-21: LGTM: Import statements reorganized and cleaned up.The import statements have been reorganized with better grouping of related domain and repository classes. This improves code organization and maintainability.
Also applies to: 33-35
350-351: LGTM: Improved readability through multi-line formatting.The
UsernamePasswordAuthenticationTokenconstructor arguments have been split across multiple lines for better readability without changing the functionality.src/test/java/com/example/spot/service/story/StoryQueryServiceTest.java (7)
3-33: LGTM: Improved import organizationThe consolidation of static imports and logical reordering of imports enhances code readability and follows standard Java conventions.
182-183: LGTM: Consistent formatting improvementsThe line breaks in method calls and parameter formatting enhance code readability, particularly for methods with multiple parameters.
Also applies to: 212-213, 264-265, 400-406, 422-424
132-132: LGTM: Standardized comment formattingThe consistent spacing in comment blocks improves visual organization of test sections.
Also applies to: 269-269, 382-382, 523-523
527-528: LGTM: Consistent utility method formattingThe formatting improvements in the authentication utility method and loop structure align with the overall formatting standardization in this file.
Also applies to: 628-628
3-8: LGTM: Clean import organizationThe static imports are now properly consolidated at the top for better readability and organization.
132-132: LGTM: Consistent comment formattingThe section divider comments are now consistently formatted with proper spacing, improving code readability.
Also applies to: 269-269, 382-382, 523-523
182-183: LGTM: Improved method call formattingMulti-line method calls are now properly formatted for better readability, especially for longer parameter lists.
Also applies to: 212-213, 264-265, 359-359, 379-379, 527-528
src/main/java/com/example/spot/auth/application/legacy/AuthServiceImpl.java (6)
29-32: LGTM: Repository refactor alignmentThe import changes from domain to infrastructure packages and the repository field rename from
MemberThemeRepositorytoPreferredThemeRepositorycorrectly align with the broader Member domain refactoring described in the PR objectives.Also applies to: 74-74
245-245: LGTM: Updated repository usageThe method correctly uses the refactored
preferredThemeRepositoryinstead of the deprecatedmemberThemeRepository, maintaining the same business logic while following the new repository structure.
134-156: LGTM: Comprehensive formatting improvementsThe JavaDoc parameter formatting, conditional statement formatting, and comment section improvements significantly enhance code readability and documentation quality.
Also applies to: 198-200, 252-253, 299-301, 440-443
74-74: LGTM: Repository migration to infrastructure layerThe change from
MemberThemeRepositorytoPreferredThemeRepositoryaligns with the PR objective of moving member preference repositories from domain to infrastructure layer, reducing ORM dependencies.
245-247: LGTM: Consistent repository usageThe method correctly uses the new
preferredThemeRepositoryinstead of the oldmemberThemeRepository, maintaining consistency with the refactored domain model.
88-88: LGTM: Improved section formattingThe comment section dividers are now consistently formatted, improving code organization and readability.
Also applies to: 130-130, 295-295, 663-663
src/test/java/com/example/spot/service/post/PostCommandServiceTest.java (5)
3-7: LGTM: Consistent import organization and field formattingThe static import consolidation and field declaration formatting with line breaks after
@InjectMocksannotations improve code readability and follow the same patterns established in other test files.Also applies to: 93-109
187-187: LGTM: Standardized test formattingThe comment block standardization, exception assertion formatting, and utility method formatting enhance test readability and maintain consistency with the project's formatting standards.
Also applies to: 262-262, 374-374, 594-595, 1080-1081
3-8: LGTM: Clean import organizationStatic imports are properly consolidated at the top, improving code organization and readability.
93-94: LGTM: Consistent annotation formattingAdding line breaks after
@InjectMocksannotations improves code readability and maintains consistent formatting patterns.Also applies to: 96-97, 99-100, 102-103, 105-106, 108-109
187-187: LGTM: Improved section formattingComment section dividers are now consistently formatted with proper spacing, enhancing code organization.
Also applies to: 262-262, 374-374, 415-415, 469-469, 522-522, 618-618, 675-675, 730-730, 790-790, 847-847, 901-901, 951-951, 1015-1015, 1076-1076
src/main/java/com/example/spot/study/application/StudyMemberCommandServiceImpl.java (5)
168-170: LGTM: Improved conditional statement formattingAdding braces around single-line
ifstatements enhances code clarity and prevents potential errors when modifying the code later. This follows good Java coding practices and improves consistency.Also applies to: 178-180, 183-185, 236-238, 246-248, 251-253
68-69: LGTM: Enhanced parameter and documentation formattingThe multi-line parameter formatting and JavaDoc improvements significantly enhance code readability, especially for methods with multiple parameters and complex builder patterns.
Also applies to: 87-88, 130-132, 152-153, 196-204, 268-272
48-48: LGTM: Consistent section formattingThe comment section divider is now properly formatted, improving code organization.
168-170: LGTM: Improved conditional statement formattingAdding braces around single-line
ifstatements enhances code clarity and follows best practices for maintainability, reducing the risk of introducing bugs when adding statements later.Also applies to: 178-180, 183-185, 236-238, 246-248, 251-253
68-69: LGTM: Better method call formattingMulti-line method calls are now properly formatted with appropriate line breaks and indentation, improving readability for long parameter lists.
Also applies to: 87-88, 93-94, 101-102, 130-131, 173-175, 241-243
src/main/java/com/example/spot/todo/domain/ToDo.java (4)
53-55: LGTM: Aligned with Member domain refactoringThe removal of the member collection call from
setToDoList()correctly aligns with the PR objectives to eliminate bidirectional relationships in the Member domain. Maintaining only the study-side association management is consistent with the broader refactoring strategy.
32-33: LGTM: Consistent formatting improvementsThe annotation formatting and method structure improvements enhance code readability and maintain consistency with the project's formatting standards.
Also applies to: 57-68
53-55: LGTM: Removal of bidirectional member collection managementThe removal of
this.member.addToDoList(this)aligns perfectly with the PR objective of eliminating bidirectional relationships and collection management from the Member entity. This reduces coupling and ORM dependencies while maintaining the necessary association with the Study entity.
32-34: LGTM: Consistent formatting improvementsThe formatting adjustments improve code readability and maintain consistency throughout the entity class.
Also applies to: 57-59, 61-68
src/main/java/com/example/spot/report/application/ReportCommandServiceImpl.java (4)
9-9: LGTM! Repository correctly moved to infrastructure package.This change aligns with the refactoring objective to centralize repository access in the infrastructure layer, improving architectural separation.
14-19: Good improvement: Explicit imports replace wildcards.The explicit imports for report domain classes improve code clarity and make dependencies more transparent compared to the previous wildcard imports.
78-86: Method signature reformatting improves readability.Breaking the parameters across lines makes the method signature more readable and follows good formatting practices for methods with multiple parameters.
118-120: Excellent removal of bidirectional relationship management.The removal of
member.addMemberReport(memberReport)call correctly implements the refactoring objective to eliminate bidirectional relationship management from the Member entity. This reduces coupling and simplifies the domain model.src/test/java/com/example/spot/service/story/StoryCommandServiceTest.java (3)
3-10: Good import organization with static imports consolidated.The consolidation of static imports for assertions and Mockito methods at the top improves code organization and readability.
12-41: Import cleanup enhances maintainability.The removal of unused imports and better organization of the remaining imports improves code maintainability and reduces clutter.
1177-1180: Minor formatting improvement for loop structure.The consistent formatting and spacing in the loop structure improves code readability.
src/main/java/com/example/spot/study/application/StudyQueryServiceImpl.java (6)
9-17: Excellent repository migration to infrastructure package.The systematic update of imports to use infrastructure repositories (
PreferredThemeRepository,PreferredRegionRepository,PreferredStudyRepository) correctly implements the architectural refactoring objective to centralize repository access.
86-86: Successfully replaced MemberThemeRepository with PreferredThemeRepository.This change aligns perfectly with the domain refactoring to replace the
MemberThemepattern withPreferredThemeassociations.
256-257: Correct implementation of preferred theme pattern.The replacement of member theme associations with
preferredThemeRepository.findAllByMemberId(memberId)successfully implements the new association model while maintaining the same business logic.
268-271: Good use of PreferredTheme domain objects.The mapping from
PreferredThemetoThemeentities usingPreferredTheme::getThememaintains clean separation between association and domain objects.
108-110: Improved code formatting with braces.Adding braces to the single-line if statement improves code consistency and follows best practices for maintainability.
368-370: Consistent application of preferred theme pattern.The systematic replacement of member theme access with
preferredThemeRepository.findAllByMemberId(memberId)demonstrates consistent application of the refactoring across all methods.src/main/java/com/example/spot/story/application/StoryCommandServiceImpl.java (4)
6-7: Import reorganization looks good.The imports have been properly reorganized and moved to appropriate packages as part of the domain refactoring.
Also applies to: 9-9, 11-13, 28-34
506-506: Simplified anonymous number assignment.The direct assignment is cleaner and more readable.
84-96: Formatting improvements enhance readability.The consistent multi-line formatting for method chains and the addition of braces to conditional blocks improve code clarity and maintainability.
Also applies to: 133-143, 178-180, 237-239, 292-294, 342-344, 373-374, 388-390, 430-431, 445-447, 624-626, 633-640, 677-679, 700-702, 718-719, 732-734
1-756: Member mutation calls removal verifiedAll
member.add*,.update*, and.delete*mutation calls have been removed consistently across the codebase:
- No remaining
member.addStudyPost(),member.updateStudyPost(), or similar calls were found.- Repository operations continue to manage persistence and relationships.
- Business logic and data integrity remain intact without bidirectional updates.
No further action required.
src/main/java/com/example/spot/member/application/refactor/impl/MemberInfoServiceImpl.java (3)
31-47: Well-structured refactoring of the updateProfile method.The changes improve the code by:
- Using
getByIdwhich handles the exception internally- Passing explicit parameters to
updateInfoinstead of the entire DTO- Eliminating the need for explicit save due to
@Transactional
49-54: Good extraction of DTO conversion logic.The helper method improves code reusability and maintains single responsibility principle.
33-33: getById throws MemberHandler for missing members
The default implementation inMemberRepositoryusesfindById(memberId) .orElseThrow(() -> new MemberHandler(ErrorStatus._MEMBER_NOT_FOUND));so it correctly throws an exception when the member isn’t found.
src/main/java/com/example/spot/member/domain/Member.java (1)
102-112: Improved updateInfo method with explicit parameters.The change from accepting a DTO to explicit parameters improves:
- Type safety
- Clarity of what fields can be updated
- Decoupling from the presentation layer
src/main/java/com/example/spot/member/application/refactor/impl/MemberPreferenceServiceImpl.java (3)
215-224: Well-structured helper methods improve code organization.The extraction of common logic into helper methods (
findMember,toUpdateDTO) follows DRY principle and improves maintainability.
226-245: Efficient persistence pattern for preference updates.The persist methods properly handle the update scenario by:
- Checking for existing data
- Deleting old preferences
- Saving new preferences
This ensures data consistency while avoiding orphaned records.
56-70: Good use of static factory methods for domain object creation.Using static factory methods like
PreferredTheme.of(),PreferredRegion.of(), andStudyJoinReason.of()provides:
- Better encapsulation
- Clearer intent
- Easier to add validation in the future
Also applies to: 82-96, 106-122
src/main/java/com/example/spot/schedule/application/ScheduleCommandServiceImpl.java (1)
57-58: Formatting improvements enhance code readability.The consistent application of multi-line formatting and addition of braces to conditional blocks improves code clarity.
Also applies to: 92-99, 127-128, 236-240, 268-269, 281-285, 292-294, 302-310, 354-355, 362-364
| List<PreferredStudy> findByMemberIdAndStudyLikeStatusOrderByCreatedAtDesc( | ||
| Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable); | ||
| Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable); | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Mixed OrderBy in method name + Pageable can create double sort clauses
findByMemberIdAndStudyLikeStatusOrderByCreatedAtDesc(Long, …, Pageable) hard-codes ORDER BY created_at DESC while also accepting a Pageable that can carry its own Sort.
Spring Data will prepend the fixed ORDER BY and silently ignore conflicting sort in Pageable, which can surprise callers.
Two cleaner options:
-List<PreferredStudy> findByMemberIdAndStudyLikeStatusOrderByCreatedAtDesc(
- Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable);
+Page<PreferredStudy> findByMemberIdAndStudyLikeStatus(
+ Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable);or keep the hard-coded order and drop Pageable. Choose whichever better matches the API need.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| List<PreferredStudy> findByMemberIdAndStudyLikeStatusOrderByCreatedAtDesc( | |
| Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable); | |
| Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable); | |
| Page<PreferredStudy> findByMemberIdAndStudyLikeStatus( | |
| Long memberId, StudyLikeStatus studyLikeStatus, Pageable pageable); |
🤖 Prompt for AI Agents
In
src/main/java/com/example/spot/member/infrastructure/PreferredStudyRepository.java
around lines 13 to 15, the method
findByMemberIdAndStudyLikeStatusOrderByCreatedAtDesc uses a hard-coded ORDER BY
clause in its name while also accepting a Pageable parameter that can include
its own sorting, causing potential conflicts and ignored sorts. To fix this,
either remove the OrderBy clause from the method name and rely solely on the
Pageable's sorting, or keep the hard-coded OrderBy and remove the Pageable
parameter to avoid double sorting issues. Choose the approach that best fits the
intended API behavior.
| * | ||
| * @param postId 스크랩할 게시글 ID | ||
| * @param memberId 회원 ID | ||
| * @return 스크랩한 게시글 ID와 스크랩 수 | ||
| * @throws PostHandler 게시글을 찾을 수 없는 경우 | ||
| * @throws PostHandler 게시글을 찾을 수 없는 경우 | ||
| * @throws MemberHandler 회원을 찾을 수 없는 경우 | ||
| * @throws PostHandler 이미 해당 게시글을 스크랩 한 경우 | ||
| * @throws PostHandler 이미 해당 게시글을 스크랩 한 경우 | ||
| */ |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Document concurrency caveat in Javadoc
The scrap operation is check-then-insert and can suffer from race conditions if two requests hit the same (memberId, postId) simultaneously.
Consider adding a note (or better, optimistic/unique-key handling) so future maintainers know that duplicate-key DB constraints, or a serialisable isolation level, are expected to ensure idempotency.
🤖 Prompt for AI Agents
In
src/main/java/com/example/spot/post/application/command/impl/ScrapPostUseCaseImpl.java
around lines 34 to 41, the Javadoc for the scrap operation lacks a concurrency
warning. Add a note explaining that the method uses a check-then-insert pattern
which can cause race conditions if concurrent requests for the same (memberId,
postId) occur. Recommend that future maintainers ensure idempotency by relying
on database unique constraints or using optimistic locking or serializable
transaction isolation levels.
| System.out.println(startDate); | ||
| System.out.println(finishDate); |
There was a problem hiding this comment.
Remove debug println statements.
Debug statements should not be committed to production code. Use proper logging instead.
- System.out.println(startDate);
- System.out.println(finishDate);
+ // Use proper logging if needed
+ // log.debug("Start date: {}, Finish date: {}", startDate, finishDate);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| System.out.println(startDate); | |
| System.out.println(finishDate); | |
| // Use proper logging if needed | |
| // log.debug("Start date: {}, Finish date: {}", startDate, finishDate); |
🤖 Prompt for AI Agents
In
src/main/java/com/example/spot/schedule/application/ScheduleCommandServiceImpl.java
around lines 169 to 170, remove the System.out.println debug statements and
replace them with appropriate logging calls using the project's logging
framework to ensure proper log management in production code.
1 participant
#️⃣ 연관된 이슈
🔎 작업 내용
리팩토링 할 부분이 많아서 양방향 연관관계 삭제 위주로 우선 진행했습니다.
기존 회원 도메인 내에서 연관된 컬렉션(List<>)을 통한 양방향 연관관계가 존재했으나, 아래와 같은 문제를 해결하기 위해 리팩토링을 진행 했습니다.
기존에는
Member엔티티가List<PreferredTheme>와 같이 연관된 컬렉션을 직접 가지고 있었지만, 현재는Repository를 통해 조회하는 방식으로 변경하여, 연관 도메인과의 결합도를 낮췄습니다.다음에는 회원 가입 및 소셜 로그인 로직 정리를 해보려고 해요!
다음 작업을 위해서 머지함
📷 스크린샷 (선택)
💬리뷰 요구사항 (선택)
Summary by CodeRabbit
Refactor
Bug Fixes
Style
Tests
Chores