디지털 가든

잠시 움켜쥐다: 스물아홉 개의 보류 필드의 부채 상환 리팩터링

2026-09-29 · 약 7분 · 리팩터링 · 제어 바 · B시계 · 부채 상환

어떤 코드 부채의 채권자는 남이 아니라 석 달 뒤의 자신이다.

B시계의 플레이어 뷰에는 한 건의 낡은 부채가 누워 있었다. 3266행의 MyPlayerView에서 가장 불룩한 한 마디는 스물아홉 개의 pendingXxx 필드——플레이어 뷰의 삼층을 걸치고, 서로 무관계하다. 그것들이 존재한 유일한 이유는 제어 바가지연 생성되기 때문이다——태어나기 전에, 사방에서 밀려오는 배치들은 모두「잠시 움켜쥘」수밖에 없고, 강생하는 순간에야 걸친다.

1. 부채 상환의 자세

리팩터링의 칼질은 실로 절제되어 있었다. 독립한 ControllerStateBuffer를 뽑아내고, applyTo()은 원래의 applyPendingControllerState와 한 줄씩 맞춘다——먼저 부채를 갚고, 화폐는 바꾸지 않는다. MyPlayerView는 오십이 행이 날씬해졌다. 그리고 별도의 네 부류 동접두사 필드(설정 패널, 가로세로 전환의 재그리기 요구, seek 시열의 Runnable)는 명확하게 이전을 거부당했다——그것들은 제어 바 배치와 아무 관계도 없으며, 억지로 옮기면 직책이 다시 변질될 뿐이다. 리팩터링 미덕의 절반은 무엇을 옮기느냐에 있고, 나머지 절반은 무엇을 옮기는 것을 거부하느냐에 있다.

2. 고치려 한 병은, 이미 나아 있었다

리팩터링의 명분은 한 마디 걱정이었다——「제어 바가 표시되는 동안 방향 키를 눌러도 숨기는 계기가 재설정되지 않는가?」 실측된 기록이 하층의 결백을 증명했다——CtrlBar: maybeShowController already visible, isForced=true ... timeoutMs=5000. 기제는 MyPlayerView.kt:1009-1021에 있고, 모든 키 콜백(방향 키／미디어 키／D-pad)이 isForced=true를 가지고, 어떤 키든 그 5초를 재설정한다. 연속 세 번 누름, 계기는 모두 바르게 재조판되었다. 버그로 보이는 두 가지 동작도 설계임이 확인되었다——숨은 상태에서 좌우를 누르면 먼저 seek 진행 바 모드로 들어간다；일시 정지 상태에서 제어 바가 상주하는 것은 모두 작의다.

3. 두 번의 재작업

하룻밤에 두 번의 재작업, 모두 같은 규율이 받아냈다. 첫째——ControllerStateBuffer가 SponsorSegment의 import를 빠뜨렸다. 동패키지 클래스는 명시적 import를 요하지 않지만, 패키지를 넘는 그것은 요한다. Mac CI의 compileReleaseKotlin이 붙잡았다. 한 개의 커밋으로 끝났다. 둘째——kb_key_selected를「온면의 밝은 청록＋왼쪽 지시 막대」로 고친 뒤, 키의 문자가 ?attr/tvTextSecondary(회청 #9AA5B4)를 쓰는 것으로 판명됐다. 밝은 바탕에 올려 대비가 부족하고, 멀리서는 밝은 덩어리가 도리어 보기 어렵다. 최종적으로 tvAccentDim 바탕＋2px의 tvAccent 테두리로 고쳐 포커스 상태와 같은 언어를 썼다.

덧붙여 실기 검수 파이프라인의 함정도 기록했다. PlayerActivity의 BACK는 2초 안에 두 번 눌러야 종료한다(첫 번째는 제어 바를 숨길 뿐, exitIntervalMs=2000L 타임아웃으로 계기가 재설정된다)——오토메이션 감초에게 여러 번의 무의미한 누름을 안겼다.

에필로그

같은 밤의 재고 점검의 결론은 맑았다. 플레이어와 탄막은 이미 극치(화질／배속／자막／확대／미러／음 트랙／인코딩／sponsor 스킵. 탄막의 클라우드 키워드, 정규, 블랙 유저, 스마트 스위치), 진정한 단쇄는「콘텐츠 소비」에 있다——댓글 영역의 reply endpoint는 영이고, 번극·추번의 379행 죽은 코드는 깨울 수 있었다. 부채를 갚는 의미란, 바탕을 치워야 다음 전투가 어디로 칠지를 안다는 것이다.

실제 좌표

리팩터링 제어 바 B시계 부채 상환

댓글

← 디지털 가든