Refactor: #310 MSW 처리중 teamService 기능 리팩토링 #312
Conversation
Walkthrough이 풀 리퀘스트는 팀 관리 및 프로젝트 서비스 핸들러의 기능을 대폭 개선합니다. 주요 변경 사항은 Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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: 0
🧹 Nitpick comments (11)
src/mocks/services/projectServiceHandler.ts (1)
275-275: 프로젝트 팀원 추가 API 점검
- 이미 프로젝트에 등록된
userId가 중복으로 요청될 경우 에러 처리가 필요한지 고민해 보세요.- 역할 검증 후
createProjectUser까지 최소한의 예외 처리를 추가하면 좋겠습니다.src/mocks/services/teamServiceHandler.ts (5)
6-29: 새로운 매핑 함수 다수 추가
mockAPI에서 제공되는 다양한 함수가 추가 임포트되었습니다. 팀과 프로젝트 간 연동 로직이 커지고 있으므로, 한 파일에서 과도하게 많은 책임을 지고 있지 않은지 점검해 보세요.
35-35: autoIncrementIdForTeam 초기화 로직 주의
TEAM_DUMMY.length + 1을 사용해 ID를 매기고 있습니다. 실제 운영에서는 동시성 문제나 ID 충돌 방지를 위해 좀 더 견고한 로직(예: DB 시퀀스)이 필요할 수 있으니 참고하세요.
74-113: 팀 생성 로직 검토
HEAD역할을 생성자에게 부여하고, 나머지coworkers를isPendingApproval = true로 세팅하여 초대 형태로 처리하는 방식이 적절해 보입니다.- 다만,
headCoworker가 이미coworkers에 들어있을 가능성에 대한 중복 체크가 없으므로, 중복 여부를 검토하는 로직이 필요할 수 있습니다.
249-249: TODO 주석 확인
주석에 적힌 대로isPendingApproval등 추가 정보가 응답에 포함되어야 한다면, 빠른 시일 내 구현을 권장드립니다.
306-335: 팀 초대 API 로직
- 이미 팀에 속한 경우 404를 반환하는 처리가 있는데, "이미 존재" 상황이므로 409(Conflict) 처리도 고려해 보세요.
- 초대 시 자동으로
isPendingApproval = true로 설정하는 부분이 초대 로직에 일관성을 부여합니다.src/mocks/mockAPI.ts (4)
43-46: createTeamUser 함수 검토
TEAM_USER_DUMMY에 바로 push하는 간단한 구조입니다. 동시성이나 무결성 검사가 필요하지 않은지 재검토해 보세요.
84-87: createTeam 함수
새로운 팀을TEAM_DUMMY에 추가합니다. 같은 팀 이름 중복 여부는 검사하지 않는 것으로 보이니, 필요하다면 추후 검증 로직을 추가해 주세요.
94-102: updateTeam 함수 예외 처리
팀이 없으면 에러를 던지는 구조입니다. "팀를 찾을 수 없습니다." 메시지 출력 시 오탈자(팀를→팀을) 확인 바랍니다.
192-203: updateProject 함수
ProjectInfoForm으로부터 데이터를 받아서project객체를 갱신합니다.startDate나endDate가 유효한 날짜인지 검사하는 로직이 없으므로, 필요하다면 요청 레벨에서 유효성을 점검해 주세요.src/mocks/services/taskServiceHandler.ts (1)
289-289: [역할 처리 로직 수정] 프로젝트 유저 부재 시 기본 roleName을 null로 처리
projectUser가 없을 경우roleName을 자동으로 null로 설정함으로써 예외 상황에 대한 가독성이 높아졌습니다. 다만, 이후 로직에서roleName이 null일 경우의 처리 흐름을 명확히 해두면 유지보수에 도움이 될 것입니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
.eslintrc.cjsis excluded by none and included by none
📒 Files selected for processing (7)
src/mocks/mockAPI.ts(5 hunks)src/mocks/mockUtils.ts(1 hunks)src/mocks/services/projectServiceHandler.ts(6 hunks)src/mocks/services/taskServiceHandler.ts(1 hunks)src/mocks/services/teamServiceHandler.ts(6 hunks)src/types/RoleType.tsx(1 hunks)src/types/TeamType.tsx(1 hunks)
🔇 Additional comments (28)
src/mocks/services/projectServiceHandler.ts (5)
27-30: 신규 import 및 타입 추가 확인
createProjectUserFormat 함수와 ProjectInfoForm 등의 타입 추가가 적절해 보입니다. 새로 가져온 함수의 역할이 이 파일 내 로직과 잘 호환되는지 확인해 주세요.
106-121: 프로젝트 유저 생성 로직 검토
coworkers.push(adminCoworker)로 관리자 계정을 자동 추가하는 로직이 있는데, 이미coworkers목록에 동일한userId가 존재할 경우 중복 삽입이 일어날 가능성이 있습니다.createProjectUserFormat실행 시 오류 발생 시 404를 반환하고 있으나, 내부적으로 잡히는 에러 유형(예: 잘못된roleName)에 따라 400 또는 404 대신 500을 고려해야 하는지 검토해 보세요.
222-222: 프로젝트 삭제 호출 순서
deleteProject를 마지막에 호출하는 흐름이 합리적으로 보입니다. 연관된 데이터(프로젝트 상태, 작업 등)를 미리 정리하는 방식이 적절해 보입니다.
236-236: 타입 변경에 따른 수정 확인
updatedProjectInfo를 ProjectInfoForm으로 받도록 변경됨에 따라, API 요청 구조가 달라졌다면 프런트엔드 측에서도 동일하게 수정되었는지 확인이 필요합니다.
384-384: 역할 검증 시 상태 코드 검토
"유효하지 않은 역할"은 404보다 400(Bad Request)에 가깝게 해석될 수 있습니다. 필요하다면 404 여부가 API 설계에 맞는지 다시 검토해 주세요.
src/mocks/services/teamServiceHandler.ts (9)
2-3: TEAM_DUMMY 및 createTeamUserFormat 임포트 확인
팀 관련 Mock 데이터를 TEAM_DUMMY에서 불러오고, createTeamUserFormat를 사용하는 부분이 정상입니다. 현재 로직에 맞게 반영된 것으로 보입니다.
56-57: 팀 검색 시 승인 대기 멤버 제외
filter((teamUser) => teamUser.isPendingApproval === false) 로직이 팀 내 실제 참여자만 조회하도록 되어 있습니다. 팀원 검색을 분리하고 싶다면 별도의 API를 고려해도 좋겠습니다.
126-139: 팀 탈퇴 시 프로젝트 사용자 삭제
deleteAllProjectUserByTeamId로 해당 팀 내 프로젝트에서도 사용자를 제거하는 것은 논리적으로 일관성이 있어 보입니다.- 다만, 실제 요구사항이 "팀을 탈퇴해도 과거 프로젝트 이력은 유지"해야 한다면, 추가 논의가 필요할 것 같습니다.
147-195: 팀 삭제 로직 점검
- 삭제 순서가 올바르게 설정되어 있어, 프로젝트 > 상태 > 작업 등을 먼저 정리하고 팀을 마지막에 제거하는 구조가 안정적입니다.
- 예외 상황에서
console.error만 찍고 500을 반환하는 로직은 간단하지만, 추후 로깅 체계가 필요할 수 있습니다.
Line range hint 206-220: 팀 초대 수락 시 승인 처리
팀 초대가 존재하지 않을 경우 500을 반환하지만, 404나 400의 의미로 표현해도 좋을 것 같습니다. 실제 API 설계에 맞춰 상태 코드를 재검토해 보세요.
228-243: 팀 초대 거절 시 삭제
초대가 없을 경우 404를 반환하는 부분은 합리적입니다. 거절 시 deleteTeamUser로 팀-유저 관계를 제거하는 흐름이 명확합니다.
282-303: 팀 정보 수정 로직
updateTeam호출 전, 권한을 세부적으로 체크하고 있습니다. HEAD나 LEADER만 수정 가능하도록 확장할지 여부도 검토가 필요해 보입니다.- 현재 로직은 HEAD만 가능한 구조로 보이니, 기획 요구사항과 일치하는지 확인해 주세요.
341-363: 팀원 삭제 시 권한 확인
HEAD 권한만 팀원을 제거할 수 있도록 설계되었습니다. LEADER 등 다른 권한에서 제거가 필요한지 확인이 필요할 수 있습니다.
371-402: 팀원 권한 변경 API
역할 검사 및 변경 로직이 잘 분리되었습니다. 예외 상황에는 500을 반환하지만, 404 또는 400일 수도 있으니 사용자 오류/서버 오류 구분을 조금 더 세부적으로 처리할 여지가 있습니다.
src/mocks/mockAPI.ts (9)
10-10: TEAM_DUMMY 임포트 확인
팀 정보를 편리하게 제어하기 위해 TEAM_DUMMY를 사용하는 것은 적절합니다. 실제 운영 환경과의 차이점을 잊지 않도록 주의하세요.
17-21: Team, TeamInfoForm, ProjectInfoForm, TeamUser 등 추가 타입 임포트
새로운 타입들이 반영됨에 따라 프로젝트 전반에 걸쳐 타입 정합성이 개선될 수 있습니다. 타입 충돌 여부를 다시 한번 점검해 주세요.
58-63: updateTeamUser 함수 예외 처리
teamUser가 없으면 예외를 던지도록 되어 있습니다. 호출 레벨에서 적절히 try-catch로 감싸거나, 사용자에게 명확한 에러 메시지를 제공하도록 해주세요.
65-72: deleteTeamUser 예외 메시지
없는 유저를 삭제하려 할 때 메시지를 잘 표시해주고 있습니다. 404(존재하지 않음)와 400(잘못된 요청) 중 적절한 상태 코드를 사용하여 API 일관성을 유지하는지 확인이 필요할 수 있습니다.
74-81: deleteAllTeamUser 전체 삭제 로직
TEAM_USER_DUMMY 배열을 필터링 후 재할당하는 방식이 명확합니다. 혹시라도 일부만 실패해야 하는 시나리오(트랜잭션)가 있다면 별도 처리가 필요할 수 있습니다.
89-92: findTeam 함수
단순 조회 로직으로 보이는데, 같은 팀 ID가 여러 번 저장될 가능성이 없는지 확인해 보세요.
104-109: deleteTeam 함수
팀을 찾지 못하면 예외를 던집니다. 그 외 로직은 문제 없어 보입니다.
153-165: deleteAllProjectUserByTeamId 함수 검토
findAllProject(teamId)로 얻은 프로젝트에 소속된 유저를 필터링 후, 특정userId만 제거하는 로직입니다.- 실제로 팀 탈퇴 기능과 긴밀히 연동되므로, 중복 제거나 이미 제거된 유저 처리가 필요한지 검토해 보세요.
167-174: deleteAllProjectUser 전체 삭제
프로젝트 단위로 전부 제거하는 로직이 명확합니다.
src/types/RoleType.tsx (1)
15-15: roleName 속성에 null 허용
roleName을 null로 설정할 수 있게 되면서 유연성이 생겼지만, 실제로 null 상태가 어떻게 처리되는지 주의 깊게 확인해야 합니다.
src/types/TeamType.tsx (1)
20-20: TeamForm 구조 변경
TeamInfoForm & { coworkers: TeamCoworkerForm[] } 형태로 단순화되어 가독성이 좋아졌습니다. 다만, creatorId가 필요한 경우가 있다면 주의가 필요합니다.
src/mocks/mockUtils.ts (3)
1-3: [임포트] 역할 검색 함수 제대로 임포트 확인 필요
findRoleByRoleName 함수를 올바르게 불러오는지와 해당 함수의 내부 예외 처리를 재확인하는 것이 좋습니다.
5-16: [팀 유저 객체 생성] 역할 검증 로직과 예외 처리 우수
createTeamUserFormat 함수 내에서 role 부재 시 예외를 던지는 부분이 명확해서 좋습니다. 단, 이 예외가 상위 로직에서 충분히 처리되는지 확인해 주세요.
18-28: [프로젝트 유저 객체 생성] 역할 검증 및 반환 형식 일관성 확인
createProjectUserFormat 함수가 팀 유저 생성 로직과 유사하게 동작하도록 잘 구성되었습니다. 프로젝트와 팀에 대해 동일한 방식으로 역할 검증을 수행하므로 확장에도 유리해 보입니다.
Seok93
changed the title
PR Type
What kind of change does this PR introduce?
Related Issues
What does this PR do?
task_user)는 남기도록 기능 수정roleName을 null로 처리하도록 수정Other information
팀 소속 유저 검색 API에서 팀에 초대된 유저와 참여된 유저를 구별하지 않고, 모든 유저에 대하여 검색이 가능한 상태였습니다. 그래서 팀에 참여하고 있는 유저 내에서 검색이 진행되도록 필터를 추가했습니다.
반복되는 로직을 mockUtils 파일로 분리하였습니다. (createTeamUserFormat, createProjectUserFormat)
프로젝트 생성시 프로젝트원을 추가하는 과정에서 오류가 발생하면 일관성을 해칠 가능성이 있었습니다. 이를 데이터 무결성을 먼저 확인한 뒤 등록하도록 수정하여 일관성을 유지할 수 있도록 만들었습니다.
데이터 타입중 유틸리티로 처리하던 데이터 구조가 이미 별칭으로 선언되어 있어, 이를 이용하도록 수정하였습니다.