TDD Isn't Design

https://tidyfirst.substack.com/p/tdd-isnt-design?fbclid=IwAR2CvJPKgRkoSiKl6LfHIugUsFyJI2bFkfrB80oebLdb_V4PeWbJgaWBUBw

프롬프트는 다음과 같았습니다: "TDD만으로 훌륭한 시스템 설계가 나올 수 있다는 생각은 마음에 들지 않습니다."
결론적으로 동의합니다. 당신은 디자인 결정을 내려야 합니다. 더 자세한 답변은 다음과 같습니다.

조금이라도 상식이 있는 사람이라면 TDD가 디자인의 필요성을 대체한다고 말하지 않습니다. 핵심 질문은 '언제'입니다. 첫 번째 테스트를 작성하고 통과하기 전에 몇 가지 구현 디자인 결정을 제안하고 있습니다. 특히 몇 달에서 몇 년이 걸리던 과거의 디자인 '단계'와 비교하면 그렇게 끔찍해 보이지는 않습니다.

TDD offers:

• 인터페이스 디자인 결정에 대한 즉각적인 피드백. 여전히 결정을 내려야 합니다. 결정한 만큼 디자인이 좋아지지만, 결정의 질에 따라 고통도 반비례하게 됩니다.
• 인터페이스 디자인 결정과 구현 디자인 결정을 분리하세요. 이 방법은 누가 설명해주지 않아도 항상 저에게 권장되는 것이었습니다.
• 일단 인터페이스를 테스트하기 위한 결정을 내리고 노트를 작성하면 구현 디자인 결정이 가장 낮은 첫 번째 기준인 '코드가 작동하는가'를 통과했는지 여부에 대한 즉각적인 피드백을 받을 수 있습니다.

인터페이스 디자인 결정이 있는 상황에서 구현 디자인 결정을 내리는 데 자신이 없다면 괜찮습니다. 구현 디자인 결정을 몇 개만 내려야 하는지 실험해 보세요. 저는 최소한의 결정이 무엇인지 궁금합니다. 경험상 답은 '0'인 것으로 나타났습니다. 이 숫자는 직접 확인해 보시기 바랍니다.