開發者入口網站的技術雷達與路線圖

工程團隊缺乏一個集中式、互動式的方式來視覺化和傳達技術採用決策與策略路線圖。本提案為內部開發者入口網站引入 技術雷達（靈感來自 ThoughtWorks）和 路線圖管理 功能。

關鍵洞察： 分散在 wiki、試算表和部落知識中的技術決策，導致重複的評估工作、不一致的採用，以及對組織技術方向的能見度不足。統一的技術雷達提供了「我們應該使用什麼技術」的單一事實來源。

問題陳述

現狀：碎片化的技術決策

組織中的實際問題

問題	影響
沒有集中的技術登錄	團隊重複評估工作
決策埋藏在會議紀錄中	新成員不知道什麼是被批准的
無法看到棄用狀態	舊技術持續存在，沒有遷移計畫
路線圖在分散的工具中	IC 不清楚策略方向
沒有提案工作流程	技術採用感覺很武斷

真實案例

場景 1：重複評估

「三個團隊在 6 個月內獨立評估了狀態管理函式庫。每個團隊產出不同的建議，因為他們不知道彼此的工作。」

場景 2：隱藏的棄用

「我們兩季前決定棄用 Library X，但它仍然在 Confluence 的『已批准』清單中。新專案持續採用它。」

場景 3：策略失調

「領導層宣布了『雲原生』策略，但沒有路線圖顯示這對團隊意味著什麼。每個團隊的解讀都不同。」

場景 4：外部平台變更未追蹤

「Chrome 六個月前推出了 OffscreenCanvas 和 transferable streams，讓我們可以把重度媒體處理移到 worker 執行緒。但沒人追蹤這件事 - 團隊還在用阻塞主執行緒的 canvas 操作。」

使用案例：追蹤外部平台演進

除了內部技術決策，技術雷達還應該追蹤影響架構方向的外部平台能力。

範例：瀏覽器能力驅動架構

需要追蹤的內容

類別	範例	為何追蹤
瀏覽器 API	OffscreenCanvas、WebGPU、View Transitions	啟用新模式，淘汰舊的變通方案
執行環境變更	Node.js LTS、Deno 功能、Bun 相容性	影響後端架構決策
協定更新	HTTP/3、HTTP QUERY 方法、WebTransport	影響網路層設計
安全標準	CORS 變更、Cookie 政策、CSP 更新	需要應用程式變更
標準組織	W3C DTCG（設計 Token）、OpenAPI 更新、TC39 提案	影響工具和格式決策

記錄外部變更

外部平台變更的技術雷達條目應包含：

markdown

## 技術：OffscreenCanvas + Transferable Streams

### 環：Adopt
### 象限：技術

### 摘要
Chrome 69+ 支援具有可轉移控制權的 OffscreenCanvas，能讓 canvas 渲染
完全在 Web Workers 中進行，無需主執行緒參與。

### 架構影響
- **之前**：重度 canvas 操作阻塞主執行緒，造成卡頓
- **之後**：將 canvas 轉移到 worker，離線處理幀
- **遷移**：識別 canvas 密集元件，重構為 worker 模式

### 受影響系統
- 影片處理管線
- 即時視覺化元件
- 圖片操作功能

### 瀏覽器支援
- Chrome：69+（完整支援）
- Firefox：105+（部分）
- Safari：16.4+（部分）

### 行動項目
- [ ] 審計前端目前的 canvas 使用情況
- [ ] 建立基於 worker 的 canvas 工具庫
- [ ] 遷移影片縮圖產生器（影響最大）
- [ ] 更新效能指南

範例：協定演進（HTTP QUERY 方法）

markdown

## 技術：HTTP QUERY 方法（RFC 草案）

### 環：Assess
### 象限：技術

### 摘要
IETF 草案提議 QUERY 作為新的 HTTP 方法 - 類似 GET 但可帶請求主體。
解決了複雜查詢超出 URL 長度限制的問題。

### 架構影響
- **之前**：複雜搜尋查詢使用 POST（不可快取）或 URL 編碼
- **之後**：QUERY 方法允許帶請求主體且具有類似 GET 的可快取性
- **API 設計**：可簡化搜尋/篩選端點

### 目前狀態
- IETF 草案階段（尚非 RFC）
- 尚無瀏覽器/伺服器支援
- 值得追蹤以用於未來 API 設計

### 行動項目
- [ ] 監控 IETF 草案進度
- [ ] 評估對目前使用 POST 的搜尋 API 的影響
- [ ] 在伺服器/客戶端支援可用後規劃採用

範例：標準組織決策（W3C DTCG）

markdown

## 技術：W3C Design Tokens Community Group（DTCG）格式

### 環：Assess
### 象限：技術

### 摘要
W3C DTCG 正在標準化基於 JSON 的設計 token 格式。一旦定稿，
這將成為設計工具（Figma、Sketch）和開發工具鏈之間的互通標準。

### 架構影響
- **之前**：每個設計系統使用專有 token 格式
- **之後**：統一格式實現工具無關的 token 管線
- **遷移**：評估目前 token 格式，規劃遷移路徑

### 為何現在追蹤
- 草案規格正在穩定
- 主要工具（Figma Variables、Style Dictionary）正在對齊規格
- 早期採用減少未來遷移成本

### 行動項目
- [ ] 評估目前設計 token 格式 vs DTCG 規格
- [ ] 測試 Style Dictionary DTCG 外掛
- [ ] 與設計團隊討論 Figma Variables 匯出格式
- [ ] 規劃漸進式遷移策略

與路線圖整合

外部平台變更應連結到內部路線圖里程碑：

外部變更	路線圖里程碑	時程
WebGPU 在 Chrome 穩定	GPU 加速視覺化階段	Q2
View Transitions API	SPA 導航改進	Q3
W3C DTCG 規格定稿	設計系統 token 格式遷移	Q4
Baseline 2024 功能	瀏覽器支援政策更新	Q1

提案：技術雷達與路線圖

目標狀態

技術雷達視覺化

雷達顯示跨四個環和四個象限的技術採用狀態：

環（採用狀態）

環	含義	行動
Adopt	已驗證，建議廣泛使用	預設使用
Trial	值得追求，低風險實驗	在新專案中謹慎使用
Assess	值得探索，了解影響	評估，尚未承諾
Hold	謹慎行事，主動避免	不要開始新的使用

象限（技術類別）

象限	範例
語言與框架	TypeScript、React、Go、Spring Boot
工具	Docker、Kubernetes、Terraform、GitHub Actions
平台	AWS、GCP、Cloudflare、Vercel
技術	主幹開發、功能旗標、BFF 模式

雷達視覺化元件

主要功能：

可懸停/點擊查看詳情的互動式雷達
依象限、環或搜尋詞篩選
技術詳細面板，包含理由、ADR 連結、採用歷史
歷史比較視圖（跨時間段比較雷達）
匯出為 PNG/PDF 用於簡報

技術提案工作流程

提案生命週期

提案範本

markdown

## 技術提案：[名稱]

### 摘要
一段話描述技術及其重要性。

### 建議環
[ ] Adopt  [ ] Trial  [ ] Assess  [ ] Hold

### 象限
[ ] 語言與框架  [ ] 工具  [ ] 平台  [ ] 技術

### 問題陳述
這解決什麼問題？為什麼是現在？

### 評估標準
- 效能基準
- 安全評估
- 學習曲線
- 社群支援
- 授權相容性

### 證據
- 概念驗證結果
- 團隊回饋
- 與替代方案的比較

### 風險與緩解
| 風險 | 緩解 |
|------|------|
| ... | ... |

### 發起人
[提案發起人的姓名和團隊]

投票與批准

角色	能力
貢獻者	提交提案、對提案投票
審查者	批准/拒絕提案、請求修改
管理員	管理雷達、覆蓋決策、配置設定

批准門檻（可配置）：

Adopt：需要 3+ 審查者批准
Trial：需要 2+ 審查者批准
Assess：需要 1 審查者批准
Hold：需要 2+ 審查者批准（用於棄用）

路線圖管理

路線圖結構

路線圖功能

時間軸視圖：包含里程碑和相依性的視覺化時間軸
里程碑管理：建立、編輯、追蹤里程碑狀態
相依性追蹤：顯示計畫之間的關係
進度指標：計畫中 / 進行中 / 已完成 / 已阻擋
匯出選項：PNG、PDF、嵌入碼用於文件

路線圖與雷達整合

路線圖里程碑可以連結到：

技術雷達項目（技術決策）
ADR（架構決策）
相關文件

技術設計

資料模型

technologies
├── id: UUID
├── name: string
├── description: text
├── quadrant: enum (languages, tools, platforms, techniques)
├── homepage_url: string
├── created_at: timestamp
└── created_by: user_id

radar_snapshots
├── id: UUID
├── technology_id: FK
├── ring: enum (adopt, trial, assess, hold)
├── rationale: text
├── snapshot_date: date
├── created_by: user_id
└── related_adrs: UUID[]

proposals
├── id: UUID
├── technology_id: FK (nullable for new tech)
├── proposed_ring: enum
├── status: enum (draft, review, approved, rejected)
├── sponsor_id: user_id
├── content: jsonb
├── created_at: timestamp
└── updated_at: timestamp

votes
├── id: UUID
├── proposal_id: FK
├── user_id: FK
├── vote: enum (approve, reject, abstain)
├── comment: text
└── created_at: timestamp

roadmaps
├── id: UUID
├── title: string
├── description: text
├── start_date: date
├── end_date: date
├── owner_id: user_id
└── visibility: enum (public, team, private)

milestones
├── id: UUID
├── roadmap_id: FK
├── title: string
├── description: text
├── target_date: date
├── status: enum (planned, in_progress, completed, blocked)
├── dependencies: UUID[]
└── linked_technologies: UUID[]

API 端點

端點	方法	描述
`/api/radar`	GET	取得目前雷達狀態
`/api/radar/history`	GET	取得歷史快照
`/api/radar/technologies`	GET/POST	列出/建立技術
`/api/radar/technologies/:id`	GET/PUT/DELETE	管理技術
`/api/radar/proposals`	GET/POST	列出/建立提案
`/api/radar/proposals/:id/vote`	POST	對提案投票
`/api/roadmaps`	GET/POST	列出/建立路線圖
`/api/roadmaps/:id/milestones`	GET/POST	管理里程碑

視覺化函式庫

建議：D3.js

選項	優點	缺點
D3.js	最大彈性，強大社群	學習曲線較高
Zalando Tech Radar	預建雷達	客製化有限
Chart.js	易於使用	無原生雷達環支援

D3.js 提供互動功能（懸停詳情、篩選、動畫）所需的彈性，同時是維護良好且社群支援強大的函式庫。

實施路線圖

第一階段：基礎

目標： 基本雷達視覺化與靜態資料。

[ ] 設置技術和快照的資料庫架構
[ ] 建立雷達視覺化元件（D3.js）
[ ] 實作技術的基本 CRUD API
[ ] 新增象限篩選和搜尋
[ ] 部署只讀雷達與策展的初始資料集

第二階段：提案工作流程

目標： 啟用協作式技術提案。

[ ] 實作提案提交表單
[ ] 新增投票機制
[ ] 建立審查者儀表板
[ ] 建置提案更新的通知系統
[ ] 為技術主管啟用提案功能

第三階段：路線圖管理

目標： 基於時間軸的路線圖功能。

[ ] 建立路線圖資料模型和 API
[ ] 建置時間軸視覺化元件
[ ] 實作里程碑管理
[ ] 新增相依性追蹤
[ ] 啟用路線圖與雷達連結

第四階段：整合

目標： 與現有系統連接。

[ ] 將雷達項目連結到 ADR
[ ] 與開發者入口網站搜尋整合
[ ] 新增 RSS/webhook 通知
[ ] 啟用文件嵌入碼
[ ] 使用 OpenAPI 規格的 API 文件

CLAUDE.md 整合

新增至專案 CLAUDE.md：

markdown

## 技術雷達

### 技術選擇
- **務必查看** 技術雷達後再採用新技術
- **優先選擇** Adopt 環中的技術
- **記錄理由** 當使用 Trial 或 Assess 技術時
- **絕不使用** Hold 技術，除非有明確的例外批准

### 搜尋策略
選擇技術時：
1. 查看技術雷達中的現有決策
2. 搜尋相關 ADR
3. 如果找不到，考慮提交提案

### 禁止事項
- 未經例外批准就採用 Hold 環技術
- 建立重複的技術評估
- 忽視棄用時間表

成功指標

指標	之前	目標	如何衡量
重複評估	常見	罕見	追蹤相同技術的提案
技術決策能見度	低	高	調查：「你知道在哪裡找到技術決策嗎？」
找到已批准技術的時間	分鐘	秒	任務計時研究
棄用合規性	未知	>90%	審計 Hold 技術的使用情況
提案週轉時間	N/A	<2 週	追蹤提案生命週期時長

風險與緩解

風險	緩解
雷達變得過時	季度審查節奏，每象限指定負責人
提案過多	每季提案限制，需要發起人
投票系統被操縱	依專業加權投票，審查者監督
視覺化效能問題	分頁，基於象限的延遲載入
採用阻力	從只讀開始，逐步啟用貢獻功能

待解決問題

路線圖是否應該支援跨路線圖的相依性？
歷史雷達快照的保留政策是什麼？
整合優先順序：ADR、wiki 還是專案管理工具？
應該支援自訂象限標籤還是強制標準？
如何處理跨越多個象限的技術？

相關： AI 代理友善知識庫 | 返回： 提案概覽

參考資料

ThoughtWorks Technology Radar - 原始技術雷達概念
Zalando Tech Radar - 開源雷達實作
Backstage Tech Radar Plugin - Spotify 開發者入口網站雷達
AOE Technology Radar - 另一個雷達實作範例

開發者入口網站的技術雷達與路線圖 ​

問題陳述 ​

現狀：碎片化的技術決策 ​

組織中的實際問題 ​

真實案例 ​

使用案例：追蹤外部平台演進 ​

範例：瀏覽器能力驅動架構 ​

需要追蹤的內容 ​

記錄外部變更 ​

範例：協定演進（HTTP QUERY 方法） ​

範例：標準組織決策（W3C DTCG） ​

與路線圖整合 ​

提案：技術雷達與路線圖 ​

目標狀態 ​

技術雷達視覺化 ​

環（採用狀態） ​

象限（技術類別） ​

雷達視覺化元件 ​

技術提案工作流程 ​

提案生命週期 ​

提案範本 ​

投票與批准 ​

路線圖管理 ​

路線圖結構 ​

路線圖功能 ​

路線圖與雷達整合 ​

技術設計 ​

資料模型 ​

API 端點 ​

視覺化函式庫 ​

實施路線圖 ​

第一階段：基礎 ​

第二階段：提案工作流程 ​

第三階段：路線圖管理 ​

第四階段：整合 ​

CLAUDE.md 整合 ​

成功指標 ​

風險與緩解 ​

待解決問題 ​

參考資料 ​

開發者入口網站的技術雷達與路線圖

問題陳述

現狀：碎片化的技術決策

組織中的實際問題

真實案例

使用案例：追蹤外部平台演進

範例：瀏覽器能力驅動架構

需要追蹤的內容

記錄外部變更

範例：協定演進（HTTP QUERY 方法）

範例：標準組織決策（W3C DTCG）

與路線圖整合

提案：技術雷達與路線圖

目標狀態

技術雷達視覺化

環（採用狀態）

象限（技術類別）

雷達視覺化元件

技術提案工作流程

提案生命週期

提案範本

投票與批准

路線圖管理

路線圖結構

路線圖功能

路線圖與雷達整合

技術設計

資料模型

API 端點

視覺化函式庫

實施路線圖

第一階段：基礎

第二階段：提案工作流程

第三階段：路線圖管理

第四階段：整合

CLAUDE.md 整合

成功指標

風險與緩解

待解決問題

參考資料