문단 넷 대신 칸 넷
절차의 한 단계에 대해 평소 쓰던 산문을 꺼내봐. 뭘 위한 건지, 뭘 조심해야 하는지, 잘된 게 어떤 모양인지. 그걸 칸 넷에 밀어넣어. 단계 이름, 허용 입력, 금지 입력, 그리고 뭘로 닫히는지. 산문 대부분은 안 들어가고, 안 들어간 건 들여다볼 값어치가 있어. 템플릿에 들어가야 할 장인 지식이거나, 애초에 강제 불가능했던 소망이거든.
칸은 하네스가 붙잡을 수 있게 골랐어. 허용/금지 입력은 집합 소속 질문이야. "뭘로 닫히는지"는 사후 조건이고. 존재해야 하는 파일, 쓰였어야 하는 기록, 바뀌었어야 하는 상태. 넷 중 어느 것도 누구한테 조심하라고 안 해.
흥미로운 건 세 번째 칸이야
절차 문서 대부분은 허용 칸이 암묵적으로 있고 금지 칸은 아예 없어. 실패가 사는 자리가 그 누락이고. 이 단계가 설계 브리프랑 대상의 현재 상태를 볼 수 있다고 적는 건 쓸모 있어. 원어 짝은 볼 수 없다고 적는 문장이 그 단계를 원래와는 다른 단계로 만드는 문장이야.
금지 칸을 쓰면 정직한 점검도 강제돼. 금지 항목이 진짜로 필요한 단계가 나올 거야. 파일을 쓰는 단계엔 경로가 있어야 하니까. 그건 이 연습의 실패가 아니라 연습이 작동한 거야. 그런 단계는 다른 방법으로 지켜야 하고, 어떤 게 그런지 아는 것이 이 트랙 나머지의 입력 전부야.
계약은 파이프라인으로 합성되고, 파이프라인은 데이터야
단계마다 칸이 넷이면 파이프라인은 단계의 순서 목록 더하기 깃발 몇 개야. 어떤 단계가 어떤 입력을 제한하는지, 이 파이프라인이 착지시킬 수 있는 경로가 뭔지, 어떤 종류의 기록을 찍는지, 게이트가 뭔지. 그게 레지스트리 항목이지. 아홉 번째 파이프라인을 더하는 게 새 하위 클래스가 아니라 데이터 변경이 되고, 더 중요하게는 하네스가 이미 적용할 줄 아는 가드 전부를 새 파이프라인이 공짜로 쓰게 돼.
차이가 언제 드러나냐면 아홉 번째를 더할 때가 아니라 여덟 개 전부에 걸린 규칙 하나를 고칠 때야. 계약이 코드에 흩어져 있으면 그건 여덟 군데 수정이고, 그중 하나를 빼먹었는지는 아무도 몰라. 데이터면 한 군데 수정이고 나머지는 읽는 쪽이 알아서 따라와. 파이프라인을 데이터로 두는 값어치는 추가가 싸다는 게 아니라 일관성이 기본값이라는 데 있어.