tidy-as-you-go

name	tidy-as-you-go
description	Small grooming each time code is finished, named, reviewed, or committed — removing unused imports, variables, and dead code; tightening identifier names to expose intent; and leaving the file one notch cleaner than it was found. Never expands into unrelated refactors that bloat the PR. 코드를 작성·수정·리뷰·커밋·완료할 때마다 작은 정돈을 습관화하는 엔지니어링 철학 스킬.
when_to_use	Use whenever code is being wrapped up, named, reviewed, or committed — phrases like "done", "ready to commit", "wrap up", "clean up", "tidy", "naming", "다 됐어", "이제 끝났어", "커밋할게", "PR 올릴게", "정리 좀", "이 이름 괜찮아?" — and immediately after finishing a feature, just before closing a file, or whenever unused code is noticed mid-work.
allowed-tools	Read Edit Grep

한 줄. 떠나기 전에, 들어왔을 때보다 한 단계 깨끗하게.

Why this mindset

항상 정돈하는 습관을 들이자. 사용하지 않는 변수, import를 정리하자. 의도가 드러나는 변수명을 지을 수 있도록 노력하자. 그 이외에도 어떻게 하면 코드를 깨끗하게 관리할 수 있을지에 대해 고민하자.

Instructions

정돈은 따로 잡는 큰 행사가 아니다. 코드를 만질 때마다 곁들이는 작은 동작이다.

1. 마무리 직전, 한 번 훑는다. 기능을 다 짠 뒤·커밋 직전·"이제 됐다" 시점에 파일을 한 번 더 위에서 아래로 본다. 안 쓰는 import, 안 쓰는 변수, 디버그용 print/console.log, 주석 처리만 해놓은 죽은 코드 — 보이면 그 자리에서 지운다.

2. 이름은 한 번 더 의심한다. 변수·함수·파일 이름이 "이게 뭐 하는 건지" 한눈에 드러나는지 다시 본다.

   • data, temp, result, handle, doStuff 같은 이름은 거의 항상 더 좋은 이름이 있다.
   • 좋은 이름의 기준: 읽는 사람이 함수 본문을 안 봐도 의도를 짐작할 수 있는가.
   • 떠오르지 않으면 "이 함수 한 문장으로 설명해줘"를 자기 자신한테 묻고, 그 문장에서 동사·명사를 뽑는다.

3. 보이스카우트 룰. 원래 작업과 무관해도, 같은 파일에서 명백히 잘못된 작은 것이 보이면 지나가는 김에 고친다. 단, 별건 손대지 않는다 — "지나가는 김에"가 리팩터링 폭주가 되면 그건 정돈이 아니라 새 작업이다.

4. 포맷·정렬은 도구에 맡긴다. prettier, eslint --fix, black, gofmt 같은 게 깔려 있으면 그걸 돌린다. 손으로 들여쓰기·따옴표·세미콜론을 다투지 않는다. 도구가 없는 프로젝트면 한 번 깔자고 제안만 하고, 본업을 멈추진 않는다.

5. 정돈한 만큼만 정돈했다고 말한다. 사용자에게 마무리를 보고할 때 "이번에 정리한 것"을 짧게 한 줄 적는다. "안 쓰는 import 3개, 디버그 로그 2줄 제거. tmpData → parsedRows로 이름 변경." 이게 다음에 누가 봤을 때의 이정표다.

Examples

기능 끝낸 직후:

• 사용자: "검색 기능 다 만들었어."
• Claude: "마무리 전에 한 번 훑었어 — useState에서 안 쓰던 loading, 위에 디버그 console.log 한 줄, 그리고 data를 users로 바꿨어. 지금이 더 읽기 좋아. 커밋해도 될 것 같아."

이름이 안 떠오를 때:

• 사용자: "이 함수 이름 뭐로 하지?"
• Claude: "이 함수 한 문장으로 풀면 '이메일 형식이 맞는지 검사해서 true/false 돌려준다'야. 그럼 isValidEmail 정도가 자연스러워. checkEmail은 검사 후 뭘 하는지 모호해서 한 단계 약해."

선 긋는 흐름:

• 사용자: 기능 작업 중인데 옆 파일에 거대한 함수가 보임.
• Claude: "이 옆 파일에 100줄짜리 함수가 좀 어수선해 보이긴 해. 다만 지금 작업 범위 밖이라, 표시만 해두고 손은 안 댈게. 따로 정리할 일감으로 빼두면 좋겠어."

Pitfalls

• "나중에 한꺼번에 정리하지" → 그 "나중"은 거의 오지 않는다.
• 의미 없는 이름 (data1, temp, foo, value)이 마이그레이션 없이 살아남는 일.
• 안 쓰는 import·변수가 누적되면서 파일이 무거워 보이는 일.
• 정돈한답시고 작업 범위 밖까지 파헤쳐 PR이 거대해지는 일.

정돈은 완벽주의가 아니다. "내가 떠난 자리가 들어왔을 때보다 한 단계만 깨끗하면 된다." 그 한 단계가 매번 쌓이는 게 깨끗한 코드베이스다.