여러 항목을 순서대로 실행하다 마지막 자료가 빠졌다는 사실을 알게 되면 이미 처리한 항목과 남은 항목이 섞인다. 나는 항목을 하나씩 확인하고 곧바로 실행하는 대신 전체 준비 확인을 먼저 통과하게 했다. 이 준비가 실제 처리 성공은 아니지만 시작 전에 찾을 수 있는 문제를 앞에서 발견하는 데 의미가 있었다.
전체 목록을 받는 준비 단계를 둔다
Workflow.prepare는 항목 목록의 형식과 개수, 서로 다른 ID를 확인한다. 프로젝트 안의 업무 노트북은 program.prepare로 전체 목록을 호스트에 보낸다. 호스트도 중복 ID를 검사하고 모든 항목에 prepareNotebookItem을 적용한다. 첫 항목이 맞다는 사실을 나머지의 준비 완료로 바꾸지 않는다.
Workflow.run은 실행 루프에 들어가기 전에 prepare를 다시 호출한다. 사용자가 준비 셀을 봤다는 기억에만 의존하지 않으려는 순서다. 보관함에서 시작한 단일 항목 경로는 다른 어댑터를 사용하므로 프로젝트 노트북의 전체 목록 검사를 모든 실행 형식에 그대로 적용했다고 쓰지 않는다.
키 형식과 이번 입력 요구를 구분한다
prepareNotebookItem은 알 수 없는 매개변수를 거절하고 정의 기본값과 이번 값을 합친 뒤 템플릿을 해석한다. 낮은 함수에는 기본값 사용이 남아 있다. 그래서 모든 누락 입력을 이 함수가 거절한다고 설명하지 않는다. 현재 입력 전체를 요구하는 다른 실행 입구의 검사는 별도 계약이다.
이 구분은 실제 오류를 진단할 때 중요하다. 이름을 잘못 쓴 키인지, 의도적으로 빈 문자열을 넣은 것인지, 기본값으로 채워진 것인지가 다르다. 나는 준비 화면에 정상 표시가 떴다는 이유로 모든 값이 이번 사람의 요청에서 왔다고 추정하지 않는다. 입력의 형식과 입력의 출처를 함께 봐야 했다.
파일 이름보다 이번에 선택된 핸들을 확인한다
준비는 치환된 단계에서 첨부 핸들을 모으고 현재 context의 선택 파일에 모두 있는지 확인한다. 없다면 NOTEBOOK_FILE_NOT_SELECTED다. 과거 실행의 파일 이름이 같거나 경로가 남아 있다는 이유로 새 업로드 자료로 인정하지 않는다. 매체별 옵션 안의 업로드 항목도 해당 검사에서 확인한다.
이 단계가 서버에 파일이 올라갔다는 뜻은 아니다. 준비 후 파일이 바뀔 수도 있고 실제 선택과 전송에서 다른 오류가 날 수 있다. 이후 실행 경계의 파일 검증과 서버 결과 확인은 계속 필요하다. 나는 선택 자료의 적합성과 전송 완료를 다른 상태로 보여 주는 편이 사용자가 이해하기 쉽다고 봤다.
시작 위치와 매체 규칙도 먼저 해석한다
준비 함수는 시작 주소와 탭의 시작 위치, navigate 단계의 주소를 범위 검사로 넘긴다. 매체별 제목과 시각, 구성 자료도 전용 입력 검사에 보낸다. 뒤에서 사용할 값을 미리 치환해야 잘못된 설정이 실제 행동 전에 드러날 수 있다.
그러나 주소 형식과 입력 규칙이 맞아도 그때의 로그인과 실제 편집기 상태까지 확인한 것은 아니다. 사이트 화면은 바뀔 수 있다. 준비 결과는 현재 프로젝트와 프로필, 기준 탭과 단계 설명을 보여 주는 검토 자료다. 실제 버튼을 누를 때는 새 관찰과 실행 조건을 다시 확인해야 한다.
시험은 두 번째 항목의 오류에도 실행0회를 요구한다
기존 단위 시험은 첫 항목 뒤에 미지 키가 있는 항목을 놓고 준비를 요청한다. 오류가 나면 execute 호출이0회여야 한다. 중복 ID와 선택하지 않은 첨부도 같은 방식으로 실행 전에 거절되는지 본다. 마지막 항목까지 검사를 미룬 뒤 앞선 동작을 했다는 시험이 아니다.
이 근거는 기존 execute 대역과 임시 폴더를 사용하는 시험 코드다. 이번 집필에서 실제 업체 자료를 새로 전송하지 않았다. 아래 파일 원장 모듈도 실행을 대신하지 않는 독립 예제다. 준비 검사와 원장 저장, 실제 외부 처리의 증거를 나눠 남겨야 어떤 문제를 앞에서 잡았는지 정확히 설명할 수 있다.
준비 완료가 처리 완료처럼 보이지 않게 한다
준비 화면이 있어도 사용자는 다음 버튼을 누르면 무조건 끝날 것이라 기대할 수 있다. 나는 준비한 항목과 아직 실행하지 않은 상태를 함께 보여 주는 것이 중요하다고 본다. 사전에 막을 수 있는 오류를 줄이는 일과 실행 후 확인할 일을 없애는 것은 다르다.
견적을 일괄 만들거나 여러 자료를 발송하는 회사 프로그램도 비슷하다. 전체 자료를 먼저 확인하면 중간까지 처리된 상태를 줄일 수 있다. 그래도 실제 저장과 전달 결과는 항목별로 남겨야 한다. 준비를 별도 단계로 둔 이유는 성공을 미리 선언하기보다 시작할 조건을 분명히 설명하기 위해서였다.