Loading... # 为何每隔十年都会出现取代开发者的梦想 # 一、新闻概述 ## 1. 标题 为何每隔十年都会出现取代开发者的梦想：从 COBOL 到 AI 的五十年循环 ## 2. 发布时间 2025 年 12 月 7 日 ## 3. 来源 Caimito Agile Life # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 文章揭示了一个持续 50 年的模式：每隔十年就会出现新的技术承诺要"简化或取代开发人员"，从 COBOL、CASE 工具、Visual Basic 到现在的 AI。 ### B. 核心亮点 - 1969 年阿波罗登月项目开启了软件专业化时代 - COBOL 承诺让业务人员自己写程序，结果却创造了新的专业领域 - CASE 工具、Visual Basic、低代码平台都未能消除对专业开发者的需求 - AI 编码助手是最新的尝试，但仍面临同样的本质问题 ## 2. 关键信息 ### A. 历史跨度 从 1969 年到 2025 年，跨越 56 年的技术演进 ### B. 核心观点 软件开发的根本约束不在于工具或语法，而在于处理复杂性所需的思维能力 ### C. 关键人物 - Margaret Hamilton：阿波罗导航软件负责人 - Stephan Schwab：文章作者 ## 3. 背景介绍 ### A. 阿波罗时代 1969 年，当尼尔·阿姆斯特朗踏上月球表面时，世界见证了人类组织智慧的成就。Margaret Hamilton 和她的团队手写阿波罗导航软件，通过仔细审查发现关键错误，证明了软件可以是任务关键性的。 ### B. 持续的张力 尽管软件能力取得了非凡进步，但需求远远超过创造能力。每个组织需要的软件都超过其构建能力。 # 三、详细报道 ## 1. 历史回顾 ### A. COBOL 时代（1960-1970 年代） COBOL 的名称中明确表达了目标：Common Business-Oriented Language（通用商业导向语言）。愿景很清晰：让语言像英语句子一样可读，业务分析师就能编写自己的程序。 **承诺**：如果我们让语法足够可读，任何了解业务的人都能编写代码。 **现实**：COBOL 成为了另一种需要专业培训的编程语言。业务分析师很快发现，可读的语法并不能消除逻辑、数据结构或系统设计的复杂性。一类新的 COBOL 程序员出现了，而消除专业开发者的梦想仍未实现。 ### B. CASE 工具（1980 年代） 计算机辅助软件工程工具带来了巨大的承诺。绘制流程图和实体关系图，工具就会生成可工作的代码。 **营销信息**：可视化设计比输入神秘的命令更直观。业务专家可以建模他们的流程，软件就会自动实现。 **结果**：大多数 CASE 工具倡议陷入困境或彻底失败。生成的代码通常需要大量人工干预。性能问题出现。当生成的代码与可视化模型 diverged 时，维护成为噩梦。 ### C. Visual Basic 和 Delphi（1990 年代） 微软的 Visual Basic 和 Borland 的 Delphi 使构建用户界面 dramatically 更容易。将组件拖放到表单上，设置属性，编写事件处理器。 **成就**：这波浪潮以不同的方式成功。这些环境承认编程知识仍然是必要的，但降低了入门门槛。 **局限**：随着需求增长复杂性——与现有系统集成、安全考虑、负载下的性能、长期维护——对经验丰富的开发者的需求变得明显。 ### D. Web 框架、低代码、无代码（2000 年代及以后） Ruby on Rails 承诺约定优于配置。低代码平台提供最少编码的可视化开发。无代码平台声称为常见商业应用程序完全消除编程。 **共同特点**：每波浪潮都提供了真正的价值。在特定上下文中，开发确实变得更快。更多人可以参与创建软件解决方案。然而，专业软件开发人员仍然必不可少，对他们的技能的需求继续增长而不是萎缩。 ## 2. 技术演进时序图 ```mermaid timeline title 软件开发工具演进史（1969-2025） 1969 : 阿波罗登月项目<br>手写导航软件 1960s-1970s : COBOL<br>业务导向语言 1980s : CASE 工具<br>可视化建模生成代码 1990s : Visual Basic/Delphi<br>拖拽式界面开发 2000s : Web 框架<br>Ruby on Rails 等 2010s : 低代码/无代码平台<br>可视化业务应用开发 2020s : AI 编码助手<br>自然语言生成代码 ```  ## 3. 核心问题分析 ### A. 复杂性的来源 软件开发看起来应该很简单，因为我们可以用简单的语言描述我们想要什么。 **表面描述**："当客户下订单时，检查库存，计算运费，处理付款，并发送确认电子邮件。"这个描述听起来很简单。 **隐藏的复杂性**： - 当库存被另一个订单临时保留时会发生什么？ - 如何处理部分付款？ - 如果电子邮件服务暂时不可用怎么办？应该重试吗？多少次？ - 如果客户的结账会话过期怎么办？如何防止重复订单？ - 如何处理并发订单？ - 如何确保数据一致性？ 每个答案都会导致更多问题。累积的决策、边缘情况和相互作用创造了真正的复杂性，没有任何工具或语言可以消除。 ### B. 根本约束 软件开发主要不受打字速度或语法知识的约束。它受到良好处理复杂性所需的思维的约束。 **关键洞察**： - 更快的打字对思考如何处理并发数据库更新没有帮助 - 更简单的语法对推理安全含义没有帮助 - 可视化工具不能消除理解逻辑复杂性的需要 # 四、影响分析 ## 1. 对行业的影响 ### A. 持续的需求增长 尽管工具取得了巨大进步，但专业开发人员的需求继续增长。这是因为： 1. **软件吞噬世界**：每个行业都在数字化 2. **复杂性增加**：现代系统需要集成、安全、性能、可扩展性 3. **维护负担**：现有软件需要持续更新和改进 ### B. 工具演进模式 每个新时代的工具都提供了真正的价值，但没有一个能实现最初的承诺。模式一致： 1. **承诺**：这次真的会简化/消除开发工作 2. **现实**：工具在某些上下文中提供帮助 3. **结果**：专业开发者仍然必要，需求继续增长 ## 2. 对企业领导者的影响 ### A. 评估新工具的正确问题 错误的问题："这是否会消除我们对开发者的需求？" 正确的问题： - 这是否帮助我们的开发者更有效地处理复杂问题？ - 这是否使我们能够更快地构建某些类型的解决方案？ - 这是否减少了在重复任务上花费的时间，以便开发者可以专注于独特的挑战？ - 我们的团队是否需要学习新技能才能有效使用它？ ### B. 现实期望管理 理解这种模式有助于你以现实的期望参与新工具。使用 AI 助手。评估低代码平台。试验新框架。但主要投资于你的团队清晰思考复杂性的能力。 ## 3. AI 时代的特殊影响 ### A. AI 编码助手的定位 AI 编码助手代表最有能力的尝试协助软件创建。它们可以： - 从自然语言描述生成大量可工作的代码 - 解释现有代码 - 建议改进 - 帮助调试问题 **真正的进步**：这是真正的进步。帮助是真实和有价值的。经验丰富的开发者使用这些工具更有效地工作。 **持久的约束**：我们已经开始看到熟悉的模式出现。关于 AI 取代开发者的初步兴奋正在让位于更细致的理解：AI 改变了开发者的工作方式，而不是消除他们判断的需要。 ### B. 开发者角色的演变 ```mermaid graph LR A[传统开发者] -->|工具辅助| B[AI 增强开发者] B -->|能力提升| C[架构师/问题解决者] A -.编码.-> D[代码生成] B -.指导审查.-> D C -.设计决策.-> E[系统架构] B -.集成验证.-> E ```  # 五、各方反应 ## 1. 文章核心观点 ### A. 模式揭示问题的本质 这种 50 年的模式教给我们一些关于软件开发本身的基本知识。如果问题主要是机械的——打字太多、语法太复杂、步骤太多——我们到现在应该已经解决了它。 **已解决的部分**： - COBOL 使语法可读 - CASE 工具消除了打字 - 可视化工具消除了语法 - AI 现在可以从描述生成整个函数 **持久的挑战**：基本挑战持续存在，因为它不是机械的，而是智力的。软件开发是使思维有形化。我们创建的制品——无论是 COBOL 程序、Delphi 表单还是 Python 脚本——都是关于复杂性的无形推理的可见结果。 ### B. 梦想的价值 也许取代开发者的循环梦想不是一个错误。也许它是推动工具创造的必要乐观主义。 **每次尝试的价值**： - COBOL：让一代开发者能够有效地构建业务系统 - CASE 工具：推进了我们对可视化建模的思考 - Visual Basic：将应用开发带给更多人 - AI：将改变我们的工作方式 ## 2. 行业观察 ### A. 工具与人类思维的关系 你不能缩短那种推理，就像你不能缩短设计建筑或诊断医疗状况所需的推理一样。更好的工具有帮助。经验有帮助。但仍有人需要仔细思考。 ### B. 关键结论 ```mermaid graph TD A[软件需求] -->|超过| B[开发能力] B -->|创造| C[新工具承诺] C -->|提供| D[部分解决方案] D -->|改善| E[开发效率] E -->|但未消除| F[复杂性约束] F -->|继续需要| G[专业开发者] G -->|推动| A ```  # 六、技术趋势展望 ## 1. 未来的发展方向 ### A. AI 的真正价值 AI 将改变开发者工作的方式，而不是取代他们。真正的价值在于： 1. **效率提升**：自动化重复性任务 2. **学习加速**：交互式指导帮助新手 3. **代码审查**：发现潜在问题 4. **文档生成**：自动创建说明文档 ### B. 开发者的核心能力 未来的开发者需要更专注于： 1. **问题域理解**：深入理解业务问题 2. **系统设计**：架构和集成能力 3. **安全考虑**：识别和缓解安全风险 4. **性能优化**：在复杂场景下保证性能 5. **维护策略**：长期可维护性设计 ## 2. 对组织的建议 ### A. 投资重点 主要投资于你团队清晰思考复杂性的能力。这种能力仍然是约束因素，就像在阿波罗计划期间一样。 ### B. 工具采用策略 使用新工具，但要有清晰的期望： - 工具可以帮助，但不能替代判断 - 工具可以提高效率，但不能消除复杂性 - 工具可以扩大参与范围，但不能消除专业知识 # 七、经验总结 ## 1. 模式的启示 这个 50 年的模式告诉我们： 1. **软件开发本质上是智力活动**：不是机械打字或语法问题 2. **复杂性是根本约束**：工具可以辅助但不能消除 3. **每次尝试都有价值**：即使未实现最初承诺，也推动了进步 ## 2. 对未来的启示 下一波开发工具将会到来。一些将提供真正的价值。一些将以新技术重复熟悉的承诺。 ** productive 参与新工具的方式**： - 保持对模式的视角 - 评估真正的价值，而不是营销承诺 - 投资于人的能力 - 接受复杂性是固有的 ## 3. 最终思考 阿波罗登月发生是因为聪明的人仔细思考了一个非凡复杂挑战的每一个细节。他们手写软件是因为那是可用的工具。如果他们有更好的工具，他们会很乐意使用它们。但工具不会消除他们仔细思考复杂性的需要。 我们仍然处于同样的基本情况下。我们有更好的工具—— vastly 更好的工具——但思维仍然是必不可少的。 *** ## 参考资料 1. [Why We've Tried to Replace Developers Every Decade Since 1969](https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html) 最后修改：2026 年 01 月 18 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏