어떻게 어긋남을 찾아 고치기, 디버깅
상속까지 와서 꽤 큰 프로그램을 만들었다(13강). 그런데 만든 프로그램은 어딘가 꼭 어긋난다. 오타 하나, 빗나간 가정 하나면 충분하다. 어긋남은 실패가 아니라 늘 있는 일이고, 그것을 차분히 찾아 고치는 일이 디버깅이에요.
멈춘 자리가 첫 단서
프로그램이 어긋나면 조용히 죽는 것이 아니라 한 자리에서 멈춘다.
그리고 '여기, 이 줄'이라고 그 자리를 가리킨다.
그 가리킴이 가장 값진 첫 단서다. 에러는 먼저 어디서 멈췄는지를 보여 줘요.
실행을 누르면 단계가 차례로 켜지다가 어긋난 자리에서 딱 멈춘다.
어디서 멈췄는지 한눈에 보인다.
이제 그 자리에 빨간 글씨가 뜬다.
많은 사람이 그 글씨를 보면 덜컥 겁부터 먹지만, 사실 그것은 우리 편이에요.
빨간 글씨는 꾸중이 아니라 힌트
빨간 글씨는 우리를 혼내는 것이 아니다.
컴퓨터가 무엇을 이해하지 못했는지 적어 둔 쪽지다.
보통 두 가지가 들어 있다. 자리(어디)와 종류(무엇)다. '이것은 숫자가 아니다', '그런 이름은 없다' 같은 식이다.
차분히 읽는 법만 익혀도 절반은 푼 셈이에요.
메시지 조각을 누르면 '어디'와 '무엇'이 따로 빛나며 갈라진다.
메시지를 '어디'와 '무엇'으로 갈라 읽으니 무섭던 글씨가 갑자기 친절해 보인다.
하지만 메시지가 가리키는 자리가 늘 진짜 원인인 것은 아니다.
긴 프로그램이라면 원인을 어떻게 빨리 좁힐까요?
범위를 반씩 좁힌다
버그가 어디 있는지 모를 때는 처음부터 다 읽지 말고 가운데를 본다.
여기까지는 멀쩡한가? 그렇다면 버그는 뒤쪽 절반에 있고, 아니라면 앞쪽 절반에 있다. 그리고 다시 반으로 나눈다.
이렇게 반씩 좁히면 긴 줄에서도 금세 범인을 찾아요.
가운데 확인을 누를 때마다 멀쩡한지 문제인지에 따라 범위가 반으로 준다.
몇 번 누르니 범위가 한 자리로 좁혀졌다.
전체를 다 보지 않고도 범인을 콕 집은 것이다.
이제 원인을 찾았으니 고칠 차례인데, 고칠 때 빠지기 쉬운 함정이 하나 있어요.
한 번에 하나만 바꿔서 확인하기
원인 같은 것이 보인다고 한꺼번에 다 손대면 안 된다.
다섯 군데를 동시에 바꾸면, 고쳐져도 어느 것이 고친 것인지 알 수 없다.
새 문제가 생겨도 무엇 때문인지 모른다.
그래서 하나만 바꾸고, 실행해 보고, 살펴봐요.
후보를 하나만 바꾸고 확인을 누르면 원인이 또렷해진다. 여럿을 바꾸면 무엇이 고쳤는지 흐려진다.
하나씩 바꾸니 무엇이 진짜 원인이었는지 또렷해졌다.
범인을 정확히 알고 고쳤다.
그러면 이제 끝일까? 아직 한 걸음이 남았다. '고친 것 같다'와 '고쳤다'는 다르기 때문이에요.
고친 뒤에는 꼭 다시 돌려 확인한다
고쳤다는 생각만으로는 끝나지 않는다.
다시 실행해서 끝까지 통과하는 것을 두 눈으로 봐야 끝이다.
덤으로, 멀쩡하던 다른 곳이 망가지지 않았는지도 살핀다.
이 '고치고 다시 확인'하는 한 바퀴가 어림짐작과 진짜 고치기를 가르는 선이에요.
다시 실행을 누르면 고친 프로그램이 끝까지 초록으로 통과한다.
이제 우리는 만들 줄도 알고(1~13강), 어긋났을 때 찾아 고칠 줄도 안다(14강).
그런데 우리가 쓴 이 글자들은 어떻게 기계가 실제로 돌리는 것이 될까?
다음 레슨에서는 그 글이 기계의 일이 되는 길을 따라가 봐요.