4.5 跨项目复用与团队工具链

复用的三个层次

  1. 项目内：同一工具模块服务不同系统（常见，成本低）
  2. 跨项目（同团队）：插件化，走 Tools 仓库
  3. 对外分发：市场/开源（要求最高：自包含、文档、兼容性）

工具仓库的推荐结构

ToolsRepo/                      （独立 git 仓库）
├── Plugins/
│   ├── ToolFramework/          空壳插件模板（新建工具照抄）
│   ├── AssetValidator/         检查器框架
│   └── BatchProcessor/         批处理框架
├── Python/                     （Python 脚本集合）
├── Content/                    （可发布的示例资产）
└── README.md                   （工具目录、负责人、用法）

项目通过 submodule 或脚本同步引用。「哪个项目用什么版本」靠 git 记录。

三个机制保证长期可用

① 工具巡检：每季度过一遍 Tools 仓库——哪些没人用了（可以删/存档）、哪些有重复（合并）、哪些在每个项目都修了同样的 bug（说明该统一修）。

② 插件模板/框架：新工具从标准模板起步（统一日志、统一异常处理、标准 UI 结构）。这是降低维护成本的杠杆点。

③ breaking change 流程：工具 API 要改时，先在群里通知 → 加 deprecated 提示 → 下个里程碑删除。

反模式：每个项目复制一份

最常见的坏味道：「工具在项目 A 里写好，复制到项目 B，之后各自演化」。一年后两个版本差异大到无法合并，修 bug 要修两遍。解法就是一开始就走「工具仓库 + 引用」，而不是复制。

工具的「文档」

每个长期工具需要：

  • README：一句话说明做什么、怎么用（10 行内）
  • 负责人：找谁改
  • 示例：一个跑得通的最小例子

团队大了之后，工具发现是个问题——搞一个「工具目录页」（Confluence/内部 wiki），列全所有工具 + 一句话说明 + 入口。新人入职看一遍，比口口相传强。

度量工具价值

想知道哪些工具有用？最简单的办法：

  • 记录运行日志（每工具一个 log 文件，含运行时间戳）
  • 季度统计工具的调用次数
  • 没人用的工具果断淘汰/合并——工具也讲「优胜劣汰」，留着只会占维护成本

心得：一个组织最重要的资产不是某个牛工具，而是「工具持续被创造和迭代的机制」。框架/模板/文档/巡检——这些「生产工具的工具」做扎实了，团队的工具生态也会自增长。我们组从两个人随手写工具，到现在工具仓库 20+ 个工具插件，靠的就是这套机制而不是管理要求。