이 단계에서는 이전 조각들을 하나의 완성된 규칙으로 합칩니다. 정책은 일부러 작게 잡습니다. 개봉하지 않은 상품은 배송 뒤 14일까지 환불할 수 있습니다. 결정과 경계를 모두 눈에 보이게 만드는 습관을 들이세요.
코드보다 먼저 입력을 밝힙니다
프로시저는 두 입력을 받습니다.
days는 배송 뒤 지난 일수입니다.opened?는 상품을 개봉했으면#t, 아니면#f입니다.
이 수업에서는 호출자가 이미 0 이상의 올바른 일수와 불리언을 전달했다고 가정합니다. 입력 검증은 결정적으로 오류 처리하기에서 다루는 별개의 결정 경계입니다.
규칙 작성하기
(define (refund-decision days opened?)
(if (and (<= days 14) (not opened?))
'(decision allow)
'(decision deny outside-refund-window)))
(refund-decision 9 #f)결과
(decision allow)검사를 왼쪽에서 오른쪽으로 읽으세요. days가 14 이하여야 하고, opened?가
거짓이어야 합니다. 첫 조건이 실패하면 and는 즉시 멈춥니다. if는 선택된
인용 결정만 평가합니다.
거부 라벨은 일부러 보수적인 하나의 이름을 사용했습니다. 실제 정책에서는 “기간 초과”와 “개봉함”을 나누는 사유를 두고 싶을 수 있습니다. 이것은 제품 정책의 선택이지, 리스펙스의 숨겨진 동작이 아닙니다.
성공 사례만 말고 경계를 시험합니다
(list (refund-decision 14 #f)
(refund-decision 15 #f)
(refund-decision 9 #t))결과
((decision allow) (decision deny outside-refund-window) (decision deny outside-refund-window))| 사례 | 확인하는 것 | 결정 |
|---|---|---|
| 14일, 미개봉 | 포함되는 마지막 경계 | 허용 |
| 15일, 미개봉 | 기간 밖의 첫 값 | 거부 |
| 9일, 개봉 | 두 번째 조건의 독립 실패 | 거부 |
나중에 누군가 <=를 <로 바꾸면 첫 행의 결과가 달라집니다. 경계표를 두면
그러한 변화를 바로 검토할 수 있습니다.
규칙을 결정적으로 유지합니다
규칙은 인자만 읽습니다. 시계를 가져오거나 서버를 호출하거나 가변적인
애플리케이션 상태를 읽지 않습니다. 호출자가 days를 계산해 명시적으로
전달합니다. 문서화된 같은 런타임 제한 아래에서 같은 두 리스펙스 값을 주면,
평가 경로도 관측 결과도 같습니다.
이것이 환불 정책의 공정성, 법적 충분성, 실제 데이터의 정확성을 증명하는 것은 아닙니다. 리스펙스는 계산을 점검할 수 있게 해 주며, 입력 출처와 외부 행위에 대한 책임은 주변 애플리케이션에 남아 있습니다.
연습
미개봉 상품을 30일까지 허용하도록 바꾸고, 마지막 허용값과 첫 거부값을 보여 주는 경계 호출 두 개를 추가하세요.
답 하나 보기
(<= days 14)를 (<= days 30)으로 바꾸고 다음을 시험합니다.
(list (refund-decision 30 #f)
(refund-decision 31 #f))예상 결과는 ((decision allow) (decision deny outside-refund-window))입니다.
6단계로 갈 준비가 됐나요?
이제 호출을 읽고, 프로시저를 정의하고, 리스트를 데이터로 보존하고, 가지를 고르고, 경계를 시험할 수 있습니다. 다음 단계는 프로그램이 실행되는 곳입니다.
과정에서 벗어나 다른 길로 갈 수도 있습니다.
- 언어를 더 깊게 배우려면 소스 텍스트와 리더
- 실행 하나의 정확한 기록을 남기고 검사하려면 결정 기록 실행하고 검사하기
- 정확한 소스를 되돌릴 수 있는 시각 아티팩트로 만들려면 리스펙스 이미지
- 결정 기록을 나중에 인증하고, 직접 고른 소스·입력으로 다시 확인해야 할 때는 고급 리스펙스 바우치 흐름