30 秒看懂
Titus Winters 讨论 Google 的 C++ 重构和可读性审查、心理安全的价值、生产力指标的局限以及计算机教育的建议。他对 AI 和未来课程的观点是供讨论的主张,并非普适处方。
- 1测试文化测试可以使共享代码更易于安全修改,也让发布更可靠。
- 2大规模重构理解编译器的转换支持了大规模 C++ 迁移。
- 3可读性与指导可读性审查逐渐成为指导工程师和分享实践的方式。
- 4团队与安全感信任与学习帮助团队讨论错误并培养能力。
- 5衡量影响AI 可能改变可行的工作,而吞吐量指标会遗漏这种变化。
- 6教育Winters 主张教育更加重视规格、验证和实践经验。
要点建议
- 测试可以使共享代码更易于安全修改,也让发布更可靠。
- 理解编译器的转换支持了大规模 C++ 迁移。
- 可读性审查逐渐成为指导工程师和分享实践的方式。
- 信任与学习帮助团队讨论错误并培养能力。
- AI 可能改变可行的工作,而吞吐量指标会遗漏这种变化。
- Winters 主张教育更加重视规格、验证和实践经验。
按章节阅读整理后的全文
早期经历与测试
Winters 回顾 Google 及其测试文化。
Gergely Orosz 与 Titus Winters 讨论 Google 的软件工程、大规模 C++ 重构、团队文化、开发者生产力与计算机科学教育。Winters 关于 AI 和课程的评论是他的观点和预测。
Winters 介绍自己在计算机科学教育方面的背景,以及从咨询工作进入 Google 的经历。他对开发者效率、API 设计和底层系统感兴趣。
他在 Google 的最初岗位并不完全合适,但后来转向 C++ 基础设施。对话强调了找到能让工程师优势与工作匹配的团队的重要性。
Winters 回忆,在频繁发布困难时,发布工程师坚持要求代码变更配有测试。测试让修改共享代码更安全,也帮助团队更有信心地推进;这个故事描述的是特定历史背景。
新工程师可能因为系统脆弱或入职培训与指导不足而害怕破坏生产环境。Winters 说,教育可能强化一种错误期待:每个工程问题只有一个正确答案,而不是需要权衡。
大规模 C++ 重构
团队使用理解编译器的工具修改大型代码库。
他讨论 Abseil 以及在不同环境之间共享基础 C++ 组件的需求。让内部工具和接口可以在其他地方使用,会带来依赖和兼容性问题。
团队面临大规模重构;Winters 估计涉及约 2 亿至 2.5 亿行自有 C++ 代码,且许多工程师同时修改代码。他把任务比作在建筑仍然开放时更换地基。
仅靠文本搜索不足以安全识别所有相关调用。团队利用理解编译器的抽象语法树转换,根据代码结构匹配并生成修改。
格式化生成的修改是一个实际障碍。Winters 将自动 C++ 格式化工具的需求与这项工作联系起来;在代码库持续变化时,团队还必须把修改分成可管理的批次。
他认为保持代码一致能改善后续工程师复制的示例。持续清理能力可以使现有代码库成为更可信的模式来源,但复制的代码仍需要审查。
两人比较确定性的重构工具与 AI 辅助重写。基于编译器的转换可以对明确修改提供精确匹配,而 AI 可以帮助生成工具或处理更难形式化的情况。
他们讨论用 AI 找到反复出现的审查问题,然后把检查编码为可重复执行的 lint 规则。这可能降低重复推理成本,让既定规则更一致,但前提是规则本身正确。
可读性与团队
指导与心理安全支持共同工作。
Winters 解释《Software Engineering at Google》的由来:反复遇到大规模设计和维护问题的工程师与领域专家共同整理经验。这本书描述的是特定时期的实践,并非适用于所有组织的永久规则。
Google 的可读性审查将代码所有者批准与特定语言的专业能力结合。Winters 说,这一过程逐渐从一次性展示演变为围绕日常修改进行的指导。
导师在团队自身审查之后检查修改,对符合语言习惯和一致性的代码给出反馈。工程师可以逐步取得认证并最终指导他人;这一过程也促进跨团队知识传播。
被问到强大的 AI 工具是否降低团队的重要性时,Winters 说协调与清晰沟通仍然重要。即便工程师指挥代理,也必须明确工作、审查结果并与人协作。
他将高效团队与信息共享及学习许可联系起来。心理安全让人更容易承认不确定性、讨论错误并改进系统,而不是掩盖问题。
对于持续合作的团队,让有指导的初级工程师承担合适任务可以培养未来能力。Winters 将此与只为单个项目选择眼下最快的个人进行对比。
两人讨论绩效压力和内部竞争如何抑制知识共享。Winters 认为,当人们相信团队成功也能支持个人成功时,他们更可能投入彼此的成长。
他描述裁员带来的压力和注意力损失,包括花时间支持同事并为不确定性做准备。这是对组织成本的定性描述,并非量化的因果估计。
生产力与 AI
两人讨论指标与可能性变化。
谈到开发者生产力,Winters 介绍了结合发布、测试和变更等多个指标,而不是把一个数字当成全部情况。任何综合指标都取决于输入、权重和背景,也可能被误用。
他区分更快完成相同工作与改变哪些工作变得可行。AI 可能让团队尝试此前在经济上不可行的项目;仅看吞吐量指标可能遗漏这种变化的价值。
主持人分享一个团队利用规格和测试配合 AI 替换昂贵组件的例子。这个故事说明经济性可能变化,但不保证未经审查的重写安全或正确。
教育与进入行业
Winters 提出课程与评估的改变。
Winters 参与过专业学会的课程制定工作,认为本科计算机科学的许多内容变化太慢。他追问保留某些主题是因为它们不可或缺,还是出于传统或因为容易教授。
他建议更加重视设计、精确规格、测试和验证,以及团队合作与沟通。他对学位招生变化的预测属于推测;理论与实践的适当平衡仍可讨论。
两人将学位项目与密集实践培训和合作实习作比较。真实经验可以帮助学生学习版本控制、代码审查和与他人协作,同时基础理论也可能有价值。
Winters 建议初级工程师用 AI 扩展理解,而不是直接把工单粘贴进提示词后提交输出。即使工具生成代码,人仍需负责明确需求并验证工作。
他质疑在教育中完全禁止 AI 的做法,同时承认学生可能绕过学习过程。挑战在于设计能揭示理解程度的评估,而不只是检查最终产物是否存在。
可能的方法包括口头解释、结对工作和评估得出答案的过程。两人承认教育工作者仍在试验,并不存在已经确定的方法手册。
Winters 设想一门入门课,先学习清楚表达接口、输入和输出,再集中于实现。他希望学生学会如何让工具产出符合实际目的的成果。
对于进入这一领域的人,他建议追求真正感兴趣的方向并积累有特色的作品,而不是追逐每个热门话题。主持人最后回顾确定性工具,以及改变团队能够构建什么的价值。
同频道的其他文章
1:56:28EN → 简体中文
1:34:17EN → 简体中文
1:59:04EN → 简体中文
29:39EN → 简体中文
1:42:31EN → 简体中文
1:28:32EN → 简体中文