103 일이 굴러가는 방식 — 어휘와 절차

103.1 이름이 없으면 같은 것을 다르게 부른다#

먼저 이 장에서 쓸 낱말을 한자리에 모은다. 뒤에서 하나씩 실물과 함께 볼 것이므로, 지금은 훑고 지나가도 된다.

★ 이 낱말들은 어느 도구의 이름이 아니다. 도구는 프로젝트마다 다르지만 부르는 자리는 같다. 그래서 낱말만 익혀 두면 처음 보는 저장소에서도 무슨 일이 벌어지는지 읽힌다.

103.2 픽스처 — 시험이 딛고 서는 판#

시험 하나를 돌리려면 준비물이 있어야 한다. 읽을 입력, 견줄 정답, 미리 만들어 둔 임시 폴더, 정해진 값이 들어 있는 자료. 그 준비물 묶음을 「픽스처(fixture)」라 부른다.

102장의 골든 시연에 이미 실물이 있었다. 이름만 안 붙였을 뿐이다.

★ 픽스처의 조건은 하나다 — 매번 같아야 한다. 어제와 오늘이 다르면, 시험이 실패했을 때 「코드가 틀렸나, 준비물이 달라졌나」를 가릴 수 없다. 그 순간 그 시험은 답을 주는 물건이 아니라 물음을 하나 더 만드는 물건이 된다.

그래서 픽스처로 쓰면 안 되는 것들이 있다.

말의 뿌리도 그 성질에 있다. 건물에 붙박이로 달린 조명이나 배관을 영어로 fixture 라 부르는데, 옮겨 다니지 않고 늘 그 자리에 있다는 뜻이 시험 쪽으로 건너온 것이다.

103.3 증인 — 검사는 결함의 묘비다#

버그를 하나 고쳤다고 하자. 그 자리에 무엇을 남길 것인가. 아무것도 남기지 않으면 그 버그는 다시 돌아온다. 사람이 바뀌고, 코드가 고쳐지고, 아무도 그 사연을 모르기 때문이다. 되돌아온 결함을 회귀라 부른다(102장에서 이름만 스쳤다).

막는 방법은 하나다. 고친 자리마다 「이 결함이 돌아오면 우는 검사」를 하나 세워 둔다. 그것이 「증인(witness)」이다.

★ 그리고 순서가 중요하다 — 고치기 전에 세운다. 고친 뒤에 세우면 그 검사가 정말 무는지 알 수 없다. 처음부터 초록인 검사와, 결함을 잡아 빨강이었다가 고쳐서 초록이 된 검사는 겉보기에 같지만 값어치가 전혀 다르다.

#!/bin/sh
# 증인을 *고치기 전에* 세운다.
#
#   ① 결함이 있는 판에 대고 돌린다 --- 증인이 울어야 한다(빨강).
#      울지 않으면 그 증인은 아무것도 지키지 않는 것이다.
#   ② 고친 판에 대고 돌린다 --- 조용해야 한다(초록).
#
# 이 순서가 요점이다. 초록만 본 검사는 *무는지 모르는* 검사다.
set -eu
cd "$(dirname "$0")"
CC=${CC:-cc}
CFLAGS="-std=c23 -Wall -Wextra"

printf '== (1) the version with the defect (a witness must cry)\n'
$CC $CFLAGS -o witness-buggy find-buggy.c witness.c
if ./witness-buggy; then
    printf '   * no witness cried --- this witness is useless\n'
    rc=1
else
    printf '   -> it cried, as intended\n'
    rc=0
fi

printf '\n== (2) the fixed version (all must be quiet)\n'
$CC $CFLAGS -o witness-fixed find.c witness.c
./witness-fixed || rc=1

rm -f witness-buggy witness-fixed
exit $rc

== (1) the version with the defect (a witness must cry)
  ok   finds a value in the middle
  ok   finds the first
  FAIL * finds the last - one cell of edge  (got -1, wanted 4)
  ok   an absent value gives -1
  ok   an empty array gives -1 too
a witness cried
   -> it cried, as intended

== (2) the fixed version (all must be quiet)
  ok   finds a value in the middle
  ok   finds the first
  ok   * finds the last - one cell of edge
  ok   an absent value gives -1
  ok   an empty array gives -1 too
all five witnesses are quiet

시연이 그 순서를 그대로 보인다. 이진 탐색에서 lo <= hi 를 lo < hi 로 적는 흔한 실수를 두고, 증인 다섯을 먼저 세웠다.

1. 결함이 있는 판에 대고 돌리면 「맨 뒤를 찾는다」 하나만 운다. 나머지 넷은 조용하다 — 증인이 어디가 잘못됐는지까지 짚어 준다는 뜻이다.
2. 고친 판에서는 다섯이 다 조용하다.

그리고 증인 하나하나에 왜 중요한가가 문장으로 붙어 있다.

check("★ 맨 뒤를 찾는다 — 경계 한 칸", find(sorted, n, 50),  4);

수가 아니라 이 문장이 자산이다. 몇 달 뒤 이 검사가 울었을 때, 사람이 읽는 것은 「검사 3번 실패」가 아니라 「경계 한 칸을 못 본다」이기 때문이다.

103.4 음성 검사 — 그 검사가 정말 무는가#

증인의 순서에서 배운 것을 규칙으로 세우면 이렇게 된다. 새 검사를 지으면 반드시 한 번 고장 내 본다. 이것을 「음성 검사(negative test)」라 부른다 — 「없는 것을 없다고 하는가」가 아니라 「있는 것을 있다고 하는가」를 확인하는 일이다.

방법은 간단하다. 검사가 잡아야 할 결함을 일부러 넣고, 검사가 우는지 보고, 되돌린다.

103.5 래칫 — 늘면 안 되는 수#

프로젝트에는 「0 이면 좋지만 당장 0 으로 못 만드는」 수들이 있다. 경고의 수, 아직 못 고친 결함의 수, 시험이 안 도는 자리의 수 같은 것들이다. 이런 수를 다루는 방법은 둘 가운데 하나다 — 못 본 척하거나, 늘지 못하게 막거나.

뒤쪽이 「래칫(ratchet)」이다. 지금의 수를 파일에 적어 두고, 그보다 늘면 게이트가 운다. 톱니바퀴가 한 방향으로만 도는 것과 같아서 붙은 이름이다.

★ 마지막 줄이 래칫의 진짜 값어치다. 늘리는 것을 금지하는 것이 아니라 눈에 보이게 만드는 것이다. 정말 필요하면 기준선을 올리면 된다. 다만 그 순간 그 변경이 커밋에 남고, 리뷰에서 「이건 왜 늘었나」를 묻게 된다.

그리고 조이는 쪽은 사람이 한다. 수가 줄었다고 기계가 자동으로 기준선을 낮추면, 어느 날 우연히 줄었다가 다시 늘 때 막지 못한다 — 래칫이 사라지는 것이다.

103.6 티어 — 늘 전부 돌릴 수는 없다#

검사를 많이 세울수록 전부 돌리는 데 오래 걸린다. 그러면 사람은 안 돌리기 시작한다 (102장의 make clean 과 같은 이야기다). 그래서 검사에도 깊이를 둔다. 바뀐 것에 따라 어디까지 돌릴지 정하는 것이 「티어(tier)」다.

두 가지 규율이 붙는다.

1. 깊이는 바뀐 것이 정한다. 문서만 고쳤다면 깊게 돌릴 까닭이 없고, 핵심 자료구조를 건드렸다면 얕게 넘어가면 안 된다.
2. ★ 올릴 수만 있다. 「급하니 이번엔 얕게」는 규율을 무너뜨리는 첫걸음이다. 깊이를 내려서 통과시키는 물건이 아니다.

103.7 한 건의 일 — 결정과 실행을 가른다#

이제 절차다. 요청 하나가 들어와서 커밋으로 끝나기까지, 큰 프로젝트가 실제로 밟는 걸음은 대체로 이렇다.

★ 첫 걸음이 가장 자주 빠지고 가장 비싸다. 결정과 실행은 다른 종류의 일이다.

• 결정 — 어느 길로 갈지, 공개 약속이 바뀌는지, 남이 쓰던 것이 깨지는지. → 혼자 정하지 않는다. 물어본다.
• 실행 — 그 결정을 어떻게 옮길지. → 묻지 않고 한다.

이 둘을 섞으면 양쪽이 다 나빠진다. 실행까지 물으면 일이 안 굴러가고, 결정까지 혼자 하면 나중에 통째로 되돌리게 된다.

두 번째 걸음도 그만큼 값한다. 「느린 것 같다」·「아마 여기가 문제일 것이다」로 시작한 작업은 자주 헛다리를 짚는다. 재고 나서 계획이 뒤집히는 일이 흔하고, 그것이 정상이다. 뒤집혔다면 그 사실을 기록에 남긴다 — 다음 사람이 같은 자리를 다시 짚지 않도록.

103.8 조용한 실패 금지 — 그리고 커밋은 결정의 기록이다#

마지막으로 이 장 전체를 관통하는 규율 하나가 있다. 조용히 실패하지 않는다.

잘랐으면 잘랐다고 말한다. 못 쟀으면 못 쟀다고 말한다. 검사를 건너뛰었으면 건너뛰었다고 말한다. 침묵은 언제나 「검사했고 괜찮다」 로 읽히기 때문이다.

★ 마지막 줄이 특히 위험하다. 「0 이다」와 「검사가 0 이라고 답했다」는 다른 문장이다. 검사의 범위가 곧 그 검사의 약속이므로, 무엇을 안 보는지도 함께 적어야 한다.

그리고 커밋 메시지다. 코드는 무엇을 했는지 말하지만 왜 는 말하지 못한다 (102장의 설계 기록과 같은 이야기다). 그래서 커밋에는 이것들을 적는다.

1. 무엇을 왜 고쳤는가 — 특히 되돌린 것이 있으면 그것도
2. 어떤 수가 어떻게 움직였는가(래칫이 있다면)
3. 배운 것 한 줄 — 다음 사람이 같은 자리를 다시 짚지 않도록

여기까지가 여럿이 오래 짓는 일의 뼈대다. 다음 장은 이 모든 것을 한 영역에 대고 본다 — C 가 가장 깊이 뿌리내린 자리인 임베디드에서, 어떤 컴파일러와 어떤 연장을 들고 일하는지다.