[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 8장: 프로그래머 피드백

본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

기대 출력 피드백

• 사용자 피드백
  • 사용자가 직접 코드를 사용한 후 경험한 버그나 불만을 제보
  • 굉장히 확실한 피드백인 반면, 제품과 비즈니스 입장에서 피해가 큰 피드백
• Quality Assurance
  • 전문 인적 자원에 의한 인수 테스트
  • 소프트웨어 품질에 전문성을 가진 인력들로부터 테스트를 받을 수 있음
  • 주로 개발 완료 후 고객에게 인도되기 전에 수행
• 프로그래머 테스트
  • 프로그래머가 직접 피드백 장치를 준비
  • 비용이 저렴함
    • 프로그래머가 테스트 코드를 직접 작성하여 자동화된 테스트를 수행함
  • 이른 시점에 코드에 대한 피드백을 얻을 수 있음
    • 고객에게 전달되기 전에 피드백을 얻음
    • 프로그래머에게 더욱 친숙한 방식으로 피드백이 전달되기 때문에 문제를 발견하기 쉬움
• 도구 피드백
  • 컴파일 오류, 정적 검사 등 프로그래머가 사용하는 도구가 제공하는 피드백

 

 

오버엔지니어링

• 프로그래머는 요구사항 명세에 명확히 지정되지 않는 성능 달성이나 구현 설계 품질 개선에 빠져드는 경향을 가짐
• 이런 목표는 그 자체로 나쁜 것은 아니지만, 지나치면 더 중요한 목적인 기능 요구사항에 써야 할 자원을 불필요하게 낭비하게 됨
• 테스트 주도 개발은 가장 중요한 목표를 우선 달성하도록 유도하며 오버엔지니어링에 빠졌음을 느낄 때 안심하고 다음으로 나아갈 수 있도록 피드백을 제공

 

 

핵심은 피드백

• 테스트 개발의 핵심은 정해진 절차가 아니라 짧은 주기로 지속되는 피드백
• 피드백에 기반해 안정적으로 지식과 코드를 늘려 나가는 것이 목적