回看 2018，如果用一個詞概括，我會選"體系化"。年初還在為各個項目重複造輪子，年底已經有了一套可複用的工程化體系：統一的構建方案、跨項目共享的組件庫、團隊級的代碼質量規範。技術債清了不少，基建也鋪得差不多了。是時候做個覆盤。

一、年度技術里程碑

TypeScript 全面落地

年初決心在主推的中後台項目上引入 TypeScript。當時的團隊阻力不小——"多寫那麼多類型有什麼用"是最常聽到的聲音。

推動策略是漸進式：先在新增模塊上用，再逐步改造已有代碼。兩個月後，重構改了接口簽名，編輯器立刻標出所有受影響的調用點，團隊的態度從質疑變成了依賴。到年底，項目 TypeScript 覆蓋率已經超過 70%，核心業務模塊全面覆蓋。

Webpack 4 遷移

從 Webpack 3 升到 4，不只是改配置。項目編譯時間從平均 120 秒降到 40 秒，利用 splitChunks 做了智能分包後，首屏 JS 體積從 680KB 壓縮到 420KB。同時搭建了統一的構建配置方案，沉澱成 build-scripts 包，新項目初始化時間從半天降到半小時。

Vue 深入與 React 探索

Vue 方面深入了響應式原理和組件設計模式，主導了內部組件庫從設計到發佈的全流程。同時開始系統學習 React——不為了替代 Vue，而是為了在技術選型上有更理性的判斷。年底拿到一個數據可視化需求，React + D3 的方案比 Vue 實現更順暢，驗證了雙框架能力的實際價值。

Node.js BFF 層

年末開始做 BFF（Backend for Frontend）中間層，用 Koa 做了接口聚合和數據轉換。雖然還沒上線，但已經跑通了完整的鏈路，驗證了前後端分層解耦的可行性。

二、工程化成果

組件庫建設

主導完成了 @company/ui 組件庫，覆蓋表格、表單、篩選器、圖表容器等 40 餘個業務級組件。設計思路是"封裝業務模式而非 UI"——比如 <SmartTable> 封裝了排序、篩選、分頁的完整交互，業務層只需配置列定義和數據源。

至今已有 5 個在建項目接入，組件複用率達到 60%。新項目 UI 開發工作量平均減少 40%。

構建優化數據

| 指標 | 年初 | 年底 | 提升 | | ------|------|------|------| | 編譯時間 | ~120s | ~40s | 66% | | 首屏 JS 體積 | 680KB | 420KB | 38% | | 新項目初始化 | ~4h | ~30min | 87% |

這些數字背後是 HappyPack 多線程構建、SplitChunks 分包、tree-shaking 和 ModuleConcatenationPlugin（作用域提升）的綜合運用。

代碼質量工具鏈

接入 ESLint + Prettier 統一代碼風格，配合 husky + lint-staged 做提交前檢查。團隊代碼風格爭議降到了幾乎為零——規則寫在配置裏，不用在 Code Review 裏扯皮。

三、代碼質量演進

類型系統和錯誤處理的變化最能體現成熟度的提升。以一個典型的 API 調用為例：

// 年初風格：能跑，但脆弱
async function handleSubmit() {
  this.loading = true;
  const res = await axios.post("/api/order", this.form);
  if (res.data.code === 0) {
    this.$message.success("提交成功");
    this.$router.push("/orders");
  }
  this.loading = false;
}

// 年底風格：有類型約束、有錯誤分類、有邊界保護
interface OrderForm {
  productId: string;
  quantity: number;
  remark?: string;
}

async function handleSubmit(): Promise<void> {
  this.submitting = true;
  try {
    const order = await orderApi.create<Order>(this.form);
    this.$message.success(`訂單 ${order.id} 創建成功`);
    this.$router.push({ name: "OrderDetail", params: { id: order.id } });
  } catch (e) {
    if (e instanceof ApiError) {
      switch (e.code) {
        case "STOCK_INSUFFICIENT":
          this.stockError = true;
          break;
        case "ORDER_LIMIT_EXCEEDED":
          this.$message.warning("已達下單上限");
          break;
        default:
          this.$message.error(e.message);
      }
    } else {
      throw e; // 非業務錯誤交給全局錯誤處理
    }
  } finally {
    this.submitting = false;
  }
}

差異不只是"加了類型"。核心變化是：API 調用有返回類型約束，錯誤有業務分類的處理邏輯，非預期錯誤不會被吞掉，finally 保證狀態一致。寫代碼的心態從"跑通就行"變成了"讓三個月後的自己也能看懂、能改"。

四、團隊協作經驗

Code Review 文化

年中開始推動團隊做 Code Review，初期阻力很大。轉折點是第一次通過 Review 發現了一個 N+1 請求的性能問題——前端每次彈窗都會觸發 50 次並行請求，改了之後彈窗加載從 3 秒降到 0.5 秒。用實際數據説話，比講道理有效。

到年底，Code Review 已經變成團隊習慣，PR 合併前必須有人 Review。更重要的是，Review 的內容從"少個分號"變成了"這個抽象層級對不對""這個狀態管理方案有沒有更優解"。

知識分享

在團隊內部做了 4 次技術分享：TypeScript 實踐、Webpack 優化策略、組件庫設計思路、Vue 性能優化。每次分享倒逼自己把知識點體系化梳理。也開始鼓勵團隊裏的其他人做分享，培養"輸出倒逼輸入"的學習氛圍。

五、未完成的遺憾

坦率説，有幾塊今年做得不夠：

測試覆蓋率仍然偏低。寫了部分核心邏輯的單元測試，但遠沒有形成常態。組件庫的測試還算完整，業務代碼幾乎沒有測試。這不是懶，是優先級判斷——今年先解決"從 0 到 1"的工程化基建，測試是"從 1 到 10"的質量保障，排在 2019。

CI/CD 流水線還是運維同事在維護。我對 Jenkins 的理解停留在"配置改了能跑"的層面，還沒有系統地掌握自動化部署、環境管理、發佈回滾這些流程。這是一個架構師視角必須補齊的能力。

文檔體系不夠完善。組件庫有 README 但沒有完整的使用文檔和 API 説明，組件間的設計決策也沒有記錄。接新人來時才發現文檔的重要性——很多"為什麼這麼做"只有寫的人知道。

這些問題我都不視為失敗，而是看清了"工程化體系建設"和"工程化體系成熟"之間的距離。2019 的目標就是縮短這個距離。

六、2019 規劃

技術深耕

• 測試體系化：給組件庫補齊完整的單元測試，業務代碼測試覆蓋率目標 60%+。探索 E2E 測試方案（Cypress 或 Puppeteer）。
• CI/CD 自主掌握：搭建前端專屬的 CI/CD 流水線，包含 lint、test、build、deploy 全流程自動化。
• React 深入：不滿足於使用層面，深入 hooks 源碼和 Fiber 架構。考慮一個新項目用 React 從零搭建，積累跨框架經驗。
• 監控與告警：搭建前端監控體系，覆蓋錯誤捕獲、性能指標、用户行為追蹤。從方案設計開始，不是接第三方 SDK 了事。

架構能力

• 微前端調研：團隊項目越來越多，部署和維護成本在上升。需要評估微前端方案（qiankun / Module Federation），看是否適合現有技術棧。
• BFF 層上線：把年末的 Koa BFF 原型打磨到生產可用，真正實現前後端數據層解耦。
• 組件庫文檔站：搭建組件庫文檔站（類 Storybook），補齊 API 文檔和交互式示例。

團隊建設

• 推動 Code Review 規範寫入團隊 Wiki，新人入職自動了解流程。
• 建立"每週技術分享"機制，覆蓋團隊成員，不再只靠我一個人輸出。
• 開始培養 1-2 個能獨立負責技術方向的同事，把"架構"從個人能力變成團隊能力。

小結

• TypeScript 全面落地，項目覆蓋 70%+，重構效率和代碼可靠性顯著提升
• Webpack 4 遷移完成，編譯速度提升 66%，首屏體積壓縮 38%
• 主導組件庫建設，40+ 業務組件，5 個項目接入，新項目 UI 工作量減少 40%
• 推動 Code Review 文化落地，從形式化走向實質性技術討論
• 測試覆蓋率、CI/CD、文檔體系是明年必須補齊的短板
• 2019 核心方向：質量保障體系化 + 架構能力拓展 + 團隊技術傳承