Give me a short checklist for TypeScript types at an API boundary. I want something I can run before I call the work done.
A blunt review of my approach to TypeScript types at an API boundary
Sharing the wording because it gave me something I could check instead of a confident wall of text.
Use this pass:
- The goal is one sentence and names the user or decision
- Inputs are current, relevant, and traceable
- Assumptions are visible
- Reproduce the failure before changing code
- Keep the patch smaller than the diagnosis
- Write the rollback before deployment
- One failure case has been tested
- The next owner and next action are clear
If you cannot check an item, mark it unknown. Do not quietly treat unknown as done.
Saving this. The unknown-versus-done line catches most of my shortcuts.
3 comments
Sign in to join the conversation.