纯粹与非纯粹软件工程

软件工程领域存在两种截然不同的工作模式：一种是追求技术完美与艺术性的“纯粹工程”，另一种是注重高效解决现实问题的“非纯粹工程”。随着市场环境从资本驱动转向盈利驱动，后者的重要性日益凸显。这两种工程师因工作性质、所需技能和思维方式的差异而时常产生冲突，其中，非纯粹工程在复杂组织内落地的难度常常被低估。此外，人工智能辅助开发对处理常见问题的非纯粹工程助益更大，而对探索未知领域的纯粹工程则作用有限。

两种软件工程：纯粹与非纯粹

软件开发的工作可以分为两种截然不同的类型。

• 纯粹工程 (Pure Engineering): 目标是尽可能 完美地 解决一个技术问题。它更接近艺术或研究，由工程师自身的审美和探索欲驱动。

  • 例子: 编写一个理想的开源库，或打造心目中最完美的个人游戏引擎。
  • 特点: 过程开放，可以无休止地打磨和优化，追求技术上的极致。

• 非纯粹工程 (Impure Engineering): 目标是尽可能 高效地 解决一个现实世界的问题。它更像是管道维修或建筑施工，服务于他人的需求。

  • 例子: 在公司里按时交付一个项目或某个新功能。
  • 特点: 必须服从于外部需求（通常是雇主），并且有明确的 截止日期，这意味着 妥协 是工作的一部分。

时代变了：纯粹工程的重要性正在下降

在资金充裕、追求炒作的 2010 年代，大型科技公司有能力资助大量的纯粹工程项目。这既能产出亮眼的开源成果来吸引人才（一种 变相的开发者营销），也能为过剩的工程师提供看似有用的工作。

然而，如今的科技公司必须关注 盈利。随着招聘放缓和预算收紧，许多纯粹工程岗位被削减。一些纯粹工程师感到工作突然变得“政治化”，但根本原因在于，他们之前所扮演的、由市场泡沫支撑的角色，在当前环境下已不再被需要。

为什么两种工程师都不可或缺

科技公司既需要纯粹工程，也需要非纯粹工程，但需求量并不对等。

• 纯粹工程 对于构建解决特定技术难题的核心组件至关重要，例如数据库、编程语言或公司内部高度定制化的工具。

• 非纯粹工程 则是公司业务的基石。几乎所有商业行为都依赖于尽快交付新功能或新产品的能力。

几乎所有科技公司的决策都是数十甚至数百人之间妥协的结果。能够满足这些需求的，正是乐于从事非纯粹工作的工程师。

在实践中，专注于纯粹工作的工程师往往难以胜任非纯粹工作，他们 不擅长妥协、害怕截止日期。反之，习惯了非纯粹工作的工程师在面对纯粹工作时，则可能因为 过于务实 而缺乏追求最优解的耐心和技术深度。

非纯粹工程的真正价值

有人可能会认为，纯粹工程技术更难，因此这只是“能干”与“不能干”的区别。这种看法是错误的。这更像是物理学和数学，它们是 需要不同技能组合的不同领域。

纯粹工程师常常低估了做好非纯粹工程的难度。

• 纯粹工程 是你与技术难题的 一对一对决。
• 非纯粹工程 则是一场 混战：你不仅要面对技术问题，还要对抗遗留代码、相互冲突的政治观点、团队共识，以及大量因满足商业需求而累积的附带复杂性。

有些功能虽然会拖累后续的每一次开发，但却能提供巨大的商业价值。这就是非纯粹工程的现实。

这就是为什么在大型科技公司中，能够有效完成非纯粹工程的工程师能获得高薪的原因。

AI 对谁的帮助更大？

对于 AI 辅助编程工具（如 LLMs）的态度差异，也体现了这两种工程的区别。

• 纯粹工程师普遍持否定态度。他们处理的问题通常非常新颖，个人专业知识远超 AI 模型，因此觉得 AI 生成的代码是“垃圾”。

• 非纯粹工程师则发现 AI 能显著提升效率。他们面对的问题对自己来说可能是新的，但通常 在行业内并非全新问题。在紧迫的期限下，AI 可以作为一个“更聪明”的伙伴，提供快速的建议和代码审查。

对于纯粹工程师来说，他们尝试使用 LLM 时总是觉得毫无帮助。但这可能反映了一种视野的局限性，因为他们没有站在非纯粹工程的场景下思考。

最后的思考

纯粹工程的困难和价值是公认的，我们日常使用的编程语言、框架和数据库都依赖于它。

然而，非纯粹工程同样是 困难且有价值的。大型科技公司早已通过招聘策略和薪酬结构证明了这一点。但在工程师的圈子里，人们谈论“工程”时，有时会下意识地认为只有纯粹工程才是真正的工程，而忽略了在现实世界中创造价值的另一半。