模組化和包管理

pnpm workspace 是個很有意思的用法，可以把各個子目錄正式化為統一管理的程式模組，讓各個模組存在轉為可以通過 @xxx/xxx 形式引入的包。這種把多個模組聚合在一個倉庫的架構，就叫做monorepo，他的好處就是all in one，全放在一起管理，而不需要在多個倉庫（或者分散的資料夾，邏輯上和倉庫類似）中跳來跳去，在維護和版控管理上要方便的多。

比如原先是

  backend/       ← 后端，有自己的 package.json
  frontend/      ← 前端，有自己的 package.json
  shared/        ← 共享类型（靠手抄同步到 frontend）

而利用 pnpm workspace 就可以將整個專案轉為

 project/
  ├── pnpm-workspace.yaml        ← 新增：声明 packages/* 是工作区成员
  └── packages/
      ├── backend/               ← 原 backend
      ├── frontend/
      └── shared/                ← 变成一个真正的包：@editorial/shared

這對於跨模組要共享同樣型別或者契約來說是非常方便的。原先的分離資料夾形式還需要手動去核對，時間長非常容易飄，尤其是相對目錄這種東西，一旦未來需要調整結構，基本上整個程式碼就得全改。因此，最簡便且規整的方式就是將其抽象為包，交給包管理器統一調配。如果未來需要調整、擴展，都只需要在這個基礎上順延即可，非常方便。

同時還有依賴管理方面，也可以讓所有模組的依賴進行統一管理，而不是各寫各的。從供應鏈安全和可能的穩健性上來說，都比分散在各自的內部要好的多。對於ai時代的程式設計來說，相較於 基於過程的質量控制 裡面提過的利用「微服務」來隔離各個倉庫，monorepo 的代價會更低一點。尤其是運維上，搞個k8s多少還是負擔太大了。整體上來說，微前端或者monorepo這種輕量級的模組化管理手段還是我更青睞的形式。

不過ai時代最大的優勢就是「程式碼富裕」，架構開始逐漸勝於純粹的「程式碼增量」。過去工程師可能會因為編碼成本過高而放棄清晰且隔離的架構，因為整體上的維護和開發成本會增加。但今天，ai時代的開發成本被壓縮到極致，反而是維護成本開始成為短板。此時，架構清晰的優勢就會勝出——好測試、穩健性且低耦合的程式碼，在可維護性上遠比龐雜的程式碼要更容易。尤其是對於ai開發來說，比起讓它在依託難以名狀的麵條裡面遨遊，一改改成全局崩塌，還不如讓它在清晰且界限明確的島嶼之間秩序通行。至少對於後者來說，即便出現問題，其邊界也能嚴格控制在島嶼內部，但若是前者，連鎖反應就可能導致塌陷式的全面崩塌。從穩健性上來說，顯然是島嶼勝出。