jiantw83andClaude Opus 5
b79c68613a
時程清單的「相依鏈最長路徑」預設了一份工作拆法，但分析階段還沒有工作包可依， 照著問會問不出東西。補上說明：這個階段要先拉一份暫定拆法，它同時是下一段開 工作包的草稿；拆不出來本身就是一個要問使用者的問題。 架構清單原本在開頭多了一段中間文字，內容與自己的「問題怎麼問」重複，也讓它 成為四份裡唯一結構不同的一份，移除。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 lines
1.2 KiB
Markdown
21 lines
1.2 KiB
Markdown
# 架構可行性檢查
|
|
|
|
問的是「這件事該不該在這裡做、做了會不會把結構弄壞」。
|
|
|
|
## 檢查項
|
|
|
|
1. **落點** — 這個需求該由哪一個 repo 承接？若需求議題的「影響範圍」列了多個 repo，
|
|
哪一個是主要落點、其餘各自要改什麼？
|
|
2. **放錯地方的徵兆** — 若照目前的落點做，是否需要把原本屬於別處的知識搬進來？
|
|
需不需要讀別的 repo 的資料表或內部模組？
|
|
3. **相依方向** — 新增的相依是誰依賴誰？會不會造成循環相依（A 依賴 B，B 又回頭依賴 A）？
|
|
4. **既有邊界** — 這次改動會不會穿過既有的分層或模組邊界？若會，是邊界本來就畫錯，
|
|
還是這次該繞過？
|
|
5. **對外介面** — 會不會改變既有的對外介面？既有呼叫端有誰、要不要同時改？
|
|
6. **可回復性** — 做錯了要怎麼退回？是可以直接 revert，還是會留下已遷移的資料或已發布的介面？
|
|
|
|
## 問題怎麼問
|
|
|
|
每一條檢查若在議題裡找不到答案，就轉成一個問題。問題要具體到能用一句話回答，
|
|
不要問「架構上有什麼考量嗎」這種無法收斂的問法。
|