管理技术质量 (Manage Technical Quality)

"当我能帮团队完善一个有价值但计划不足的提案时，我特别有成就感。一个结构合理的计划能大幅缩小范围并获取最大价值，从而更快展现影响力。"

Dmitry Petrashko

工程师、管理者和高管们往往在一个问题上容易达成共识：我们的技术质量出现了危机。大家通常会得出一种简单的诊断和解决办法：工程师不够重视质量，我们要么招更好的工程师，要么重新培训现有的工程师。这是一个带有明显"反派"的诱人借口，它很方便地把责任从工程领导层身上推开。但这种把责任推给权力最小的群体的说法，既没用又不对。

技术质量低并不是危机的表现，而是软件发展的常态。随着公司的扩张、转型或进军企业级市场，成功的公司会不断提高他们的质量标准。在一家运作良好的公司里，过去的许多技术决策必然无法满足现在的质量要求。所以，填补当前质量与目标质量之间的差距，不是一种失败，而是工程领导层日常且必不可少的工作。

问题所在

工程领导团队的目标是：在维持适当技术质量的同时，将尽可能多的精力投入到核心业务中。你必须在不同时间维度的需求中寻找平衡。比如，为了赶下周的截止日期交付关键项目，与为了下季度能提升十倍发布速度而搭建平台，这两种工作截然不同。

随着公司质量标准的不断变化，你管理技术质量的方法也应同步演进：

解决引发眼下紧急问题的热点 (hot spots)
引入公认能提升质量的最佳实践 (best practices)
优先关注能长期维持质量的杠杆点 (leverage points)
统一组织开发软件的技术方向 (technical vectors)
衡量技术质量 (measure technical quality)，指导更深入的投资
组建技术质量团队 (technical quality team)，专门开发质量系统和工具
运行质量项目 (quality program)，进行衡量、跟踪和问责

请记住：选择最便宜、最简单的有效工具。技术质量是一场长期游戏，没有绝对的终点，只有不断学习并继续走下去。

循序渐进

寻找通用解决方案固然令人兴奋，但快速解决眼下问题并推进下一步同样重要。

在规划质量改进时，最有效的方法是从最轻量级的方案开始。只有当早期方法无法承受规模的压力时，才向大型解决方案推进。如果你的团队连最基础的代码检查（linting）都不愿采用，那你全面推行大型质量项目的尝试注定会失败。

所以，先做简单的事！

即便失败了，在简单事情上的试错成本也比复杂事情低得多，这能帮你更快进入更好的下一次迭代。慢慢向综合方案过渡即可，无需着急。

虽然这些阶段看起来像逐级上升的楼梯，但实际操作通常不是线性的。你可能会先修复一个热点，引入一个最佳实践，启动一次架构审查，然后取消这个审查，接着又回去修热点。如果某个流程不起作用，尝试调整一下；如果还是不行，就痛快地抛弃它。

热点问题

遇到质量问题时，人们常常本能地认为是流程出了错，需要用新流程来解决。比如，一次部署导致了宕机，就认为是开发者没按流程测试，于是规定以后每次提交都必须带测试。

这就像是对萨班斯-奥克斯利法案的一个老笑话：它并没有降低风险，只是在出事时让大家清楚该找谁背锅。靠增加流程来问责的作用有限，更重要的是理解问题本身并直接解决它。

流程的改变需要人改变工作习惯，这很难。因此，与其增加流程，不如采用性能工程师的思维：测量问题，找出问题最集中的地方，然后精准打击。

比如对于未测试的部署，你可以直接给部署的工程师反馈，帮他们改变习惯；或者承认系统设计本身容易出错，采用《软件设计哲学》中"从根源上消除错误"的设计方法。

如果是开发速度慢，你可以优化测试时间、把 Docker 编译步骤移到 RAM disk 上，或者使用《软件设计 X 射线》中的技术找出需要优化的特定文件。

系统思维是一种极具变革性的思考方式。有时，你不需要花力气培训团队写更好的测试，而是可以直接删掉那个导致了 98% 测试失败的旧文件。这就是优先解决热点问题的奇效。

当你发现组织产生质量问题的速度快于你修复热点的速度时，就是时候引入最佳实践了。

最佳实践

我曾待过一家公司，由于缺乏团队规划流程，工程主管强令大家使用敏捷开发（Scrum）。经理们把流程写在维基上，发了公告，然后宣布大功告成。结果呢？根本没人真正用 Scrum。但因为大家都怕承认错误，主管依然把这当成一次重大胜利。

这个悲伤的故事反映了许多公司推行最佳实践的现状。推行最佳实践需要组织和领导具备一定的成熟度，所以我建议在解决完热点问题后再进行。

推行新实践时要记住：好的流程是演进而来的，而不是强加的。研究其他公司的做法，写下计划，先在几个积极的团队中试验，打磨掉阻力，完善文档，最后再全面推广。仓促的流程注定失败。

同样重要的是：一次只推行一个新流程。如果你同时推行多个新实践，你就是在分散团队的注意力。集中所有精力让一个实践取得成功，好过把资源摊薄在几个半吊子的项目上。

对于该优先采用哪些实践，建议参考《Accelerate》一书中基于数据研究的结论。我早期最推荐采用的包括：版本控制、主干开发、CI/CD、生产环境可观测性（开发者为自己写的系统值班）以及小批量修改代码。如果你想了解内部文档建设，可以看看这篇关于投资内部文档的文章。

如果你发现自己总想增加正在进行中的实践数量，这就意味着你需要进入下一个阶段：寻找杠杆点了。

杠杆点

除了优化当前的热点问题，在软件演进的过程中，还有少数几个关键领域，如果在上面多投入一点，就能长久地保持代码质量并降低未来的维护成本。我称之为质量杠杆点，最具影响力的三个是：接口、有状态系统和数据模型。

接口 (Interfaces) 是系统间的契约。有效的接口将客户端与实现解耦。持久的接口只暴露必要的复杂性。令人愉悦的接口设计是克制而敏锐的。
状态 (State) 是所有系统中最难修改的部分，这使得有状态系统成为关键杠杆点。随着安全、隐私和合规要求的增加，修改有状态系统会变得异常困难。
数据模型 (Data models) 是接口和状态的交集。好的数据模型是严格的：它只允许合法的状态存在，同时也能包容未来的演进。有效的数据模型绝不会耍小聪明。

处理这些杠杆点时，要更加刻意和谨慎。如果是接口，找几个真实的客户端来对接模拟实现；如果是数据模型，拿真实的业务场景来验证；如果是有状态系统，测试它的故障模式和一致性。撰写技术规范、收集同行反馈，并在实施过程中保持开放的心态。

投资杠杆点的一个隐藏优势是：你不需要全组织的共识就能开始做，只要针对具体系统发力即可。

技术方向

高效的组织会将主要精力集中在共同的愿景上。如果把每个技术决策看作网格上的一个向量，向量方向越一致，团队长期的产出就越大。反之，那些方向跑偏的强力工程师，反而会给组织带来破坏。

你可以通过指定一位带架构师 (Architect) 头衔的人来统一决策，但这难以规模化。对齐技术方向的更佳工具包括：

直接反馈：遇到方向不一致时，别急着改流程，直接找当事人沟通。消除信息差往往能省去几年不必要的流程。
完善工程战略 ：从技术规范、战略到愿景逐步明确方向。
将方法封装在工具和工作流中：光靠文档没用。通过工具培养习惯。比如，要开通新服务，必须在内部网站上先提交技术规范链接；不配置值班人员，就不允许部署代码。
在入职时进行培训：在人们刚加入、习惯还未固化时，就引导他们走向正确的方向。
利用康威定律 (Conway's Law)：组织架构会决定软件的结构。优秀的组织设计本身就是一种提升质量的力量。
管理技术变更 ：使用架构审查、投资策略和引入新工具的结构化流程。这是最后推荐的手段，前提是组织已经有了清晰的愿景。

无论用什么方法，统一方向都需要数月甚至数年的时间。如果这些常规方法不够用，那第一步应该永远是：衡量。

衡量技术质量

《Accelerate》提供了衡量开发速度的指标，但这都是在代码合并之后的。我们该如何衡量代码库本身的质量，以便发现问题并评估改进效果呢？

像 PR 修改的文件数、单文件代码行数等只能作为代码质量的代理指标。要真正衡量质量，你需要制定一个极其精确的质量定义 。这个定义越详细，对指导改进越有用。具体方法可参考《构建演进式架构》和挽救不合理的软件。

你的质量定义可以包含：

代码静态类型的比例是多少？
有多少文件有对应的测试？代码库的测试覆盖率是多少？
是否所有端点都在冷启动后 500ms 内响应？
有多少高频修改的文件（在超过一半的 PR 中都被改动）？

你不需要照搬上面的标准，定义应当针对你代码库的具体需求。关键是要做到清晰可衡量。

定义完成后，通过数据检测（instrumentation）来收集指标。这虽然很难，但一旦跑通，你将获得一个动态的质量评分面板，为你指明改进方向。

技术质量团队

技术质量团队（也叫开发者生产力或开发者工具团队）专门负责创建和维护公司的软件质量，涵盖从构建、测试到接口设计等广泛的工作。

组建这种团队时，建议从 3-6 人的固定规模开始，以保持专注。随着规模扩大，你可以参考规模法则按比例扩充团队（经验法则是：除基础架构工程师外，每 15 名产品工程师配 1 名工具工程师）。

该团队成功的核心原则：

相信指标胜过直觉：质量是个复杂系统，直觉容易欺骗你。指标能让你保持诚实。
保持直觉的新鲜感：脱离一线开发太久，你的直觉会变迟钝。多去业务团队轮岗，多和产品开发者 1V1 交流。
倾听并向用户学习 ：工具的普及率和易用性比单纯的功能强大更重要。隐藏掉偶然复杂性。观察工程师首次使用你工具的过程，修复痛点，重复做十次！不做用户调研的工具团队注定失败。
少做点，但做精：推向全公司的东西，做好了能加速全员，做差了（哪怕只是一点小毛病）会拖累所有人。
不要垄断影响力 ：在中央团队的全局最优（标准化）与特定团队的特殊需求（探索创新）之间寻找平衡。参考探索与标准化的量级。

一个运转良好的质量团队带来的效率提升，远大于让这些人直接去写产品代码。如果你的团队有很多高价值的工作却做不完，也许是时候启动一个质量项目了。

质量项目

质量项目 不是指写代码，而是指一项由专职团队领导的、致力于在全组织内达成特定质量目标的组织倡议（类似事件回顾项目）。

运行大规模项目容易被协调工作压垮，因此你需要找一位技术项目经理（TPM）来共同推进。关于如何运行组织项目的核心步骤如下：

找到项目赞助人 (Sponsor)：没有拥有实权的高层支持，你无法改变组织的习惯。
建立自动化、可持续的指标：纯手工维护数据注定无法长久。
为受影响的团队设定目标并提供实现路径：不能只提要求。作为专家，你要给出具体该怎么做的策略。
提供工具和文档支持：给他们"黄金示例"、自动化重构脚本或验证工具。尽一切可能降低各团队的执行门槛。
建立全员可见的仪表盘：仪表盘要提供三种视角：宏观的总体影响、中观的管理层问责、微观的具体团队下一步任务。
自动化跟进提醒：对于进度落后的团队，发送精准的自动提醒，引导他们完成下一步任务。注意不要滥发打扰。
定期与赞助人对齐状态：如果有些团队以业务繁忙为由拒绝配合，你需要借助赞助人的力量来平衡优先级。

从很多方面来看，质量项目就像是一场无尽的迁移，处理代码迁移的技巧同样适用于项目管理。

谨防失败的三个陷阱：纯流程导向（脱离实际）、纯技术导向（忽视沟通）以及单打独斗。请记住：项目本身不是目标，创造技术质量才是目标。如果一个项目不再产出质量，随时准备关停它。

从小处着手，慢慢增加

当你发现实际技术质量远落后于预期时，最自然的反应是恐慌，并试图立刻铺开所有解决方案。这种"大杂烩"式的做法往往适得其反。

如果遇到质量瓶颈，从一件小事做起，迭代直到它见效，然后再叠加下一个方法。哪怕被指责动作太慢，也要稳扎稳打。在复杂的系统中，盲目求快只是表面功夫，有条不紊的推进才能真正解决问题。

上一章：编写工程战略

图书

如果您喜欢 staffeng.com 上的故事和指南，您可能也会喜欢《Staff Engineer: Leadership beyond the management track》一书，其中收录了许多类似的指南和故事。