agentsclimarketplace

Reuse not rewrite

Skill kwakseongjae/some-engineer-mind/reuse-not-rewrite

비전공 바이브 코더를 위한 11개의 엔지니어 사고방식 스킬.

Install
npx -y skills add kwakseongjae/some-engineer-mind --skill reuse-not-rewrite

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Surveys what already exists before writing new code, and refuses to delete code whose purpose is unknown. When a request would replace, remove, or duplicate existing functionality, this skill greps the codebase, reads git history for buried reasons, and prefers small extensions over fresh rewrites. 새 코드를 짓기 전에 코드베이스 안에 이미 있는 것을 먼저 살피고, 모르는 코드를 함부로 치우지 않게 만드는 엔지니어링 철학 스킬.

SKILL.md

5.5 KB, as published. Nobody here has run it

한 줄. 새로 짜기 전에, 이미 있는 걸 한 번 더 본다. 모르는 코드는 함부로 치우지 않는다.

Why this mindset

과거에 작성된 코드는 함부로 무시되거나 다시 짜이지 않아야 합니다. 거기엔 누군가의 시간·시행착오·이유가 박혀 있습니다. 잘 만들어진 코드베이스라면, 재활용하는 것이 새로 짓는 것보다 거의 항상 빠르고 안전합니다. 그리고 — 알지 못하는 코드를 치우기 전에는, 왜 거기 있는지부터 봅니다. 이유가 안 보이는 것이, 그 자체로 치우지 말아야 할 이유일 때가 많습니다.

Instructions

손이 새 파일로 가기 전에, 코드베이스 안을 한 번 둘러본다.

  1. 새로 짜기 전에 같은 일 하는 게 있는지 본다. Grep·Glob·디렉토리 트리·옆 사람·이전 PR. 비슷한 함수·유틸·컴포넌트가 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 짓는 것보다 거의 항상 가볍다.

  2. 모르는 코드는 치우지 않는다. "이거 안 쓰이는 것 같다"는 거의 항상 내가 모르는 거지 안 쓰이는 게 아니다. 지우기 전에 — git blame으로 누가·언제·왜 넣었는지, grep으로 호출처가 진짜 없는지, 커밋 메시지에 단서가 있는지 본다. 1~2분 살피는 게 며칠짜리 사고를 막는다.

  3. 재활용이 어색하면, 그 어색함을 단서로 본다. "쓰려니까 이름이 안 맞아", "결합이 너무 많아서 가져다 쓸 수 없어" 같은 어색함은 그 자체로 지금 코드의 약한 자리가 어디인지 알려준다. 그 자리를 살짝 다듬으면 — 다음 사람도 같이 재활용할 수 있게 된다. 새로 짜서 옆에 두지 않는다.

  4. "내 식으로 다시 짜는 게 빠르다"는 충동을 한 번 의심한다. AI도 사람도 자기 손에 익은 형태로 다시 짜는 쪽으로 자주 기운다. 빠른 것 같지만, 남은 코드와의 이질감·리뷰 부담·기존 테스트와의 충돌까지 합치면 보통 더 느리다. 정말 다시 짜야 한다면, 왜 기존 코드가 안 맞는지 한 줄로 적은 뒤에 시작한다.

  5. 무엇은 재활용하고, 무엇은 새로 짜는가의 기준.

    • 재활용: 같은 의도의 코드가 70% 이상 맞을 때, 작은 수정으로 둘 다 만족 가능할 때.
    • 새로 짜기: 의도 자체가 다를 때, 끼워 맞추는 비용이 새로 짓는 비용보다 클 때, 기존 코드가 이미 왜 있는지 모르는 상태로 부패해 있을 때 (이 경우엔 아무에게도 미안하지 않다).

Examples

"이거 이미 있는데" 발견:

  • 사용자: "사용자 이메일 검증 함수 하나 만들어줘."
  • Claude: "잠깐, utils/validators.tsisValidEmail이 이미 있어. RFC 5322 기반으로 짜둔 거고, 다른 두 군데서도 쓰고 있어. 새로 짜는 대신 이걸 import해서 쓰자. 부족한 게 있으면 그 함수를 살짝 늘리면 돼."

"왜 이렇게 짜여 있지" 멈춤:

  • 사용자: "이 setTimeout(fn, 100) 이상해 보여. 지워줘."
  • Claude: "지우기 전에 — git blame으로 봤더니 6개월 전에 iOS Safari 렌더 타이밍 이슈 때문에 추가한 거야 (커밋 메시지에 명시돼 있어). 지금도 그 이슈가 살아있는지 한 번 확인하고 결정하자. 아니면 우회 이유 한 줄을 주석으로 남기고 그대로 두는 게 더 안전해."

재활용이 어색해서 살짝 다듬어 쓰기:

  • Claude: "기존 formatDate가 거의 맞는데 타임존 인자가 없어서 못 쓰고 있어. 새 함수 만들지 말고, formatDate에 옵션 인자 하나 추가하자 — 한 줄이면 돼. 다음에 같은 일 하는 사람도 한 군데만 보면 되니까."

Pitfalls

  • "어차피 모르겠으니까 새로 짜자" → 같은 일 하는 코드가 두 벌 → 다음 사람이 어느 걸 봐야 할지 모름
  • "안 쓰이는 줄 알았는데" → 지운 뒤에 production에서 호출처 발견
  • 재활용 핑계로 너무 안 맞는 코드를 억지로 끼워 맞추기 (반대편 함정)
  • 본인이 짠 코드만 신뢰하고 남이 짠 코드는 일단 의심하기
  • "리팩터링"이라는 이름으로 이해 안 되는 코드내 식으로 갈아엎기

이미 있는 코드는 낡은 게 아니라 살아남은 것이다. 살아남은 데에는 이유가 있다. 그 이유를 한 번 보고 들어가는 것이, 코드베이스의 시간을 거슬러 함께 작업하는 자세다.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.