Create Week 9 Mission 1

[chldnjswo]

📝 미션 번호

9주차 Mission 1

📋 구현 사항

• 마이페이지 UI구현
• 팔로잉 리스트 구현
• Retrofit 기반 ReqRes API 연동 구조 구현

📋 이슈

• 현재 에뮬레이터 DNS 이슈로 실제 응답 확인은 제한됨

📎 스크린샷

✅ 체크리스트

• Merge 하려는 브랜치가 올바르게 설정되어 있나요?
• 에뮬레이터 또는 실제 기기에서 정상 동작하나요?
• 불필요한 주석 및 Log가 제거되었나요?

🤔 질문 사항

[Dawon-Y]

안녕하세요! 9주차 과제 진행하시느라 고생 많으셨습니다💚

---

1) 총평

• **레이어링(DTO → Domain Model → UiState)**이 깔끔하고, 네트워크 응답을 Result로 감싸서 ViewModel에서 분기하는 구조가 안정적입니다.
• REQRES_API_KEY 체크처럼 “실행 환경에서 터지는 이슈”를 먼저 잡아주는 방어도 좋습니다.
• 다만 Factory에서 RetrofitProvider.profileService를 직접 끌어오는 방식은 확장성/테스트성 관점에서 아쉽고, errorBody.string() 처리처럼 한 번 읽으면 재사용 불가한 바디 처리도 주의 포인트가 있습니다.

---

2) 파일별 리뷰

2.1 ProfileDtos.kt (DTO)

좋은 점

• SerializedName 매핑 정확.
• ReqResUserDto.fullName 계산 프로퍼티가 아주 실용적입니다.
  • first/last 비었을 때 email, 그것도 비면 "Unknown User"로 fallback → UI에서 null/빈값 대응 부담을 줄여줌.

개선 제안

• DTO 레이어에서 fullName을 만들어두는 건 편하지만, 팀 컨벤션에 따라 “DTO는 최대한 순수하게” 두고 mapper에서 처리하기도 합니다(필수 아님).
• UserListResponseDto.data가 기본값 emptyList()라 NPE 리스크가 줄어드는 점은 좋습니다.

---

2.2 ProfileApiService.kt (Retrofit)

좋은 점

• endpoint 정의가 reqres 형식에 맞고 명확합니다.
• per_page를 기본 8로 준 것도 “팔로잉 캐러셀/리스트”엔 합리적.

개선 제안

• 반환 타입이 Response<...>라 repository에서 HTTP 에러 처리가 필요한데, 지금 repository가 처리하고 있어 좋습니다.
• 추후 실무라면 suspend fun getUser(...): SingleUserResponseDto로 바꾸고 interceptor/exception mapper로 처리하는 방식도 있으나 과제에서는 현재 구조가 이해하기 쉽습니다.

---

2.3 ProfileUser.kt (도메인 모델)

좋은 점

• UI에서 바로 쓰기 좋은 형태(name, avatarUrl)로 정리되어 있어 ViewModel/UI가 깔끔해집니다.

개선 제안

• 현재 name이 “표시용 문자열”로 확정되어 있어서, 만약 UI에서 “성/이름 분리”가 필요해지면 다시 DTO를 참조하게 될 수 있습니다.
• 하지만 이번 과제 범위에서는 지금이 오히려 깔끔합니다.

---

2.4 ProfileRepository.kt

좋은 점(핵심)

• runCatchingResponse로 공통 처리(성공/실패/empty body/HTTP error/exception)를 한 군데로 모아둔 게 베스트입니다.
• getProfile() / getFollowing()이 Result를 반환하니 ViewModel이 Response를 직접 만지지 않아도 됩니다(레이어 분리 좋음).
• getProfile()에서 body.data?.toProfileUser() null 처리까지 명확합니다.

주의/개선 포인트

1. errorBody()?.string()은 한 번 읽으면 소모됩니다.

   • 지금은 즉시 메시지로 바꿔서 Result.failure에 넣으니 실질 문제는 적지만,
   • 로깅/재시도 등에서 다시 읽으려 하면 안 됩니다(현재 코드에서는 OK).

2. Result.failure(RuntimeException("HTTP ${code}: $errorMessage"))로 예외를 래핑해서 올리는데,

   • ViewModel에서 UnknownHostException만 특별 처리하고 있습니다.
   • HTTP 401/403/500 등도 구분해서 UX를 다르게 하고 싶다면 sealed class ApiError 같은 걸 쓰는 방식도 있습니다(선택).

---

2.5 ProfileUiState.kt

좋은 점

• Idle / Loading / Success / Error로 구성한 sealed interface는 Compose에서도 쓰기 좋은 정석입니다.
• Success가 followingUsers 기본 emptyList를 갖는 것도 깔끔.

개선 제안

• Error message가 String 하나인데, 추후 재시도 버튼/에러 타입 분기하려면 ErrorType을 같이 두는 것도 방법입니다(지금은 충분).

---

2.6 ProfileViewModel.kt

좋은 점

• forceRefresh 옵션 + “이미 Loading/Success면 중복 요청 방지” 처리 좋습니다.
• API KEY 체크를 네트워크 호출 전에 해서, 원인 파악이 쉬움.
• 사용자/팔로잉을 순차로 가져오고, 실패하면 즉시 Error로 전환하는 흐름이 명확합니다.
• 자기 자신 필터링(filterNot { it.id == user.id }) 좋습니다.

개선/제안 포인트

1. loadProfileScreen()이 “user + following” 둘 다 성공해야 Success가 되는 구조인데,

   • UX 관점에서 “프로필은 떴는데 팔로잉만 실패” 같은 경우도 있을 수 있습니다.
   • 지금은 에러로 통째로 떨어집니다.
   • 과제에서는 OK지만, 좀 더 탄탄하게 하려면:
     • Success(user, followingUsers = emptyList())로라도 보여주고
     • 팔로잉 실패는 부분 에러로 처리하는 방식도 고려할 만합니다.

2. toUserMessage()에서 UnknownHostException만 특수 처리한 점은 좋은데,

   • HttpException(Retrofit2는 보통 Response 기반이라 덜 나오지만)이나
   • “HTTP 401” 같은 메시지를 사용자 친화적으로 매핑할 수도 있습니다(선택).

---

2.7 ProfileViewModelFactory.kt

좋은 점

• 과제 환경에서 DI 없이도 돌아가게 Factory로 만든 건 현실적인 선택입니다.
• modelClass.isAssignableFrom 체크도 정석.

아쉬운 점(가장 큼)

• 기본 파라미터로 ProfileRepository(RetrofitProvider.profileService)를 내부에서 만들어 버리면:
  • 테스트가 어려워지고
  • 모듈 의존성이 강해지고
  • “Factory가 Service Locator” 역할을 하게 됩니다.

개선 방향(선택)

• 최소 개선: Factory 생성 시 repository를 반드시 주입하도록(기본값 제거)
• 더 정석: Hilt @HiltViewModel로 전환 + repository도 DI

---

3) 결론

• 현재 구조는 과제 기준 상위권 품질이고, 특히 Repository에서 Result로 감싸는 공통 처리/매핑이 좋습니다.
• 가장 큰 개선 포인트는 **Factory의 의존성 주입 방식(테스트/확장성)**이고, 그 다음이 부분 성공 UX(프로필 성공/팔로잉 실패 분리) 정도입니다.

---

워크북 진행하시느라 수고하셨습니다! 궁금한 점 있으시면 언제든 말씀해 주세요!