現象：為什麼簡單專案也會失控？
入職新公司，接手一個「後台與資料庫皆就緒」的企業官網，兩人團隊預估 3 天，實際耗時 7 天。複盤發現：
- 夥伴自稱資深，實則將網路下載的
phpmywind 舊框架硬套，資料庫連線類、公共函數庫殘留大量死碼。
- SQL Server 2000 環境下仍使用 MySQL 寫法，導致頻繁語法錯誤。
- 溝通機制缺失：提出改進建議遭「這麼簡單你自己改」回應，代碼審查形同虛設。
- 缺乏專案規範：無編碼標準、無 Git Flow、無測試策略、無部署腳本。
根因剖析：三大認知誤區
| 誤區 | 表現 | 後果 |
|---|
| 「先跑起來再說」 | 忽略架構設計、資料模型驗證、介面契約 | 後期重構成本指數級上升 |
| 「工具解決一切」 | 盲目複製貼上框架/程式碼，不理解原理 | 技術債堆疊，遇到非標準場景束手無策 |
| 「溝通是浪費時間」 | 避免代碼審查、拒絕技術分享、回應建議帶情緒 | 團隊知識孤島，單點故障風險極高 |
破局行動指南：從執行者到工程師
1. 建立「最小可行性專案規範」
專案啟動清單：
☐ 技術棧確認書（語言版本、框架、資料庫、中介軟體）
☐ 資料庫設計文檔（ER 圖、索引策略、命名規範）
☐ API 契約（OpenAPI/Swagger，前後端並行開發基石）
☐ Git 分支策略（main/develop/feature/hotfix + PR 強制審查）
☐ 程式碼風格（PHP-CS-Fixer + PHPStan Level 5+ 配置入庫）
☐ CI/CD 流水線（測試 → 靜態分析 → 建構 → 部署）
☐ 監控告警（日誌聚合、錯誤追蹤、業務指標）
2. 刻意練習「提問式溝通」
- ❌ 「這段代碼有問題」
- ✅ 「這裡用
mysqli 連 SQL Server 會不會有編碼問題？我看文檔建議用 sqlsrv 驅動，您覺得呢？」
- ✅ 「我們能不能在 PR 模板加上『影響範圍』欄位，方便審查者聚焦風險點？」
3. 構建個人知識管理系統
- 每日 15 分鐘記錄：踩坑、優化、新學語法、架構決策理由
- 週末複盤：將碎片知識整理為 Markdown 文檔，發布部落格/內部 Wiki
- 建立「技術雷達」：評估新技術採用/試用/暫緩/淘汰四象限
4. 培養「業務視角」
工程師不僅交付代碼，更交付商業價值：
- 理解專案為何而建、成功指標為何（轉換率、GMV、用戶留存）
- 主動提案：例如「加入頁面載入埋點，量測 LCP/CLS，優化首屏體驗預估提升轉換 3%」
- 風險前置：上線前產出《回滾預案》、《壓測報告》、《資料遷移驗證腳本》
給新人的三條鐵律
- 動手前先思考 10 分鐘：畫時序圖、列出異常流、確認邊界條件。
- 每次提交都要能自圓其說：Commit Message 遵循 Conventional Commits，關聯 Issue/PR。
- 主動尋求回饋：每週主動約一位資深同事進行 30 分鐘代碼走讀，而非等待被審查。
技術深度決定你的上限，工程素養決定你的下限，業務理解決定你的不可替代性。拒絕做「碼農」，從今天的第一行代碼開始，做一個負責任的軟體工程師。
