개발, 코딩을 하면 할 수록 걱정과 불안이 줄어들지 않고 오히려 더 고민이 많아진다
내가 이렇게 하는게 맞나? 무언가의 버그, 오류가 있지 않을까 하는 끊임없는 불안들이 있다
그리고 내가 생각했던 설계와 실제로 구현을 했을때 설계가 달라져야하는 상황들이 많았다
빠른 피드백, 테스트 코드의 가드레일, 구현을 먼저 해서 갇힌 생각 대신 테스트코드를 작성하고 더 나은 설계를 위해 미루는 것
Q. 말 나온 김에, TDD를 왜 만들었나? 나는 걱정이 많고 불안해하는 사람이다. 그리고 나에게 프로그래밍은 끊임없는 불안의 원천이었다. 내가 뭘 까먹었지? 내가 뭘 망가뜨렸지?
그런데 TDD로 개발하면 이 불안함이 사라진다. 실패할 만한 테스트 케이스가 더 생각나지 않는다? 그러면 내 프로그램이 동작함을 확신할 수 있다. 조금이라도 불안함이 생긴다? 그냥 다음 테스트 케이스를 작성하면 된다.
물론 결함 밀도 줄이기, 설계 의사결정에 대한 피드백 빨리 얻기, 구현 설계를 진화시키기 등 TDD의 기술적 이득도 많다. 하지만 프로그래밍에 대한 불안함으로부터 해방되었다는 것, 프로그래밍이 주는 감정적 경험이 완전히 전환되었다는 것. 이게 나에겐 가장 중요하다. 이게 내가 TDD를 만든 이유다.
…
Q. 나는 구현이 너무 뻔하게 느껴져서, 구현을 먼저 한 다음에 Red-Green 테스트를 해볼 때가 있다. 이 방식에 대해 어떻게 생각하는가?
그건 ‘이 구현 방식이 옳다’는 가정을 하고 있기 때문일 것이고, 그 가정이 옳을수록 당연히 테스트를 먼저 작성하는 방식의 이점은 줄어든다.
그런데 나는 언제나 이렇게 생각한다. “나는 계속해서 학습하고 경험해나갈 것이고, 지금이 내가 가장 무식한 순간이다.”
즉 나는 내가 계속 학습할 거라고 가정하며, 상황이 변할 거라고 가정한다. 내가 더 많이 배워야 하고 더 많이 상황이 바뀔수록, 나는 최대한 의사결정을 뒤로 미루길 원한다. 이건 일반적인 원칙이다. 데이트를 하든 요리를 하든 똑같다.
더 많이 예측할 수 있다면, 더 큰 점프를 뛸 수 있다. 근데 내가 프로그래밍하면서 가장 사랑하는 순간은, 내가 죄다 안다고 생각하고 쭉쭉 진행하고 있었는데 갑자기 훨씬 나은 구현 방식이 있었다는 걸 깨닫는 순간이다. 나는 이런 순간을 최대한 자주 경험하고 싶다. 그래서 나는 TDD를 한다.
머릿속에 그림이 확실히 그려지고, 어떤 입력이 어떤 출력을 만들지 확신할 수 있다면 그냥 구현하면 된다. 하지만 실수를 많이 할수록, 더 많이 학습할수록, 세상이 더 예측불허하게 변할수록, 지금 당장 약속하지 않고 나중으로 미루는 게 더 유리하다.
켄트벡 https://www.stdy.blog/xp-tdd-and-vibe-coding-kent-beck-interview-with-programmatic-engineer/ https://www.youtube.com/watch?v=aSXaxOdVtAQ