jiantw83andClaude Opus 5
549bd29313
四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問 使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把 它變成一句能收斂的提問，那才是實際卡住的地方。 四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經 做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡）， 時程問未知數最大的一項（它決定整體估算的可信度）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
20 lines
1.2 KiB
Markdown
20 lines
1.2 KiB
Markdown
# 資料可行性檢查
|
|
|
|
問的是「資料層面會不會出事，以及出事有多難救」。
|
|
|
|
## 檢查項
|
|
|
|
1. **schema 變更** — 要不要動資料表？新增欄位、改型別、改索引，各自影響哪些既有查詢？
|
|
2. **遷移** — 既有資料怎麼辦？需不需要回填？回填期間新舊邏輯會不會同時在跑？
|
|
3. **可逆性** — 遷移能不能退回？若不能，上線前要準備什麼（備份、灰度、開關）？
|
|
4. **交易邊界** — 一次操作要寫幾個地方？其中一個失敗會不會留下不一致的狀態？
|
|
哪些必須在同一個交易內？
|
|
5. **資料量與成長** — 現在的量級是多少、一年後呢？查詢會不會隨資料成長而變慢？
|
|
6. **敏感資料** — 會不會經手個資或憑證？誰能讀到？日誌裡會不會留下不該留的東西？
|
|
7. **資料來源** — 資料從哪裡來、由誰維護？來源不可用時這個功能該怎麼表現？
|
|
|
|
## 問題怎麼問
|
|
|
|
schema 與遷移的答案通常不在需求議題裡，而在資料負責人腦子裡——這一組問題幾乎一定要問。
|
|
把「不動 schema」也當成一個明確的答案記下來，不要當成沒問。
|