Conversation
donggyu412
commented
Dec 15, 2025
- 추천 운동 삭제 api 연결
- 프로필 수정 UI 수정
| }, | ||
| }); | ||
|
|
||
| export default ProfileEditModal; |
There was a problem hiding this comment.
코드 리뷰
-
버튼 비활성화:
handleSaveProfile()을 호출하기 전에handleSave()를 호출하고 있습니다. 이 경우,tempValue가 분리된 프로필 필드가 아닌 상태에서 업데이트되고 있습니다. 사용자가 버튼을 두 번 클릭하는 경우 API 요청이 두 번 발송될 수 있습니다. 로딩 중일 때는 버튼을 비활성화해야 합니다. -
정상적인 오류 처리 누락: API 호출 후 오류 الرد, 특정 오류 메시지를 제공하지 않는 경우도 있습니다. 로그인 등의 상태에서 오류가 발생할 경우 사용자에게 의미 있는 피드백을 제공하는 것이 좋습니다.
-
성별 선택 UI: 성별 선택 UI는
Picker대신TouchableOpacity를 사용하여 선택할 수 있도록 디자인되었습니다. 그러나 Accessible(접근성) 고려가 부족할 수 있습니다. 이 요소들을 스크린 리더와 호환되도록 하면 좋습니다. -
상태 관리: 성별 및 건강 목표 업데이트를 위해 상태를 두 번 업데이트하는 부분이 보입니다. 상태 업데이트를 단일화하여 코드 효율성을 높일 수 있습니다.
-
바인딩 문제:
useState후에 사용하는 state는 항상 최신값을 반영하지 않을 수 있습니다. 따라서 비동기적으로 호출되는 부분에서 문제가 발생할 수 있습니다.useCallback을 사용하여 디펜던시를 명확하게 설정하는 것이 좋습니다. -
UI 수정: 각 UI 관련 스타일을 다루는 부분에서 동일한 스타일이 중복 사용되고 있습니다. 스타일 분리 및 재사용 가능하도록 컴포넌트 리팩토링 시 필요합니다.
-
기타 체크 포인트: 다른
return이 무시되는 곳이 있을 수 있습니다. 전체 리턴 구조가 일관되지 않도록 보장해야 합니다. -
네거티브 내비게이션 피드백: 사용자가 비밀번호 변경 모달 실행을 취소할 때에 대한 피드백이 없습니다. 이런 부분을 추가하면 사용자 경험이 개선될 수 있습니다.
이와 같은 이유로 이 코드에는 결점이 있으며, 위의 모든 수정 사항을 반영한 후에 다시 머지할 수 있도록 요청합니다.
| }, | ||
| }); | ||
|
|
||
| export default RoutineRecommendScreen; |
There was a problem hiding this comment.
잠재적인 버그 및 위험
-
상태 관리:
setLoading(true)와setLoading(false)가 제대로 짝을 이루고 있는지 확인해주세요. 로딩 상태를 특정 조건에서만 설정하는 경우, 사용자에게 피드백을 적절히 제공하지 못할 수 있습니다. -
에러 핸들링: 여러 API 호출에서는 에러를 잡아내고 있지만,
totalSuccess와totalFail변수를 사용하는 지점에서 정확히 어떤 에러가 발생했는지에 대한 정보가 부족합니다. 로깅을 개선하거나 사용자에게 좀 더 구체적인 피드백을 제공하는 것이 좋습니다. -
if-else구문:plan.planId에 대한 조건문이 여러 번 반복됩니다. 중복 코드를 줄이기 위해 공통 로직을 함수로 분리하고 호출하는 방법을 고려해주세요. -
API 통신 결과 체크: 삭제 API 호출 후 결과를 확인할 때,
result가 항상 객체라고 가정하는 것은 위험할 수 있습니다. API에서 예기치 않은 형식의 응답을 받을 경우 오류가 발생할 수 있습니다. 이 부분에 대한 추가적인 검증이 필요합니다. -
Alert.alert()의 중복 사용: 사용자에게 보여줄 프로세스 중 주요한Alert.alert()호출이 종종 반복됩니다. 이를 함수로 감싸서 중복을 줄여보세요. -
UI 요소 일관성: 삭제 확인과 관련된 Alert에서 Delete 버튼을 클릭했을 때의 동작이 일관되도록 검토해야 합니다 (예: 대화 상자의 제목이나 내용 등).
개선 제안
- 사용자가 마지막 요청 후 어떤 작업을 수행하는지에 대한 피드백을 명확히 하기 위해,
Alert.alert()의 메시지를 구체적으로 작성하는 것을 권장합니다. - 조건문에 대한 반복을 피하기 위해, 중복되는 코드 블록을 메서드로 재활용하면 가독성이 향상됩니다.
- 에러 메시지 및 로깅을 향상시켜, 문제 발생 시 디버그가 용이하도록 개선하세요.
- 사용자에게 혼란을 방지하기 위해 사용자가 실제로 어떤 작업을 수행하고 있는지를 항상 명확히 알리는 UI가 필요합니다.
|
|
||
| throw error; | ||
| } | ||
| }, |
There was a problem hiding this comment.
다음은 코드 패치에 대한 리뷰 코멘트입니다:
-
예외 처리:
deleteRecommendedExerciseByDate메소드에서 오류를 로깅하고 있습니다. 그러나throw error;라인 앞에 예외가 발생했을 때 어떤 종류의 예외인지 확인하고 적절한 로깅을 추가하는 것이 좋습니다. 예를 들어 잘못된 요청이나 네트워크 문제에 따른 예외 등입니다. -
응답 검증이 부족함:
response에서 반환된 값을 확인하지 않고 있습니다. API 호출 후 응답의 상태 코드를 확인하고 적절히 처리하는 로직을 추가해야 합니다. 예를 들어, 상태 코드가 200이 아닐 경우 적절한 오류 메시지를 반환해야 합니다. -
Promise 반환 타입:
deleteRecommendedExerciseByDate메소드의 반환 타입이Promise<any>로 지정되어 있습니다. 대신에 API 응답의 예상 구조를 반영한 구체적인 타입을 사용하는 것이 좋습니다. 이는 코드의 가독성을 높이고 오류를 예방하는 데 도움이 됩니다. -
메소드 주석: 메소드에 대한 주석이 포함되어 있지만, 반환 값에 대한 설명이 빠져 있습니다. 어떤 형식의 데이터가 반환될지 명시해 주면 좋겠습니다.
-
정적 분석 도구 사용: 코드 품질을 높이기 위해 TypeScript의 정적 분석 기능을 최대한 활용해야 합니다. 예를 들어,
error: any를 더 구체적으로 정의하거나response타입을 명시하는 것이 좋습니다.
개선 사항을 반영해 코드를 수정하면 유지보수성과 안정성이 높아질 것입니다.