스크립트 하나, 모드 둘
강제 기계 전부가 플래그 달린 스크립트 하나야. 배달 모드에선 매니페스트를 걸으면서 키트 원본을 소비자마다 선언된 대상 경로에 써. 검사 모드에선 같은 매니페스트를 걸으면서 쓰는 대신 비교해. 본문이 원본이랑 다른 대상 전부, 그리고 있어야 하는데 없는 대상 전부를 보고하고.
둘에 프로그램 하나를 쓰는 건 아끼려는 게 아냐. 정확성 논증이야. 배달이랑 검사가 따로 구현이면 "기대되는 내용"이 뭔지에 대해 서로 안 맞을 수 있고, 그러면 검사는 배달이 절대 안 만드는 뭔가를 검증하게 돼. 코드 경로를 같이 쓴다는 건 검사가 배달이 답하는 바로 그 질문을 묻는다는 뜻이야.
실패 종류 둘, 따로 보고
검사 모드는 어긋남이랑 없음을 구분해. 갈라둘 값이 있어. 원인도 처방도 다르거든. 어긋남은 파일이 있는데 본문이 안 맞는 거야. 누가 복사본을 고쳤거나, 키트 변경 뒤에 배달을 안 돌렸거나. 없음은 매니페스트가 이 소비자한테 이 파일이 있어야 한다는데 없는 거야. 보통 배달을 돌리기 전에 새 소비자를 대상 목록에 넣은 경우고.
둘 다 실패지만 메시지가 다르고, 검사의 값 대부분은 메시지에 살아. "키트 원본이랑 다름"은 diff 를 보라는 말이야. "키트는 이게 복사본으로 있을 걸 기대함"은 배달을 돌리라는 말이고. 둘을 뭉뚱그린 실패로 만들면 모든 사건이 같은 조사로 시작해.
리뷰할 때 사주는 것
남의 변경을 읽을 때 나타나는 조용한 이득이 하나 있어. 소비자 저장소에서 복사본 파일을 건드리는 diff 는 즉시 수상해. 머리말이 여기서 고치지 말라고 하고, 어긋남 테스트가 잡았어야 하니까. 그래서 리뷰어는 어느 파일이 공용인지 알 필요가 없어. 머리말이 알려주고, 테스트가 강제하니까.
그게 관례랑 기계의 차이야. 관례는 리뷰어마다 어느 파일이 금지인지 기억할 것을 요구해. 기계는 리뷰어가 변경의 재밌는 부분을 보면서, 지루한 불변량은 이미 지켜지고 있다고 믿어도 되게 해줘.