전통적인 개발 진행
문제발생 요구사항 발생
기능구현
Console 에 값 찍어
보기
간단한 테스트
Yes
15.
에러발생?
No
16.
완료!
9
17.
일반적인 개발
1. 특정모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다.
“어디까지 짰더라?”
“아, 내가 지금 뭘 하는 거였지?”
“이 모듈이 무슨 기능을 해야 한대더라?”
2. 작업 분량이 늘어날수록 확인이 어려워진다.
“로그가 어디 있더라?”
“이것도 화면으로 출력해보고…”
10
18.
일반적인 개발
3. 개발자의집중력이 필요해진다.
“앗! 화면 지나갔다!”
4. 논리적인 오류를 찾기가 어렵다.
“여기서 그러니까 이 값이 들어가면 나와야 하는 게… 아… 이게 맞던가?”
5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 되는 경우가 많다.
“맞아! 개인고객 인증을 고치면 법인 고객인증 부분도 함께 고쳤어야 했었지!!”
6. 테스트 케이스가 적혀 있는 엑셀 파일을 보며 매번 테스트를 실행하는 게 점점 귀찮아져서
는 점차 간소화하는 항목들이 늘어난다.
“날짜? 1111. 주민번호? 우선 222222-2222222. 주소? 서울 개똥이네”
11
19.
일반적인 개발
7. 코드수정 시에 기존 코드의 정상 동작에 대한 보장이 어렵다.
“휴~ 찾았다. 여길 고쳐야 하는 거였군! 아, 근데 이 금칙어 필터 모듈 혹시 다른 데서도 쓰는
거 아냐?”
8. 테스트를 해보려면 소스코드에 변경을 가하는 등, 번거로운 선행 작업이 필요할 수 있다.
“입고 처리를 테스트하려면, 주문이 완료됐다고 테이블에 직접 업데이트를 해줘야…”
9. 그래서 소스 변경 시 해야 하는 회귀 테스트3는 곧잘 희귀 테스트(rare test)가 되기 쉽다.
“아, 그걸 언제 다 다시 테스트해? 우선 급한 불부터 끄고 보자구.
집에 안 갈거야?”
12