소프트웨어 장인 정신 이야기

 

p.3-4

2차 세계 대전 동안 미국은 비행기를 6만 5000대 잃었다. 이 중 전투에서 상실한 것은 2만 3000대밖에 되지 않았다. 전투를 벌이다 비행 도중 전사하는 조종사도 있었지만, 아무도 총을 쏘지 않는 환경에서 비행하다 사망한 조종사가 더 많았다. 인류는 나는 방법을 여전히 몰랐던 것이다.

 

p.5

시인 바이런의 딸인 에이다 러브레이스 백작 부인은 배비지의 강연 기록을 번역하면서, 그 시기 누구도 인식하지 못했던 듯한 사실을 깨달았다. 컴퓨터의 숫자가 꼭 숫자만 표현해야 하는 것은 아니고 실제 세상의 무언가를 표현할 수 있다는 것이다. 이 통찰 덕분에 에이다는 세계 최초의 진정한 프로그래머로 여겨진다.

 

p.18

테스트 주도 개발만큼 리팩터링을 잘 뒷받침하는 다른 규율이 있을 수도 있다. 켄트 벡의 test && commit || revert도 그 후보다. 하지만 이 글을 쓰는 시점에는 아직 널리 쓰이지 않고 있고 학문적 호기심의 수준에 머물러 있다.

(옮긴이) test && commit || revert는 코드를 변경한 후 테스트를 통과하면 커밋하고, 실패하면 무조건 마지막 커밋 상태로 되돌려서 코드를 다시 작성하는 개발 방법이다.

 

p.21

인수테스트는 소프트웨어 개발 팀과 사업을 묶어 주는 규율이다. 시스템이 동작해야 하는 방식을 사업 목표로 명시한다. 이런 동작 방식은 테스트로 코딩하여 표현한다. 테스트가 통과하면 시스템이 명시한 대로 동작하는 것이다.

 

인수 테스트는 사업 부서를 대표하는 사람이 읽고 쓸 수 있어야 한다. 사업 부서는 인수 테스트를 쓰고 읽고 통과하는 것을 확인함으로써 소프트웨어가 무엇을 하는지 그리고 사업 부서에 필요한 일을 하는지 알 수 있다.

 

p.32

디버거에 능숙한가? 손가락이 알아서 디버거를 다루는가? 모든 단축키를 숙지하고 자유자재로 사용하는가? 효율적으로 중단점(breakpoint)과 워치포인트(watchpoint)를 걸고, 험난한 디버깅 작업 속으로 앞뒤 보지 않고 뛰어드는 것이 제2의 천성인가?

 

디버깅은 선망할 만한 기술이 아니다!

 

디버거에 능숙해지려 하지 말라. 디버거에 능숙해지는 방법은 디버깅을 하며 많은 시간을 보내는 것밖에는 없다. 그리고 나는 디버깅에 많은 시간을 쓰고 싶지 않고, 여러분도 마찬가지여야 한다. 나는 여러분이 작동하는 코드를 작성하면서 최대한 많은 시간을 보내기를, 작동하지 않는 코드를 고치는 일에는 최소한의 시간을 쓰기를 바란다.

 

나는 여러분이 디버거를 너무 뜸하게 쓰게 된 나머지 단축키도 다 잊고, 여러분의 손가락도 디버깅 감각을 잃어버리기를 바란다. 늘 헷갈리는 한 단계씩 코드 실행 아이콘과 한 줄씩 실행 아이콘 사이에서 헤매기를 바란다. 디버거가 익숙하지 않아서 어색함과 답답함을 느끼길 바란다. 여러분도 이런 바람을 가져야 한다. 디버거가 편안하게 느껴질수록 무언가 잘못하고 있다는 뜻이다.

 

하지만 테스트 주도 개발의 세 가지 법칙을 지키면 디버거가 아예 필요 없어진다고 약속할 수는 없다. 디버깅이 필요한 순간도 있을 것이다. 어쨌든 우리가 만드는 것은 소프트웨어이고, 소프트웨어는 여전히 어렵다. 하지만 디버깅의 빈도와 소요 시간은 급격하게 줄어들 것이다. 작동하는 코드를 쓰는 데는 훨씬 더 많은 시간을, 작동하지 않는 코드를 고치는 일에는 훨씬 더 적은 시간을 쓰게 될 것이다.