软件工程 - Tony Bai

本文永久链接 – https://tonybai.com/2025/09/14/code-complete-with-steve-mcconnell

大家好，我是Tony Bai。

二十年前，Steve McConnell 的《代码大全》(Code Complete 2nd) 以其近 900 页的体量，成为软件工程领域一座难以逾越的丰碑。二十年后，它依然是无数工程师书架上的必备经典。在一场深度的访谈(https://www.youtube.com/watch?v=iPKmcLxuS_A)中，McConnell分享了这部巨著背后的故事、对职业发展的深刻洞见，以及对 AI 时代的冷静思考。

尽管技术浪潮已更迭数代，但 McConnell 的核心思想依然闪耀着永恒的光芒。我从中提炼出三大“启示”，它们穿越了语言和工具的变迁，直指软件开发的本质，为每一位追求卓越的工程师提供了清晰的行动指南。

启示一：“软件构建”远不止编码，它是专业性的基石

访谈中，McConnell 反复强调一个核心概念：他所著述的领域是“软件构建” (Software Construction)，而这远不止我们通常理解的“编码” (Coding)。这是一个至关重要的区分，是从业余爱好者迈向专业工程师的第一道分水岭。

软件构建是一个广阔的领域，它涵盖了详细设计、编码、调试、测试集成、可读性与长期维护等一系列与代码紧密相关的活动。

在 McConnell 看来，只关注“编码”的工程师，如同只知道砌砖的建筑工人；而懂得“软件构建”的工程师，则是在思考整面墙的结构、承重与美学。

这意味着，在你编写每一行代码之前和之后，都需要思考：

设计：这个函数或类的内部结构是否清晰、易于理解？
验证：我将如何测试这段代码，以确保它的正确性？
可读性：几个月后，我自己或同事还能轻松读懂这段代码吗？
维护性：我的实现是否为未来的修改和扩展留下了空间？

这个启示提醒我们，卓越的软件并非代码的堆砌，而是深思熟虑的“构建”过程的产物。

启示二：战略性构建你的生涯，而非随机“跳荷叶”

在访谈最发人深省的部分，McConnell 分享了他对抗职业生涯随机性的强大心智模型：“职业金字塔” (Career Pyramid) vs. “跳荷叶” (Lily Pad Hopping)。

“跳荷叶”：工程师们从一个项目跳到另一个项目，看似在不断学习新技术、接触新业务，但这些经历是零散的、不连贯的。年复一年，知识面变广了，但核心价值并未实现质的飞跃，因为这些努力“没有累积成任何东西”。
“职业金字塔”：这是一种战略性思维。将职业生涯视为一座需要亲手建造的金字塔，每一次选择——无论是学习一门技术，还是参与一个项目——都是在为这座金字塔添砖加瓦。所有努力都服务于一个长远目标，层层叠加，最终形成一个深厚、独特且极具价值的能力体系。

这个启示提醒我们要时常自省，有意识地规划你的成长路径，让每一次努力都成为你“职业金字塔”的一部分。

我当前的工作，是在随机跳向下一片看似新奇的荷叶，还是在为我的金字塔奠定坚实的基础？
我应该学习什么，才能让我的能力体系更加稳固和高耸？
McConnell 给出了一个终极评判标准：“这个选择，能让我对我的组织或整个世界变得更有价值吗？”

启示三：AI 时代，工程师的终极价值是追求“完全正确”

面对 AI 能快速生成代码的现实，McConnell 并未表现出焦虑，反而给出了一个极其深刻的洞见，精准地定义了人类工程师在未来的核心价值。

他引用了 Fred Brooks 的“本质复杂性” (Essential Complexity) 概念，指出软件工程的真正挑战，在于处理由真实世界的混乱所带来的无数异常和边界情况。

“编程，我们不能做到‘近似正确’ (approximately right)，我们必须做到‘完全正确’ (exactly right)。”

AI 或许能高效地处理“近似正确”的部分——即生成“快乐路径” (Happy Path) 的代码。但这恰恰凸显了人类工程师的价值。

这意味着工程师的角色正在演进，目标是成为“完全正确”的最终守护者，具体来说，我们要：

从代码的创作者，到质量的审查者：我们的核心职责，是审查 AI 生成的代码，并用我们的经验和洞察力，去发现并修复其中所有微妙的、潜在的错误。
从执行者，到需求的诠释者：将模糊的业务需求，转化为精确、无歧义、能够指导 AI 的技术规格，这本身就是一种不可替代的高级智力活动。
从实现细节，到系统思考：将精力更多地投入到更高层次的“构建”活动中——架构设计、模块划分、API 契约定义，以及对系统长期健康度的深思熟虑。

小结

McConnell 的访谈如同一座灯塔，为在技术浪潮中航行的我们指明了方向。这三大启示——将编码提升为构建，将工作升华为事业，将价值定位于正确。无论工具如何演变，对质量的追求、对成长的规划、对责任的担当，将永远是定义一位卓越工程师的真正标尺。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/06/26/non-deterministic-abstraction

大家好，我是Tony Bai。

在软件开发领域，Martin Fowler 的名字几乎等同于思想的灯塔。他的每一篇文章、每一次演讲，都能为我们揭示行业发展的深层脉络。最近，Fowler 大师又发布了一篇简短但引人深思的博文——《LLMs bring new nature of abstraction》，再次精准地捕捉到了一个正在发生的、可能颠覆我们认知和工作方式的巨大变革。

Fowler 认为，大型语言模型（LLM）的出现，对软件开发的影响，堪比从汇编语言到首批高级编程语言（HLLs）的飞跃。但关键在于，LLM 带来的不仅仅是又一个“更高层次”的抽象，它正在从根本上改变编程的“本质”——迫使我们思考，用“非确定性工具”进行编程究竟意味着什么。

在这篇文章中，我们就来简单解读一下。

从“确定性”的阶梯到“非确定性”的岔路

回顾编程语言的发展史，我们一直在追求更高层次的抽象，以提升生产力、降低复杂度：

汇编语言 vs. 机器指令： 汇编让我们用助记符替代了 0 和 1，但仍需关注特定机器的寄存器和指令集。
高级语言 (HLLs) vs. 汇编： Fortran、COBOL 等早期 HLLs 让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。Fowler 回忆道，他用 Fortran IV 编程时，虽然有诸多限制（如 IF 没有 ELSE，整数变量名必须以 I-N 开头），但这已经是巨大的进步。
现代语言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等现代语言，以及各种框架和领域特定语言（DSL），进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递，使用丰富的库和模式，而不用从头编写大量底层代码。

Fowler 指出，尽管这些发展极大地提升了抽象层次和生产力，但它们并没有从根本上改变“编程的性质”。我们仍然是在与机器进行一种“确定性”的对话：给定相同的输入和代码，我们期望得到相同的输出。错误（Bug）也是可复现的。

然而，LLM 的介入，打破了这一基本假设。

Fowler 写道：“用提示词与机器对话，其差异之大，犹如 Ruby 之于 Fortran，Fortran 之于汇编”。

更重要的是，这不仅仅是抽象层次的巨大飞跃。当 Fowler 用 Fortran 写一个函数，他可以编译一百次，结果中的 Bug 依然是那个 Bug。但 LLM 引入的是一种“非确定性”的抽象 (non-deterministic abstraction)。

这意味着，即使我们把精心设计的 Prompt 存储在 Git 中，也不能保证每次运行都会得到完全相同的行为。正如他的同事 Birgitta Böckeler 精辟总结的那样：

我们并非仅仅在抽象层级上“向上”移动，我们同时也在“横向”移入非确定性的领域。

Fowler 文章中的配图非常形象地展示了这一点：传统的编程语言、编译器、字节码是一条清晰的、自上而下的抽象路径；而模型/DSL、代码生成器、低代码、框架是其上的不同抽象层次。自然语言（通过 LLM）则像一条从旁边切入的、直接通往“半结构化/接近人类思维”的道路，这条路本身就带有模糊和不确定性。

“非确定性”编程时代的挑战与启示

这种“非确定性”的本质，对我们 Gopher，乃至所有软件开发者，都带来了前所未有的挑战和需要重新思考的问题：

版本控制与可复现性： 当 Prompt 不能保证结果一致时，我们如何管理和版本化我们的“AI辅助代码”？如何确保开发、测试、生产环境的一致性，或者至少是可接受的差异性？仅仅版本化 Prompt 可能不够，我们还需要版本化模型、参数（如 temperature）甚至是一些关键的种子（seed）吗？
测试与调试： 如何测试一个输出不完全固定的“组件”？传统的单元测试、集成测试方法是否依然有效？我们可能需要引入新的测试策略，例如基于属性的测试、对输出结果的统计验证、或者更侧重于行为和意图的验证。当 LLM 生成的代码出现问题，调试的难度是否会指数级增加？
可靠性与契约： 在一个包含非确定性AI组件的系统中，如何定义和保证整体的可靠性？服务间的“契约”又该如何描述和强制执行？
思维模式的转变： 我们习惯了对代码的精确控制，追求逻辑的严密和行为的可预测。现在，我们可能需要学会与“模糊”和“概率”共存，从“指令下达者”转变为“意图沟通者”和“结果筛选者”。

这对我们 Gopher 意味着什么？

Go 语言以其明确性、强类型、简洁的并发模型以及相对可预测的行为，深受开发者喜爱。当我们尝试将 LLM 融入 Go 的生态和开发流程时，这些“非确定性”的特性会带来新的思考：

AI 生成 Go 代码： 当我们使用 LLM 生成 Go 代码片段、单元测试，甚至整个模块时，如何确保生成的代码符合 Go 的最佳实践、是高效且安全的？如何对生成的代码进行有效的审查和集成？
用 Go 构建与 LLM 交互的工具/Agent： 如果我们用 Go 开发与 LLM 交互的后端服务或智能体（Agent），我们需要在架构设计上充分考虑 LLM 的非确定性，设计更鲁棒的错误处理、重试机制，以及对 LLM 输出结果的验证和筛选逻辑。
利用 LLM 理解复杂 Go 系统： LLM 或许能帮助我们理解遗留的复杂 Go 代码库，但其解释的准确性和一致性也需要我们审慎评估。

Fowler 在文末表达了他对这一变革的兴奋之情：“这种改变是戏剧性的，也让我颇为兴奋。我相信我会为一些失去的东西感到悲伤，但我们也将获得一些我们中很少有人能理解的东西。”