피드백은 프로그래머에게 큰 도움을 주며 필수이다. 모든 코드는 작성되거나 수정된 후 실전에 배치되기 전에 검증된다. 검증 결과는 프로그래머 작업에 대한 피드백을 제공한다.
오늘은 테스트 주도 개발이 프로그래멍게 주는 피드백은 무엇인지, 그리고 다른 기법이 주는 피드백과 어떤 차이를 가지는지 강의를 통해 살펴볼 예정이다.
기대 출력 피드백
피드백 종류에 따라서 특징, 장단점이 있다.
사용자 피드백
- 사용자가 직접 코드를 사용한 후 경험한 버그나 불만을 제보한다.
- 앤드 유저라고 불리는 사용자들이 써보고 피드백을 줄 수 있다.
- 가장 확실한 피드백이면서, 제품과 비즈니스 입장에서는 피해가 큰 피드백이다.
-> 사용자가 사용을 하면서 어떤 문제 혹은 불만이 발생한 것이기 때문에 사용하는 입장에서 비즈니스 피해가 생겼을 수도 있고, 소프트웨어를 만드는 입장에서는 고객 평판이 떨어지는 요인이 될 수 있다.
Quality Assurance (QA)
-
전문 인적 자원에 의한 인수 테스트이다.
-
사용자 피드백 보다는 그 전 단계에서 받을 수 있는 피드백이다.
-
사용자 피드백과 유사한 피드백을 얻을 수 있다.
-
소프트웨어를 만들고 나서 고객에게 인도하는 과정에서 많이 일어난다.
-> 사람이 직접 인력을 사용해서 소프트웨어를 평가한 결과를 얻는다.
-> 소프트웨어 품질과 관련된 전문 인력들이 여러 경우를 고려해서 실제로 사용해보는 것이다.
프로그래머 테스트
-
프로그래머가 직접 피드백 장치를 준비한다.
-
QA에 의한 피드백보다 조금 더 프로그래머와 가까운 곳에서 제공되는 피드백이다.
-
프로그래머가 작성한 코드가 올바르게 동작하는지 검증하는 또 다른 코드(테스트 코드)를 만들어서 자동화된 테스트를 실행하는 방법이다.
-
코딩 비용이 늘어나지만, 한번 작성된 코드는 자동화 되기 때문에 별도의 인력의 도움은 받지 않아 실행비용은 저렴하다.
-
작성된 코드가 프로그래머의 손을 벗어나기 전에 피드백을 받을 수 있다.
-> 더 빨리 코드의 문제를 해결할 수 있다.
-> 프로그래머에게 조금 더 친밀한 피드백을 주기 때문에 발견된 문제를 해결하기 쉽다.
도구 피드백
-
컴파일 오류, 정적 검사 등 프로그래머가 사용하는 도구가 제공하는 피드백이다.
-
프로그래머가 직접 수고를 들이지 않고 얻을 수 있는 높은 품질의 피드백이다.
-
코드가 프로그래머의 손을 벗어나기전에 먼저 피드백을 얻을 수 있다.
오버엔지니어링
-
프로그래머는 요구사항 명세에 명확히 지정되지 않은 성능 달성이나 구현 설계 품질 개선에 빠져드는 경향을 가진다.
-
이런 목표는 그 자체로 나쁜 것이 아니지만 지나치면 더 중요한 목적, 기능 요구사항에 써야 할 자원을 불필요하게 낭비하게 된다.
-
테스트 주도 개발은 가장 중요한 목표를 우선 달성하도록 유도하며 오버엔지니어링에 빠졌음을 느낄 때 안심하고 다음으로 나아갈 수 있도록 "모든 테스트가 성공했습니다."라는 피드백을 제공한다.
회고
나는 테스트 주도 개발의 핵심은 RED -> Green -> Refactor 의 단계가 계속 돌아가는 것이라고 느꼈었다.
오늘 강의를 듣고 나서는 테스트 주도 개발의 핵심은 정해진 절차가 아니라 짧은 주기로 지속되는 피드백이구나 라고 생각이 바뀌었다.
그리고 그 피드백에 기반해 안정적으로 지식과 코드를 늘려 나가는 것이 핵심 목적이었구나.
