주문 알림 기능을 만들면서 나중에 필요할 것들이 떠올랐고 지금 넣을지를 정해야 했다. 종류별 enabled 토글과 quiet_hours 설정과 여러 채널과 발송 이력과 fallback 발송 다섯이었는데 전부 넣으면 만드는 시간이 두 배가 된다.
Table of contents
Open Table of contents
판단 기준 — 나중에 넣기 어려운 것
두 가지 방법이 있었는데 다섯을 전부 넣어 한 번에 끝내는 것과 나중에 넣기 어려운지를 기준으로 갈라 일부만 넣는 것이다. 뒤쪽을 골랐다. 이유는 전부 넣으면 만드는 시간이 두 배인데 그중 실제로 쓰일지 모르는 것이 절반이라서다. 대신 안 넣은 것을 요청받았을 때 그때 다시 만드는 비용을 감수했다. 켜고 끄기와 시간대 설정은 notification_settings 컬럼 하나로 되므로 나중에 넣어도 쉽다.
여러 채널은 나중에 넣으면 send() 를 부르는 코드를 전부 고쳐야 하므로 어렵고 notification_logs 는 나중에 넣으면 그 전 기록이 아예 없다. 대체 발송은 채널이 여럿일 때만 가능하므로 그 뒤에 오는 것이다.
조치 — 구조만 잡고 하나만 만들기
채널은 NotificationChannel 인터페이스만 두고 EmailChannel 하나만 만들었다. 나중에 SmsChannel 을 넣을 때 클래스 하나만 추가하고 부르는 쪽은 안 고쳤다.
구조를 잡는 비용은 작고 나중에 구조를 바꾸는 비용은 컸으므로 그 차이만큼이 지금 넣을 이유가 됐다. notification_logs 는 조회 화면 없이 기록만 남기게 했는데 나중에 화면을 만들 때 그동안의 이력이 그대로 있었다.
검증 — 안 만든 셋의 결과
나머지 셋은 안 만들고 BACKLOG.md 에 적어 뒀다. 나중에 넣어도 어렵지 않은 것들이었다.
실제로 enabled 토글은 두 달 뒤에 요청이 와서 반나절에 만들었다. quiet_hours 와 fallback 은 일 년이 지나도 요청이 없었으므로 안 만든 것이 맞았다.
적어 둔 판단 기준
이 판단을 다른 기능에도 쓰려고 기준을 적었다. 나중에 넣으면 구조를 바꿔야 하거나 지금부터 쌓아야 나중에 쓸 수 있거나 나중에는 되돌릴 수 없는 것은 지금 넣는다.
설정 하나 추가로 되거나 화면만 만들면 되거나 실제로 필요해질지 모르는 것은 나중에 넣는다. 안 넣기로 한 것은 어떻게 넣을지까지 BACKLOG.md 에 적어 둬서 두 달 뒤에 그 메모를 보고 바로 만들 수 있었다.
주의 — 목록을 줄이는 관리
목록에 적어 두면 나중에 넣는다가 되는데 그 나중이 언제인지를 안 정하면 계속 남는다. 그래서 분기마다 목록을 봤다.
요청이 왔으면 만들고 안 왔으면 왜 안 왔는지를 봤다. 일 년이 지나도 요청이 없던 것은 검토 시점과 종료 시점을 적어 목록에서 뺐다. 목록이 길어지기만 하면 아무도 안 보게 되므로 줄어드는 것이 보여야 계속 보게 된다.
정리
- 떠오른 것을 적고 하나씩 판단한다
- 나중에 넣기 어려운 것을 지금 넣는다
- 지금부터 쌓아야 하는 것을 남긴다
notification_logs같은 이력은 나중에 되찾을 수 없다NotificationChannel인터페이스만 잡고 구현은 하나만 만든다- 나머지는
BACKLOG.md에 적고 안 만든다 - 안 넣은 것을 어떻게 넣을지까지 적는다
- 안 만들기로 종료한 것도 이유와 함께 남긴다