Git Archaeology #8 — 工程相对论：为何同一位工程师得到不同的分数
Source: Dev.to
Source: …
工程相对论
同一个物体在月球上更轻，在木星上更重。代码库中也会出现同样的现象。
在 第 7 章 中，我谈到了代码库的 宇宙般 结构——引力、四种力以及“老练、良好的引力”。本章讨论的是这种引力的另一项基本属性。
引力取决于其所在的宇宙
观察不同代码库的 EIS 结果时，我注意到：
引力会随宇宙的不同而变化。
EIS 测量的是 你在代码库中创造了多少引力，但引力有一个关键属性：它依赖于所在的空间。
- 在物理学中，地球、月球和木星各自拥有不同的引力场。同一个物体在不同地点会变得更轻或更重。
- 在代码库中，同一位工程师在不同代码库里会得到不同的 EIS 分数。
成熟 vs. 薄弱代码库
| 成熟代码库 | 薄弱代码库 |
|---|---|
| • 结构稳定 | • 没有中心结构 |
| • 已有架构师 | • 设计碎片化 |
| • 抽象已成熟 | • 缺乏抽象 |
| • 已具备“老练、良好的引力” | • 新的引力容易形成 |
- 在成熟的环境中，创造新引力很困难。现有结构越强大，移动中心所需的能量就越大，因此提升 EIS 分数更为艰难。
- 在薄弱的环境中，第一个提出体面设计的人会一夜之间成为架构师，EIS 分数也更容易提升。
结果： EIS 不是 一个绝对值。它取决于工程师 与 代码库引力场之间的相互作用。
这在某种意义上就是 工程相对论——同一位工程师在不同的宇宙中会产生不同的引力。
对工程评估的影响
想象有位工程师的分数如下：
| 仓库 | 描述 | 总分 |
|---|---|---|
| A | 后端 API | 35 |
| B | 新微服务 | 60 |
自然地，60 看起来“更好”。
但如果仓库 A 拥有 极其强大的引力场——多个架构师、高度精炼的结构、经受战斗检验的抽象——那么在这种背景下的 35 实际上可能非常出色。
归一化陷阱： EIS 的相对归一化意味着每个团队的最高贡献者得分为 100，所以一个仓库的最高分在另一个仓库可能只是中等水平。
归一化是一个 计算 问题；工程相对论是一个 结构 问题。代码库本身改变了分数的意义。
如何考虑相对性
1. 查看 eis analyze --team
Structure: Architectural Engine → Strong gravitational field (scores are hard‑earned)
Structure: Unstructured → Weak gravitational field (scores come easily)
Total: 40 inside an Architectural Engine
Total: 40 inside an Unstructured team相同的总分在完全不同的语境下含义迥异。
- 团队中架构师越多，提升你的 Design 轴就越困难。
- 在拥有三位架构师的团队中得到 Design: 60 往往比在没有架构师的团队中得到 Design: 100 更不易。
2. 递归跨仓库分析
eis analyze --recursive ~/workspace跨多个仓库进行分析可以揭示工程师的“跨宇宙引力”。
- 在一个仓库是 生产者，在另一个仓库是 架构师——这种模式揭示了适应能力和潜在能力。
eis timeline --span 6m --periods 0 --recursive ~/workspace代码库结构不是静止不变的。成员离职、重构、新功能——都会改变引力场。时间线帮助你区分：
- 当结构变弱时分数 上升 的工程师
- 无论结构强弱都 保持稳定分数 的工程师
架构师可复制性
真正伟大的工程师能够在 任何 宇宙中创造引力——不同的代码库、团队、以及…
Source: …
在大型代码库中，**架构师（Architect）**的影响往往会在多个仓库之间产生可重复的模式，这种现象我们称之为 架构师可复现性（Architect Reproducibility）。
当你使用 --recursive 对整个工作区进行分析时，持续在多个仓库中扮演 Architect 角色的工程师具备 通用设计能力（general‑purpose design capability），这种能力不依赖于任何特定的代码库。
| 作者 | 后端 API | 前端 | 固件 | 模式 |
|---|---|---|---|---|
| machuz | Architect | Architect | Architect | 可复现 |
| alice | Architect | Producer | — | 依赖上下文 |
| bob | Producer | Producer | Producer | 始终为 Producer |
代码库中的引力透镜
在天体物理学中，巨大的天体会通过弯曲其背后天体的光线——引力透镜（gravitational lensing）——来被发现。
在代码库中，Architect 的“引力”往往最明显的不是体现在他们自己的分数上，而是体现在它如何塑造其他人的分数。
当出现强大的 Architect 时：
- 其他工程师的 Survival 分数可能下降（Architect 的代码占据了主要的 blame）。
- 团队的 Design 轴分布出现偏斜（大部分架构变更都由同一个人承担）。
- 新成员会呈现出典型的“上手曲线”：起始分数低，随后逐步适应并贡献到已有结构中。
当该 Architect 离开时：
- 多位工程师的分数会同步移动。
- 出现 Design Vacuum（设计真空）风险。
- 分数分布的“平坦化”预示着引力中心的消失。
你可以使用 eis timeline --team 观察这一现象：当引力中心消失的那一刻，整个团队的指标会出现波动。引力是真实存在的——只需要通过观察他人指标的变化才能看到它的完整形状。
结论
工程相对论（Engineering Relativity） 并不是 EIS 的局限，而是一个 特性，它反映了工程师与其所处代码库之间的真实、动态关系。理解并考虑这种相对性，你可以：
- 在上下文中解释分数，而不是孤立地看待。
- 识别真正具备适应性的 Architect，他们能够在不同代码宇宙中产生引力。
- 通过团队成员的指标透镜，发现强大 Architect 的隐藏影响。
拥抱相对性，你就能把原始数字转化为关于人、结构以及不断变化的“引力”之间相互作用的更丰富故事。
Source: …
工程相对论
在衡量工程影响时，如何进行公平的比较？
但我并不把这视为限制——而是特性。
当相对论在物理学中被发现时，“没有绝对的时间或空间” 这一事实是反直觉的。接受它导致了对宇宙的指数级更深理解。
EIS 也是如此。
分数随环境而变的事实告诉我们，在忽视环境的情况下比较工程师本质上是毫无意义的。工程师的真实能力不能在真空中测量；它始终与代码库——他们所处的宇宙——相互关联。
真正伟大的工程师在任何宇宙中都能创造引力。
但这种引力在不同宇宙中呈现的形式会不同。
这就是 工程相对论。
章节
- 仅凭 Git 历史衡量工程影响
- 超越个人分数：从 Git 历史衡量团队健康
- 通往架构师的两条道路：工程师的不同进化路径
- 后端架构师的汇聚：安置灵魂的神圣工作
- 时间线：分数不说谎，它们也捕捉犹豫
- 团队进化：时间线揭示的组织法则
- 观察代码宇宙
- 工程相对论：为何同一工程师会得到不同分数 (本篇文章)
工具
- GitHub: engineering-impact-score – CLI 工具、公式和方法论全部开源。
- 通过 Homebrew 安装：
brew tap machuz/tap && brew install eis如果这对你有帮助…
欢迎给仓库加星，将概念分享给你的团队，或贡献改进！