새 연동을 만들면서 조사와 구현을 같이 했는데 만들다가 조사하고 조사하다가 다시 고치기를 반복했다.
Table of contents
Open Table of contents
증상 — 섞어서 하고 있었다
상대가 준 규격 문서를 열어 놓고 그것을 보면서 코드를 썼다.
쓰다가 모르는 것이 나오면 문서를 다시 보고 문서에 없으면 물어봤다. 답이 올 때까지 그 자리를 TODO 로 비워 두고 다음으로 갔는데 그것이 쌓였다.
// TODO: 취소 시 부분 취소가 되는지 확인 필요
// TODO: 응답 코드 목록 받아야 함
// TODO: 시험 계정 요청함TODO 가 일곱 개가 됐고 어느 것이 답이 왔는지도 헷갈렸다.
지금 무엇이 되고 무엇이 안 되는지가 흐려져서 진행이 되고 있는지조차 판단하기 어려운 상태였다.
조치 — 나눠서 했다
코드를 멈추고 1단계 로 조사만 먼저 했다.
1단계 조사
- 규격서 전체를 읽는다
- 모르는 것을 목록으로 만든다
- 한 번에 물어본다
- 답을 받아 정리한다
2단계 구현
- 조사 결과를 보고 만든다조사에 이틀이 걸렸고 구현에 사흘이 걸렸다.
섞어서 하던 때는 8일째에도 어느 쪽도 안 끝나고 있었다. 모르는 것을 모아 한 번에 물으니 나올 때마다 하나씩 묻던 것보다 답도 빨리 왔다.
결과 — 조사 결과 문서
받은 답을 한자리에 모아 이런 형식으로 정리했다.
[연동 규격 정리]
요청
POST /api/v2/order
필수: orderId, amount, items[]
선택: memo (200자 이내)
응답 코드
0000 성공
1001 중복 주문 (재시도 불필요)
1002 잔액 부족 (재시도 불필요)
9001 일시 오류 (재시도 가능)
9999 알 수 없음 (문의)
확인한 것
부분 취소 지원함. cancelAmount 를 보낸다
같은 orderId 로 두 번 보내면 1001 이 온다 (안전하다)
확인 못 한 것
하루 호출 한도 (문의 중)확인한 것 과 확인 못 한 것 을 갈라 적었다.
만들기 전에 이 연동 규격 정리 가 있으니 구현이 빨랐다. 코드를 쓰면서 그 문서를 들여다볼 뿐 그 자리에서 새로 조사할 것이 없었다.
주의 — 확인 못 한 것
확인 못 한 것 을 전부 채우고 시작할 수는 없었다.
// 호출 한도가 확인되지 않았다. 보수적으로 초당 5회로 둔다.
// 확인되면 config 의 rate_limit 을 조정한다. (2019-04-23)
private const RATE_LIMIT = 5;RATE_LIMIT 에 가정을 세우고 어디를 고치면 되는지 함께 적었다.
답이 오면 그 한 줄만 고치면 되고 적어 두지 않으면 답이 와도 어디를 손대야 하는지부터 다시 찾게 된다.
교훈 — 설계를 바꾼 조사
규격서를 다 읽고 나니 처음 생각과 다른 것이 있었다.
처음 생각 요청을 보내고 응답으로 결과를 받는다
실제 요청을 보내면 접수만 되고 결과는 콜백으로 온다동기 호출로 생각하고 만들고 있었는데 실제로는 콜백 방식이었다.
1단계 를 먼저 밟았으면 처음부터 다르게 만들었을 것이다. 이미 만들어 둔 것을 절반쯤 버렸고 그것이 조사를 나중에 한 값이었다.
몇 달 뒤 다른 사람이 같은 연동을 손댈 일이 있었는데 연동 규격 정리 를 보고 바로 시작했다. 조사는 한 번 하고 문서로 남기면 다음 사람이 다시 하지 않는다.
제약 — 조사 기한
마음만 먹으면 1단계 를 끝없이 늘릴 수도 있었다.
조사 2일. 그 안에 답이 안 온 것은 가정을 세우고 넘어간다.기한이 없으면 답을 기다리며 아무것도 안 하게 된다.
조사 2일 기한 안에 답이 돌아온 것이 다섯 중 넷이었다. 하나는 가정을 세우고 갔는데 나중에 답이 왔을 때 그 가정이 맞았다.
정리
- 조사하면서 만들면 둘 다 어중간해진다
- 비워 둔 것이 쌓이면 진행 상태도 흐려진다
- 멈추고 조사만 먼저 한다
- 모르는 것을 목록으로 만들어 한 번에 묻는다
- 조사 결과를 문서로 만들고 만들 때는 그 문서만 본다
- 확인 못 한 것은 가정과 고칠 자리를 함께 적는다
- 조사가 설계를 바꿀 수 있다
- 뒤로 미루면 만든 것을 버리게 된다
- 문서로 남기면 다음 사람이 다시 조사하지 않는다
- 조사에 기한을 두지 않으면 답을 기다리며 멈춘다