Repository navigation
refactor(setting): 네 화면에 복제된 프로필 이미지 크기 134dp 를 단일 출처로 모은다 #1782
Description
작업 유형
refactor — 동작 변경 없는 구조·책임·경계 개선
주 담당 모듈
setting — 설정
개요
프로필 이미지 크기 134.dp 가 네 파일에 흩어져 하드코딩돼 있다. 주인이 없어서 한 곳만 고치면 나머지가 남는다.
| 파일 | 위치 |
|---|---|
feature/setting/.../screen/ProfileEditScreen.kt |
132 — Box(modifier = Modifier.size(134.dp)) |
feature/setting/.../screen/ReceiverRegisterScreen.kt |
184 — Box(modifier = Modifier.size(134.dp)) |
feature/setting/.../screen/RecipientSetScreen.kt |
64 — modifier = Modifier.size(134.dp) |
feature/receiver/.../senderdetail/SenderDetailScreen.kt |
174 — .size(134.dp) |
이 레포는 dimens.xml 이 0개고 AfternoteDesign 도 colors·typography 두 축뿐이라, 치수를 코드에 두는 것 자체는 관례가 맞다. 문제는 하드코딩이 아니라 같은 값이 네 벌로 복제돼 단일 출처가 없다는 점이다.
완료 조건
- 네 곳이 정말 같은 «프로필 이미지 크기» 인지 먼저 확인한다 — 우연히 같은 숫자면 통합하지 않는다. 시안에서 각 화면의 해당 노드를 대조할 것
- 같은 개념이면 단일 출처로 모은다.
AfternoteDesign에 치수 축을 새로 만들지는 말고(축 신설은 별건이다), 공용 컴포저블이 이미 있으면 그쪽에 흡수하는 편을 우선 검토 -
feature:receiver와feature:setting두 모듈에 걸치므로 공용 자리는core:ui가 된다. 모듈 경계를 넘는 이동이 과하면 «같은 값임을 확인했다» 는 근거만 남기고 통합은 보류해도 된다 — 그 판단도 이 이슈에서 내린다 - 시각 변경이 없어야 한다. 스크린샷 골든이 흔들리면 통합이 틀린 것이다
자식 이슈
참고
dimens.xml 로 빼는 방향은 택하지 않는다 — Compose 에서는 타입 안정성과 컴파일 검증을 잃고 간접층만 늘어난다.
같은 부류의 다른 값들(112·128·130·137·160·180·183 등)도 흩어져 있지만, 이 이슈는 복제가 확인된 134 하나만 다룬다. 나머지는 각각 한 곳에서만 쓰이므로 지금은 문제가 아니다.
실기동 화면
에뮬레이터 Pixel 7(API 34) 실기동, QA823 계정, 실서버 afternote.kro.kr. 설정 프로필 화면의 사진 자리다. 134dp 치수가 실제로 어떻게 보이는지의 기준 화면이다. 이메일 칸은 가렸다.
Activity