Files
tea-sdlc/references/feasibility-architecture.md
T
jiantw83andClaude Opus 5 d329039458 fix(可行性檢查): 補上時程估算的前提,並讓四份清單結構一致
時程清單的「相依鏈最長路徑」預設了一份工作拆法,但分析階段還沒有工作包可依,
照著問會問不出東西。補上說明:這個階段要先拉一份暫定拆法,它同時是下一段開
工作包的草稿;拆不出來本身就是一個要問使用者的問題。

架構清單原本在開頭多了一段中間文字,內容與自己的「問題怎麼問」重複,也讓它
成為四份裡唯一結構不同的一份,移除。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 13:11:05 +08:00

1.2 KiB

架構可行性檢查

問的是「這件事該不該在這裡做、做了會不會把結構弄壞」。

檢查項

  1. 落點 — 這個需求該由哪一個 repo 承接?若需求議題的「影響範圍」列了多個 repo, 哪一個是主要落點、其餘各自要改什麼?
  2. 放錯地方的徵兆 — 若照目前的落點做,是否需要把原本屬於別處的知識搬進來? 需不需要讀別的 repo 的資料表或內部模組?
  3. 相依方向 — 新增的相依是誰依賴誰?會不會造成循環相依(A 依賴 B,B 又回頭依賴 A)?
  4. 既有邊界 — 這次改動會不會穿過既有的分層或模組邊界?若會,是邊界本來就畫錯, 還是這次該繞過?
  5. 對外介面 — 會不會改變既有的對外介面?既有呼叫端有誰、要不要同時改?
  6. 可回復性 — 做錯了要怎麼退回?是可以直接 revert,還是會留下已遷移的資料或已發布的介面?

問題怎麼問

每一條檢查若在議題裡找不到答案,就轉成一個問題。問題要具體到能用一句話回答, 不要問「架構上有什麼考量嗎」這種無法收斂的問法。