버그를 없애기 위해서가 아니라....

버그가 발생한 지점과 원인을 재빨리 찾기 위해서다.

이상하게 돌아가는 애플리케이션을 눈앞에 두고 버그를 재현하지 못해서 고생을 하고...

고생끝에  버그의 원인을 찾고보니 근본적인 설계 결함이라 건드렸다가는 다 뒤집어까는 뭣같은 상황을 애초에 막는 것... 코드를 뒤집어 놓고나서 설계 구조가 엉망이 되는 더 뭣같은 상황을 막고... 뭣같은 코드때문에 기능 추가를 못하는 진짜 뭣같은 미래를 방지하는 것...

이게 tdd처럼 테스트 코드를 을 제품과 같이 끌고 가는 이유임.

프로그래밍은 경험주의의 산물이고... 따라서 버그를 없애겠다, 방지하겠다가 아니라

\"버그가 나오면 바로, 즉시, 쉽게 고친다\"

가 경험주의적 개발 철학임.

학계에서는 함수형 스타일로 프로그래밍을 하면 side-effect가 발생하지 않아서 bug-free한 이상적인 애플리케이션 개발 환경을 주장하는데 그런 조까는 소리는 연구실에서 논문 쓸때나 하시고 현실은 안변하는게 없다. 자고 일어나면 상황이 바뀌어있고 밥 먹고 오면 말이 달라져있고....

따라서 상황이 변하고 기능이 빠지고 새로 들어와도 설계를 계속해서 바꾸고 그때마다 버그를 빨리 고치고 나아가려면 테스트 코드가 첨병 역할을 해야 하는 것. 설계 변경이 어디까지 영향을 미치는지 파악을 해야 일정 산출이 되고 윗대가리들한테 정확한 기간을 말해줄 수 있음.

사소한 버그는 아무리 많이 발생해도 문제되지 않는다. 그런데 꼭 보면 악성버그를 만드는 새끼들이 있다. 요구사항만 딱! 맞춰서 커밋하고 나중에 엿은 다같이 먹고...

학식충들은 지금 하드에 있는 보잘것없는 애플리케이션을 꺼내서 새로운 기능을 추가해봐라.

아마 구현이 부드럽게 안될거고 기능 하나 하나 넣을때마다 걸레처럼 변해가는 자신의 코드를 보게될거임.

그리고 거기서부터 진짜 실력이 늘기시작하지.