절대적인 정답은 없으며, 바로 그것이 핵심입니다. 속도 대 유지보수성은 맥락에 달려 있습니다 — 코드의 **중요도(stakes)**와 예상 수명에 따라 엄격함의 수준을 맞춥니다. 일회용 prototype과 payments core는 전혀 다른 기준이 마땅합니다. 리드의 역할은 그 트레이드오프를 의도적으로 내리는 것이지, 우연히 일어나게 두는 것이 아닙니다.
결정을 위한 framework
코너를 자르기 전에 세 가지를 물어보세요.
절대적인 정답은 없으며, 바로 그것이 핵심입니다. 속도 대 유지보수성은 맥락에 달려 있습니다 — 코드의 **중요도(stakes)**와 예상 수명에 따라 엄격함의 수준을 맞춥니다. 일회용 prototype과 payments core는 전혀 다른 기준이 마땅합니다. 리드의 역할은 그 트레이드오프를 의도적으로 내리는 것이지, 우연히 일어나게 두는 것이 아닙니다.
코너를 자르기 전에 세 가지를 물어보세요.
// TODO, RFC의 메모). 무엇을 어떤 이유로 맞바꿨는지 정확히 압니다.압박 속에서도 core는 깨끗하게 유지하세요: 이름이 잘 붙은 경계, 테스트된 critical path. 지저분함은 떼어내기 싼 가장자리로 밀어내세요.
마감이 빡빡할 때 정직한 수는 stakeholder와 범위나 시간을 다시 협상하는 것이지, 조용히 부서지기 쉬운 것을 출시하는 것이 아닙니다. "feature A와 B로는 날짜를 맞출 수 있지만 C는 일주일 미뤄집니다"는 진짜 대화입니다. 취약한 코드를 조용히 출시하는 것은 누구의 동의도 없이 팀의 미래 velocity를 써버리는 일입니다.
항상 속도만 최적화하는 팀은 부채에 빠져 죽고, 항상 과도하게 다듬는 팀은 시장을 놓칩니다. 리드의 가치는 판단력입니다 — 맥락에 맞게 엄격함을 보정하고 트레이드오프를 드러내고 책임지게 만들어, 오늘의 shortcut이 팀이 갚을 수 있는 선택이 되게 하는 것입니다. 떠안게 되는 뜻밖의 일이 아니라.