Transcription
在技术领域，您看到了哪些可以与人工智能在某种程度上相媲美的类似变化？>> 我认为这是我职业生涯中最大的变化。我认为，如果我们回顾一下整个软件开发的历程，可与之相比的事情将是从汇编语言到第一批高级语言的转变。其中最大的部分是从确定性到非确定性的转变，突然之间，您在一个非确定性的环境中工作，这完全改变了。>> 您对“氛围编码”的理解和看法是什么？我认为它适合探索。它适合一次性的、可丢弃的东西，但您不希望将其用于任何具有长期能力的用途。当您使用“氛围编码”时，您实际上是在移除某物中一个非常重要的部分，那就是学习循环。您观察到了一些新的工作流程或新的软件工程方法吗？一个非常有趣的领域是马丁·福勒（Martin Fowler），他是一位在敏捷、软件架构和重构等领域极具影响力的作家和软件工程师。[音乐] 他是 2001 年敏捷宣言的作者之一，是畅销书《重构》的作者，[音乐] 并且在他的博客上定期发布关于软件工程的文章。在本期节目中，我们讨论了人工智能如何改变软件工程，[音乐] 以及大型语言模型（LLM）实现的一些有趣且新的软件工程方法，为什么重构作为一种实践[音乐]可能会随着人工智能编码工具的出现而变得更加相关，为什么设计模式在过去十年似乎已经过时，人工智能对敏捷实践的影响，以及[音乐]更多。本播客节目由 Statsig 提供，这是一个统一的平台，用于标志、[音乐]分析、实验等。请查看节目笔记，了解更多关于他们和我们其他季度的赞助商的信息。如果您喜欢这个节目，请在任何播客平台和 YouTube 上订阅该播客。那么，马丁，欢迎来到播客。>> 非常感谢您的邀请。我没想到会真的与您面对面交流。这相当不错。>> 这样更好。我想先了解一下您是如何进入软件开发的，那大概是 40 年前。>> 是的。那是在 70 年代末 80 年代初。是的。就像许多事情一样，这真的有点偶然。在学校，我显然不擅长写作，因为任何与写作有关的事情我都会得到糟糕的分数。>> 真的吗？>> 是的。哦，绝对。但是我在数学和物理方面相当不错。所以我倾向于工程方面的东西，我对电子产品很感兴趣，因为另一件事是我动手能力很差。我无法做任何需要力量或身体协调的事情。所以，各种工程和建造领域，你知道，我曾试图修理我的汽车，你知道，我甚至无法拧下生锈的螺母。你知道，我太糟糕了。但是电子产品还可以，因为那更多的是在脑子里，你知道，你需要能够操作烙铁，但那是我需要做的最多。然后是计算机，这很容易。我甚至不需要烙铁。所以，我就是这样不知不觉地进入了计算机领域。这就是我进入软件开发的途径。在我上大学之前，我在英国原子能管理局工作了一年。哇。或者我们称之为 UKAEA。我用 fortran 4 做了一些编程，这似乎是一件好事。然后在我完成学位后，我的学位是电子工程和计算机科学的混合，我环顾四周，我想，好吧，我可以去从事传统的工程工作，那些工作薪水不高，地位也不高，或者我可以去从事计算领域，那里似乎有更多的机会。所以，我就这样不知不觉地进入了计算领域。而这发生在我上网之前。>> 当时有哪些工作可以让你进入？你的第一份工作是什么？>> 嗯，我的第一份工作是在一家咨询公司 Koopers and Lybrand，或者我称之为 Cheetum and Lightum，我们当时提供信息策略方面的建议，我所在的那个小组虽然不是我的工作。我的工作是我为数不多的懂 Unix 的人之一，因为我在大学学过 Unix，所以我负责管理他们需要运行的那些奇怪软件的一堆工作站，以帮助他们完成策略工作，然后我对他们正在做的策略工作产生了兴趣，并不知不觉地进入了那个领域。我现在回头看，觉得当时有很多骗人的东西。但嘿，这是我进入这个行业的途径，并且让我很早就接触到了面向对象思维的世界，这在 80 年代中期进入对象领域非常有益。>> 您当时在一家咨询公司工作，这似乎不是最前沿的。那么，您是如何接触到面向对象的呢？那在当时，我们可能说的是 80 年代中期，那是一件非常激进的事情。那么，您是如何接触到前沿事物的呢？>> 因为这个小团队热衷于前沿事物，他们遇到了一位有一些有趣想法的人，一些非常好的想法，也有一些有点疯狂的想法。他把它包装成“面向对象”这个术语，虽然实际上并非如此，但它就像是骗人的东西的一部分。我的意思是，称之为骗人的东西有点残忍，因为他也有一些非常好的想法。但那让我朝着那个方向发展，当然，随着时间的推移，我更多地了解了面向对象到底是什么，而这些事件导致了我的整个职业生涯。在接下来的 10 到 15 年里，您是如何发展的，最终加入了 ThoughtWorks，并且您也开始写一些书，开始在业余时间发表文章。您是如何从一个刚进入行业、眼界开阔、只是吸收一切、学习东西的人，慢慢变成一个教导他人的人的？>> 嗯，这里又是一堆偶然。所以，在我还在那家咨询公司工作时，我遇到了另一位他们请来帮助他们在这个领域工作的美国人，他成为了我早期职业生涯中最重要的导师和影响者。他叫吉姆·奥德尔（Jim Odell），他早期就采用了信息工程，并在该领域工作过。他看到了这些人的想法中的优点，他是一位独立的顾问和教师，所以他花了很多时间在这方面工作。大约两年后，我离开了 Coopers and Lybrand，加入了这家名为 PEK 的疯狂公司。我在那里待了几年。那是一家小公司。英国办公室总共只有四个人，那是公司最大的办公室。>> 哇。[笑声] 这样的。嗯，我看到了，你知道，在看到一家大公司的疯狂之后，我又看到了一个小公司的疯狂。做了几年，然后我就能够独立了，我做到了，吉姆·奥德尔（Jim Odell）的帮助很大，他基本上给了我很多工作，还有我在英国获得的一些其他工作，那很棒。我记得离开 PEK 时，我想，就这样了，独立生活对我来说，我再也不会为公司工作了。>> 著名的最后一句。>> 没错。然后我继续。我在 90 年代作为一名独立顾问做得很好，在此期间我写了我的第一本书。我于 93 年搬到美国，我过得非常非常开心，显然互联网的兴起，90 年代末有很多事情发生。那是一个好时机，我遇到了这家名为 ThoughtWorks 的公司，他们只是一个客户。我只是去那里帮助他们。是的。故事还在继续。我曾遇到过肯特·贝克（Kent Beck），并在克莱斯勒著名的 C3 项目中与肯特一起工作，该项目是极限编程的诞生地。所以我曾参与过那个项目，>> 看过极限编程，看过敏捷的东西。所以，我有了面向对象的东西，有了敏捷的东西，然后我来到了 ThoughtWorks，他们正在处理一个大项目，当时对他们来说是一个大项目。仍然相当可观，大约有 100 人参与该项目。所以，这是一项相当大的工作，而且它显然会失败。但是，我能够帮助他们看到发生了什么以及如何避免失败，他们想出了如何从问题中恢复过来。但是，他们邀请我加入，我想，嘿，你知道，再加入一家公司，也许几年吧。他们是很好的人，他们是我最喜欢的客户。你知道，我一直认为其他客户会说，“这些都是很好的想法，但很难实现。”而 ThoughtWorks 会说，“这些都是很好的想法。很难实现，但我们会试试。”而且他们通常都能做到。所以我想，“嘿，有这样的客户，我不如加入他们一段时间，看看我们能做什么。”那已经是 25 年前了。>> 是的。然后快进到今天，我认为您的头衔已经超过十年了，首席科学家。>> 自我加入以来，那就是我的头衔。>> 自您加入以来。所以，我必须问，ThoughtWorks 的首席科学家做什么？>> 嗯，重要的是要记住，我不是任何人的首席，我也不做任何科学研究。[笑声] 之所以赋予这个头衔，是因为当时这个头衔被广泛用于一些面向公众的、有想法的人。如果我没记错的话，当时 Grady Booch 是 Rational 的首席科学家。>> 实际上。没错。>> 还有其他人也拥有这个头衔。所以，这是一个非常宏大且自命不凡的头衔，但他们认为这是必要的。这很奇怪，因为当时 ThoughtWorks 的一件事情是你可以选择自己的头衔。任何人都可以选择自己喜欢的任何头衔。但我不能选择我的，我必须接受首席科学家的头衔。他们不喜欢“旗杆”或“撞锤”之类的头衔，或者[笑声]“大嘴巴”，这是我最喜欢的。ThoughtWorks 每六个月会发布一次 ThoughtWorks Radar，最新的刚刚发布。>> 而最新的雷达，我记得是几天前发布的。>> 我认为今天发布了。所以，到这个节目播出时，已经过去几周了，但>> 实际上是今天。所以，我刚刚看了它，它列出了一些东西。我只列举一些我看到的东西，比如采用（adopting），也就是他们推荐使用的预提交钩子（pre-commit hooks），ClickHouse 用于数据库分析，vlm，这是用于在云端或本地以非常有效的方式学习 LLM，用于试用云代码（cloud code fast），MCP，这是一个用于 MCB 服务器的 MC 框架，他们还推荐了许多与人工智能和 LLM 相关的不同内容，例如用于评估。您能否稍微分享一下 ThoughtWorks 是如何制定这个技术雷达的，流程是怎样的？它感觉非常非常贴近行业脉搏，再次强调，我与许多其他人交谈过。ThoughtWorks 的人们如何与行业保持如此紧密的联系？>> 好的。是的。嗯，这会是一个故事。好的。它始于十多年前。它的起源是我们一直在 ThoughtWorks 极力推动的一件事，即让技术人员，真正的实践者参与到公司运营的各个层面，而其中一位领导者是我们前首席技术官丽贝卡·帕森斯（Rebecca Parsons）。所以，丽贝卡成为了首席技术官，她说我想要一个咨询委员会，让他们与项目中的情况保持联系。所以，她创建了这个技术咨询委员会，里面有一群人，他们的工作是向她汇报情况。我们每年会面两三次。她让我加入了咨询委员会，原因并非如此，而是因为我一直是公司的公众形象。她希望我参与其中。最初，我们的职责就是这样。我们只是聚在一起，讨论这些事情。然后，在一次会议上，达里尔·史密斯（Daryl Smith），当时是她的技术助理，他说，我们有很多项目在进行，最好能了解我们正在使用哪些技术以及它们有多有用，以便更好地交流想法，因为我们像许多公司一样，很难将好的想法传播出去，即使当时我们只有几千人，也很困难，现在我们有 10,000 人了。所以，我们想，好的，这是一个好主意，他提出了雷达的比喻以及我们今天看到的雷达的各个环。我们开了一个小会，创建了雷达。如果我们为内部目的做某事，我们就会尝试公开它。>> 这一直是 ThoughtWorks 的一个重要理念，当然这也是我在这里的原因，你知道，我们只是谈论我们所做的一切，我们分享一切，我们一直都在分享我们的秘密武器。所以，我们这样做了，人们非常感兴趣，所以我们继续这样做。现在，流程随着时间的推移发生了一些变化。在最初的会议上，在场的大多数人实际上都在项目一线工作，一直为客户提供咨询。现在，随着我们规模扩大了十倍，这样做要困难得多。我们也创建了更多的流程，人们可以提交“blips”（雷达上的点），提名它们。“blip”是指雷达上的一个点，一个条目。>> 然后他们会去找一个与他们有地理联系或业务线或技术联系的人，说，“嘿，我们认为这项技术很有趣。”他们会向我们简要介绍一下。然后他们会向现在称为“多普勒小组”（Doppler group）的成员简要介绍，因为我们制作雷达。是的。我的意思是，我们有时对我们的比喻会有点随意。然后，在会议上，我们会决定将哪些“blips”放入雷达，哪些不放。显然，会有一些交叉授粉，因为有人会说，“哦，是的，我也和别人谈过这个。”所以，这非常像一个自下而上的练习，这就是它现在创建的方式。所以，我们会进行“blip”收集会议，大约在雷达会议前一两个月，然后逐渐筛选它们，然后在会议本身上，我们逐一讨论它们。对我来说，这有点奇怪，因为我如今已经脱离了日常工作，这只是一系列技术和事物，我不知道其中大部分是什么，但听起来很有趣，有时我会抓住某些主题。大约十年前，微服务就是一个重要的部分，因为它通过那个雷达过程出现了，然后我们与詹姆斯·刘易斯（James Lewis）一起写了更多关于它的内容。但这确实是我们通过这个过程发现这些东西。>> 是的。而且雷达的比喻，我知道有些公司也采纳了这个想法，顺便说一句，ThoughtWorks 鼓励这样做，说制作你自己的雷达，带回你的公司。我认为他们甚至有相关的工具。我真的很喜欢 ThoughtWorks 从未说过“这是行业的东西”。他们说“这是我们的东西。这是我们看到的。这是我们推荐给我们的团队、我们的团队成员或我们的客户考虑的。”还有，我喜欢有“暂停”的选项，也许只是要小心。我们没有看到好的结果，原因如下。是的，我想它感觉新鲜的原因可能是因为 ThoughtWorks 所做的很多工作都感觉很前沿，因为它都是关于目前最热门的话题，人工智能、LLM 以及人们正在尝试看是否有效的所有技术，或者我们看到确实开始有效的东西。是的，我的意思是，ThoughtWorks 在世界各地有数千名技术人员，他们正在为各种各样的组织做各种各样的项目，雷达是我们发现的一种机制，可以将一些信息从他们的大脑中提取出来，并在内部和整个行业中传播。你说得对，我确实推荐客户这样做，尝试制作自己的雷达。当它是客户雷达时，情况有点不同，因为有时它可能更像是“这是你应该做的”，带有一点强制性，而不是我们所给予的。而且它们也可以更挑剔，因为它们可以这样说，“是的，我们只是对做某些技术不感兴趣”，而对我们来说，情况是，如果我们的客户在做，那么我们就会了解它，对吧？我们必须使用它。>> 当然，雷达上充满了与人工智能和 LLM 相关的东西，因为这是我职业生涯中一个巨大的变化，它是我职业生涯中最大的技术创新变化。回顾您的职业生涯，您看到了哪些可以与人工智能在某种程度上相媲美的类似变化？>> 我认为这是我职业生涯中最大的变化。我认为，如果我们回顾一下整个软件开发的历程，可与之相比的事情将是从汇编语言到第一批高级语言的转变，这在我之前就发生了，当时我们开始出现 COBOL 和 FORTRAN 等语言。我想那将是一个类似的转变。>> 所以，您开始使用 FORTRAN，并且可能认识一些仍然在使用汇编语言的人，或者至少认识那个时代的一些人。>> 我在大学时做过一点汇编语言，但它很有用，因为我再也不想做它了。[笑声]>> 非常明智。但是您从中学到了什么，关于需要改变什么以及它如何改变行业，仅仅是从主要是汇编语言转向主要是高级语言？>> 嗯，首先，正如您所说，事情非常具体到单个芯片。每种芯片的指令都不同。你知道，像寄存器，你访问内存的方式。你用这些非常复杂的方式来做最简单的事情，因为你唯一的指令就是将这个值从一个内存位置移动到这个寄存器。>> 你总是要以非常非常低级的形式来思考，即使是非常相对糟糕的，像 FORTRAN 这样的高级语言，至少我可以写出像条件语句和循环这样的东西，在 FORTRAN 4 中，我至少可以写“if”，我可以写一个语句，我不能写一个语句块，我必须使用 GOTO，但你知道，这比你在汇编语言中能做的要好，对吧？所以，这是一个明显的转变，从硬件转向思考更抽象的东西，我认为这是一个非常非常大的转变。然后，当然，一旦我使用 FORTRAN，我就可以在一定程度上摆脱我运行的硬件。我现在是在大型机上运行吗？我是在小型计算机上运行吗？我的意思是，存在问题，因为语言总是在不同地方略有不同，但你有了某种程度的解耦。我认为这确实非常重要。我的意思是，我只在小型微处理器上做过，因为又是电子工程部分，所以我们在这方面离硬件很近。但是，你确实有了那种思维转变，我认为这与 LLM 相似，尽管正如我所写的那样，有趣的是，这种转变并非仅仅是抽象级别的提高，尽管有一点，但最大的部分是从确定性到非确定性的转变，突然之间，你在一个非确定性的环境中工作，这完全改变了你必须思考它的方式。马丁刚刚谈到人工智能是自汇编语言转向高级语言以来最具颠覆性的变化，这种转变不仅仅是改变我们使用的语言，它们需要全新的工具链。同样，人工智能加速开发不仅仅是更快地发布，而是衡量你发布的内容是否真正带来价值。这就是现代实验基础设施发挥作用的地方，而我们的赞助商 Statsig 可以提供帮助。使用 Statsig，您无需拼凑点解决方案，即可获得功能标志、分析和会话回放，所有这些都使用相同的用户分配和事件跟踪。例如，您将一项功能发布给 10% 的用户。同时，其他 90% 的用户自动成为您的对照组，具有相同的事件分类法。您可以立即看到组之间的转化率差异，深入了解治疗组用户在您的漏斗中在哪里掉线。然后观看未转化用户的会话录制，以了解出了什么问题。另一种选择是运行不同服务之间的作业，以同步您的功能标志服务和分析数据仓库之间的用户细分，然后手动链接可能具有不同用户标识逻辑的数据。这需要大量工作，而且也可能出错。Statsig 提供慷慨的免费套餐供您开始使用，团队的专业定价从每月 150 美元起。要了解更多信息并获得 30 天的企业试用，请访问 statsig.com/pragmatic。现在，让我们回到 LLM 的抽象转变。我们可以谈谈这种抽象的转变吗？因为一种非常天真或幼稚的看法是说，我们有三个层次，对吧？我们有汇编语言，您有硬件命令。您需要非常了解硬件。我们有高级编程语言，从 C 开始，然后是 Java，然后是 JavaScript，您不需要了解硬件，您只需要了解逻辑，您可能会说，我们有了一个新的抽象，那就是英语，它将生成代码。您说这不是一个抽象的飞跃，为什么您认为不是？>> 我认为有一个抽象的飞跃。我认为抽象飞跃的差异比确定性/非确定性飞跃要小，而且值得记住的是，高级语言的一个关键之处，我之前没有提到的是创建您自己的抽象的能力。这在您接触到面向对象等事物时尤其重要，转向更具表现力的函数式语言，如 Lisp，虽然 FORTRAN 和 COBOL 在某种程度上也可以做到，因为至少使用 FORTRAN，您可以创建子程序并从中构建抽象。但是，当您拥有更现代语言的能力时，您就有更多用于构建抽象的工具，而构建抽象的能力至关重要。>> 所以，您可以在语言内部创建一个构建块，它为您设定了目标，当然，这里我们有领域驱动开发，后来也实现了这些，等等。>> 没错。我的意思是，一个古老的 Lisp 格言是，你真正想做的是用 Lisp 创建你自己的语言，然后用你创建的语言来解决你的问题。我认为这种思考方式在任何编程语言中都是一种好的思考方式。你既在解决问题，也在创造一种语言来描述你试图解决的问题。如果你能很好地平衡这两者，那就能产生非常易于维护和灵活的代码。所以，构建抽象，我认为这是高级语言的一个关键要素，而人工智能在这方面有所帮助，因为我们可以更轻松、更流畅地构建抽象，但我们面临这个问题，现在我们正在谈论这些抽象的非确定性实现，这是一个问题，我们必须学习一套全新的平衡技巧来解决这个问题。我的同事 Unmesh Jooshi 写了一些我非常喜欢的关于他如何使用 LLM 来共同构建抽象，然后利用抽象来更有效地与 LLM 对话的想法。我发现这是一种非常非常有趣的思考方式，关于他如何处理这个问题，因为他确实在朝着这个方向努力。我读过一本书，但我记不起书名了，我们以后得找出来，书中提到，如果你能用纯英语向 LLM 描述大量的国际象棋比赛，那么 LLM 就无法真正理解如何下棋。但是，如果你用这些相同的国际象棋比赛，并用国际象棋符号向 LLM 描述，那么它就可以。我认为这非常有趣，你显然缩小了 token 的数量，但你也使用了一种更严格的符号来描述问题。所以，也许这是我们使用 LLM 的一个角度。我们必须找到一种严谨的说话方式，这样我们才能获得更多进展。当然，这与领域驱动设计中的普遍语言以及我十几年前围绕领域特定语言和语言工作台所做的一些工作有着极大的相似之处。所以，这里有一些引人入胜的东西，看看它们将如何发展。>> 是的。是的。我想这是我们第一次看到一个在软件工程领域如此广泛的工具，它是非确定性的，因为我们过去也有神经网络，它们不是，但它们的应用感觉更像是小众的，而不是无处不在。现在，每个开发者，我的意思是，如果你使用代码生成，你就在使用非确定性的东西。当然，我们正在左边右边地集成它们，尝试看它们在哪里有效。我们能公平地说，这是我们第一次面临确定性计算机的挑战吗？我们非常了解它们，我们知道它们的局限性以及所有这些东西，当然还有一些竞态条件和一些奇异的东西，但现在我们有了>> 确实需要解决的问题。>> 这是一种全新的思考方式。它与其他形式的工程有一些有趣的相似之处。其他形式的工程，你考虑的是公差，我妻子是结构工程师，她总是考虑公差。我需要比数学告诉我的多做多少？因为我需要它来应对公差，因为，是的，我的意思是，我大多知道木材、混凝土或钢材的特性，但我必须，你知道，考虑最坏的情况。我们可能也需要这种思维方式。我们必须处理的非确定性的公差是什么？并意识到我们不能靠得太近，否则我们会遇到一些桥梁倒塌。我怀疑我们尤其会在安全方面这样做。我们会遇到一些明显的崩溃。我担心，因为人们在他们使用的工具的非确定性方面走得太近了。>> 哦，当然。但在我们谈论可能崩溃的地方之前，您是否观察到或意识到了一些新的工作流程或新的软件工程方法，这些方法听起来令人兴奋，我们可以现在就使用 LLM 来完成，或者至少我们可以尝试给它们一个目标，而这在以前使用我们旧的确定性工具包是不可能的？>> 对，一个领域是，一个已经引起很多关注的领域是，能够在几天内快速搭建一个原型。这比以前做得多得多。这就是“氛围编码”的事情。但它不仅仅是这样，因为它也是一种尝试探索的能力。人们可以去，嘿，我不太确定该做什么，但我可以花几天时间来探索这个想法，比以前快得多。所以，对于一次性的探索，可丢弃的小工具之类的东西，包括那些由不认为自己是软件开发人员的人所做的事情。我认为这是一个完整的领域，而且，你知道，我们可以有充分的理由非常怀疑将它推得太远，因为那里存在危险。但我们也意识到，只要你在其正确的范围内对待它，那是一个非常有价值的领域，我认为我们会，那真的很好。在完全相反的尺度上，一个非常有趣的领域是帮助理解现有的遗留系统。我的同事们在这方面做了很多工作，一两年前。基本上，想法是，你获取代码本身，对其进行语义分析，基本上用那种信息填充图数据库。然后使用该图数据库，以类似 RAG 的风格，你可以开始询问，这个数据会发生什么？哪些代码片段会接触到这个数据，当它流经程序时？非常有效，事实上，如果我没记错的话，我们将对遗留系统的理解放入了“采用”环中，因为我们说，“是的，如果你在处理遗留系统，你应该以某种方式使用 LLM 来帮助你理解。”>> 所以，在这个环中，在 ThoughtWorks 雷达中，最少的东西是“采用”，它说我们强烈建议您查看它，至少，你知道，ThoughtWorks 自己会查看它。只有四项，其中一项是，是的，使用生成式 AI 来理解遗留代码，这对我来说表明您看到了巨大的成功，这是令人耳目一新的。顺便说一句，我没有听到太多这个，我想这有助于 ThoughtWorks，我敢肯定您不得不与很多>> 嗯，我的意思是，这源于一些在遗留代码方面做了一些非常有趣工作的人碰巧遇到了这个问题并查看了它，说，“嘿，让我们试试吧。”他们发现它非常有效，而且它也是我们许多人长期以来一直感兴趣的问题，因为我们必须一直这样做。如何有效地处理遗留系统的现代化？因为任何一家比几年大的大公司都有这个问题。>> 他们有很多。>> 特别是简单的东西，人们会离开，就像这样简单。拥有一个可以帮助你取得一些进展的生成式 AI，已经比毫无进展要好。>> 没错。所以，这是两个领域，很明显，我可以说，使用 LLM 取得了巨大的成功，然后是那些我们仍在弄清楚的领域。我的意思是，我肯定看到人们越来越感兴趣，因为人们试图弄清楚如何与 LLM 进行一对一的合作来构建高质量的软件。我们看到了一些明确的迹象，表明你必须与非常薄、快速的切片一起工作，小切片。你必须将每个切片视为一个来自一个相当糟糕的合作者的 PR，他在代码行生产力方面非常高效。但是，你知道，你不能相信他们所做的事情。所以，当你像这样玩弄这个精灵时，你必须非常仔细地审查一切。精灵是 GK Kent 的术语。或者 Dusty，那个拟人化的驴子，这是 Bita 的看法，我喜欢她的观点。>> 是的。但是，有效地使用它，你确实可以提高你的流程速度。这不是倡导者所说的速度提升，但它并非微不足道。绝对值得学习如何利用它，而像 Burgita、Kent 或 Steve Jagg 这样的人，我认为他们正在推动这一点。我认为我们仍在学习如何做到这一点。>> 每个人都在学习。绝对。>> 而且仍然存在问题，我们获得的大部分经验都是在全新的环境中构建的。这给绿色字段环境留下了很大的问题。嗯，我们知道 LLM 可以帮助我们理解遗留代码。它们能以安全的方式帮助我们修改遗留代码吗？[尖叫] 这仍然是一个问题。我的意思是，我刚刚和詹姆斯·刘易斯（James Lewis）聊天，因为他今天也在城里，他评论说他一直在玩光标，他一直在构建类似的东西，他说，“哦，我想在一个不是太大的程序中更改一个类的名称，”然后他开始做。一个半小时后回来，用掉了他每月 token 分配的 10%。而他所做的只是更改一个类的名称。>> 而且我们在 IDE 中实际上有功能，我仍然记得大约 20 年前，这可能是最前沿的，当时 Visual Studio 甚至不是 Visual Studio，而是 JetBrains 推出了一个名为 ReSharper 的扩展，它有助于重构代码，人们为此支付了高昂的费用，每年大约 200 美元，才能获得这个插件，现在你可以右键单击并说“重命名类”，它会构建后台的图，以某种方式进行更改，你可以重命名变量，这又是一个巨大的交易。事实上，在 Xcode 中，苹果的开发者平台 IDE，当 Swift 发布时，你无法进行这些重构，人们对此非常不满。所以，有趣的是，有些事情很容易，我们已经解决了，而 LLM 在这方面效率不高，做得不好。>> 是的。>> 是的。然后，我的意思是，他这样做只是为了看看会是什么样子，对吧？因为他知道你可以，我的意思是，我们已经有了很长的技术历史了，所以这有点好笑。我的意思是，但这也意味着，在处理现有系统和修改现有系统时，这仍然悬而未决。然后另一个领域，无论是全新还是现有系统，都悬而未决的是，当您有一个团队时会发生什么？因为大多数软件都是由团队构建的，并且将继续由团队构建，因为即使 AI 使我们的生产力提高了十倍，我也不认为会这样，我们仍然需要一个 10 人的团队来构建以前需要 100 人团队才能构建的东西，而且我们总是想要这些东西。软件需求没有下降的迹象。所以，我们总是需要团队，然后问题当然是我们如何在团队环境中最好地运作，我们仍在努力解决这个问题。所以，有很多问题，我们有一些答案，一些答案的开端，这是一个令人着迷的观察一切的时代。>> 您提到了“氛围编码”。您对“氛围编码”的理解和看法是什么？>> 嗯，当我使用“氛围编码”这个词时，我试图回到最初的定义，基本上是你根本不看输出代码。也许，你知道，出于好奇看一眼，但你真的不在乎，也许你不知道你在做什么，因为你对编程一无所知。它只是在为你吐出东西。所以，这就是我定义“氛围编码”的方式。我的看法是，正如我所指出的，我认为它适合探索。它适合一次性的、可丢弃的东西。但你不希望将其用于任何具有长期能力的用途，因为，我的意思是，再次，这是一个愚蠢的轶事，但我正在和我同事 Unmesh 一起工作，他刚刚写了一些我们昨天发布的东西。在这个过程中，我们创建了一个小的能力随时间变化的伪图，你知道，那种愚蠢的小伪图，用来阐明一个观点。他让 LLM 来创建这个。他描述了他想要的曲线，然后 LLM 生成了它，并将其放在那里。他把它提交到了我们的仓库。我看着它，心想，是的，这是一个足够好的图。我想稍微调整一下。我想，你知道，标签离它们标记的线条有点远，所以我想把它们拉近一点。所以我打开了 LLM 生成的 SVG 文件，哦，我的意思是，对于我自己写过的东西来说，它是多么复杂和曲折，而我写它的时候，它只有十几行 SVG，而 SVG 本身并不是一种简洁的语言，因为它是一个 XML 文件，但这个东西令人震惊地奇怪。我的意思是，这就是“氛围编码”的东西，它会产生什么，天知道，而且通常确实如此，而且你无法稍微调整它。>> 你基本上必须把它扔掉，并希望你能生成你试图调整的任何东西。当然，还有另一个区别，这是 Unmesh 昨天发表的文章的核心，当你以这种方式使用“氛围编码”时，你实际上是在移除某物中一个非常重要的部分，那就是学习循环。如果你不看输出，你就学不到东西。而我们所做的很多事情是，我们产生想法，我们在计算机上尝试它们，在计算机所做的与我们的想法之间不断来回反馈。我们不断地经历那个学习循环的编程方法，而 Unmesh 的观点，我认为是绝对正确的，是你无法绕过这个过程。而 LLM 所做的，它们只是略过所有这些，而你并没有学习。当你没有学习时，这意味着当你产生某物时，你不知道如何调整它、修改它、演变它和发展它。你所能做的就是从轨道上摧毁它，然后重新开始。我偶尔也会用“氛围编码”做一些事情，作为一家咨询公司，“氛围编码”有很多问题需要解决，当然。但你在学习方面是对的，无论是“氛围编码”还是人工智能。我注意到自己的一件事是，很容易，你知道，给一个提示，得到一些输出，你知道，你应该审查很多代码，无论是你自己还是在代码审查中，但我在自己身上看到的是，在某个时候，我开始感到有点累，我就让它过去了。这也是我与软件工程师交谈时听到的，那些在采用这些工具的公司工作的人，几乎所有公司都是这样，有更多的代码出去，更多的代码需要审查，然后[清嗓子]，他们问，“当比以前更多的代码需要审查时，我如何才能在代码审查中保持严谨？”您是否看到过有助于人们，包括经验不足的人和更有经验的工程师，通过这些工具继续学习的方法？有没有一些看起来很有前景的方法？>> 没有太多。我非常关注 Unmesh 的做法，因为他的方法非常强调“让我们尝试构建一种语言来与 LLM 对话”，与 LLM 合作生成一种语言，以便更精确、更仔细地向 LLM 传达我们正在寻找的东西。我认为这是一种有前景的、非常有前景的攻击路线。确保我们创建自己的专用语言来处理我们正在处理的任何问题，我认为这实际上带来了另一个，我们正在谈论我们知道 LLM 有用的东西，另一个，这也是 Unmesh 强调的，是理解不熟悉的环境。再次，我与 James 聊天，他正在 Mac 上使用 C 语言，这不是他非常熟悉的语言，使用一个名为 Godo 的游戏引擎。>> G o d o。是的。>> 是的。>> 而且他对此一无所知。但是有了 LLM，他可以学到一些东西，因为他可以尝试。如果你把它看作是探索，我的意思是，我记不清了，我确实到了这个地步，我输入到 L。哦，好吧，我如何在 R 中做某事，我做过 20 次，但我仍然不记得怎么做。而你，在探索中，Unmesh 再次提出观点，设置初始环境。你知道，给我一个起始项目，一个样本起始骨架项目，这样我就可以开始工作了。所以，那种探索性的东西，在不熟悉的环境中提供帮助，以及学习不熟悉 API 和编码思想的途径等等。它可能非常方便。>> 我想这并不全是新的，因为我记得，你知道，大约十到十五年前，行业中最后一个重大的生产力提升是 Stack Overflow 的出现。所以在 Stack Overflow 出现之前，当你用谷歌搜索问题时，你会遇到一个叫做 Experts Exchange 的网站，那里有问答，你需要付费才能看到答案，或者你需要付费才能让专家回答，但通常即使你付费，答案也毫无用处。我们大多数人，我是一名大学生，我就是不付钱。>> 所以，你就是找不到答案，你感到非常沮丧。然后 Stack Overflow 出现了，突然之间，你有了代码片段，你
可以复制，当然，很多年轻人，或者说经验不足的开发者，甚至像我一样的人，所做的就是直接复制代码，放进去看看是否能用。
随着你接触到更有经验的工程师或开发者，你开始告诉初级工程师，比如你需要先理解它，或者即使它能用，你也需要理解它为什么能用。你需要阅读代码。
我感觉我们经历了几年的时间，人们一直在盲目地复制粘贴代码片段。我记得当时有一个关于电子邮件验证的问题，一个获得最高票的答案并不完全正确。结果发现，很大一部分软件和开发者就使用了那个答案。
>> 我感觉我们已经讨论过这个问题了。
>> 是的，这是一种类似的情况，但
>> 也许规模要小一些。
>> 是的。但更加被放大，并且如虎添翼，而且还出现了这样的问题：你知道，未来事情会如何发展，因为谁还会去写 Stack Overflow 的答案呢？
>> 是的。所以，我我我不知道我们是否会走向这样一个方向：你需要关心工艺。你需要理解 LLM 的输出是什么，它在那里是为了帮助你，如果你不这样做，我的意思是，你应该这样做，但如果你不这样做，你最终会和那些只是盲目地提示它的人一样。
>> 完全正确。是的。我的意思是，我的意思是，我没有任何问题，从 LLM 中获取一些东西并将其放入以查看它是否有效，但一旦你这样做了，就要理解它为什么有效，就像你说的，还要看看它，并说它是否真的按照我想要的方式构建，不要害怕重构它，不要害怕将其放入，当然还有测试组合，任何你放入并且有效的东西，你都需要有一个测试，并且如果你不断地与测试过程进行这种来回的交互，Martin Fowler 刚刚谈到了在与 LLM 合作以及在一般构建高质量软件时测试的重要性。
说到高质量软件，我需要提一下我们的季度赞助商，Linear。我最近参加了 Linear 的一次内部每周会议，称为“质量星期三”，我完全被震撼了。这是一个每周一次的 30 分钟会议。在这个会议上，团队在半小时内完成了 17 项不同的质量改进。17 项。这是一个快速且超级高效的会议。砰，砰，砰。每位开发者都会展示他们本周所做的质量改进或性能修复。它可以是任何东西，从节省数千美元的大规模后端性能提升，到大多数人甚至不会注意到的微小 UI 优化。例如，一个修复是稍微改变了输入新行时作曲窗口的高度。另一个是修复了一个像素的错位。你能想象如此在意细节吗？在连续多年每周都这样做之后，他们的整个工程团队都培养出了对质量的惊人洞察力。他们在发布之前就能发现这些问题。现在，他们的一位工程师告诉我，自从他们随着时间的推移训练了这个肌肉，他们开始在构建东西时注意到模式。因此，首先就很少出现这些“纸割伤”。这就是为什么 Linear 在其他问题跟踪和项目管理工具中感觉如此不同。成千上万的微小改进确实累加起来，你会感受到差异。当你使用 Linear 时，你正在体验数百次“质量星期三”会议的成果。他们的 CTO Thomas 最近写了一篇关于这个每周例程的文章，我会在下面的节目笔记中链接。如果你的团队关心工艺并构建人们真正喜欢使用的产品，请访问 linear.app/pragmatic 了解 Linear。因为说实话，在我近距离观察了他们如何工作之后，我明白了为什么如此多的顶尖工程团队正在转向它。
现在，让我们回到在与 LLM 合作时测试的重要性。我的意思是，我特别关注这个领域的人之一是 Simon Willis，他不断强调测试的重要性，测试对他来说是一件大事，并且能够让这些东西正常工作。当然，你知道，Bea 来自 Thought Works。我们是非常典型的极限编程公司。所以，她也精通测试。所以，她会说同样的话。你必须真正专注于确保测试协同工作。当然，这就是 LLM 挣扎的地方，因为你告诉它们编写测试，而我只听到问题 [笑声] 或者自己亲身经历，比如当 LLM 告诉我，“哦，我运行了所有测试。一切都很好。你的 npm 测试有五个失败。”
是的，顺便说一句，我确实看到了一些改进，比如 Clock Code 和其他代理。但是的，这是非确定性角度。有时它们会欺骗你，这很奇怪，对吧？我仍然不
>> 它们一直都在欺骗你。事实上，如果它们真的是一个初级开发者，就像人们有时喜欢称呼它们那样，我就会和人力资源部谈谈了。
>> 是的。就像前几天，我经历了一个非常奇怪的事情，这是最简单的事情。我有一个配置文件，我只是添加新项目，一个新的 JSON，你知道，数据块，我只是在评论中添加了添加的日期，说添加于，你知道，10 月 2 日，添加于 11 月 1 日。它总是当前的日期。我告诉 LLM，请添加这个配置项并添加当前日期。它添加了，并且它只是复制了最后一个日期。我说那不是今天的日期。我说，哦，非常抱歉。你知道，让我为你纠正它。它放了昨天的日期。[笑声]
我感觉你需要获得这种体验，才能看到它会因为一个简单的当前日期的事情而让你产生错觉，你知道，你可以调用一个函数之类的，但这取决于，谁知道我使用的是哪个模型，那个模型如何工作，创建它的公司是否在优化 token 使用量等等等等。所以，最终，即使是最简单的事情，你作为一名专业人士，在处理重要的事情时，也不应该信任。
>> 是的，绝对。永远不要。
>> 是的。你必须，你必须不要相信，但要验证。
>> 验证。是的。与 Thought Works 的开发者以及你聊天的人交流，他们日常成功使用 LLM 的领域有哪些呢？比如我们刚才提到了测试。我们也提到了原型设计之类的东西，但你是否看到其他一些开始变得例行公事的事情？比如，如果我正在做这件事，让我去获取一个 LLM。它可能能帮到我。
>> 是的，我的意思是，我已经提到了很多，对吧？原型设计，理解遗留代码，哦是的，你可以用它来探索新技术领域，甚至可能探索新领域，只要你，你知道，你对它的信任程度远低于你对十年前的维基百科的信任程度。这些是我到目前为止听到的。
>> 是的，一个 Burgetta 正在探索的有趣领域是规范开发。有一种想法是，你知道，LLM 有它们自己的局限性，但如果我们清楚地定义了我们想要它做什么，并给它一个非常好的规范，你知道，它可以运行，它可以长时间运行，它有迭代等等。你对此有何看法？你是否有一种似曾相识的感觉，因为我们以前听过这个，对吧？你的职业生涯始于一种叫做瀑布开发的东西。那么，你如何看待这次的相似之处和不同之处呢？
嗯，与瀑布的相似之处在于人们试图创建一个大量的规范，而不怎么关注代码。在这里，我的意思是，无论你，无论你再次谈论，这就是你所说的规范，是如此关注它，还是做小部分的规范，进行紧密的循环？我的意思是，对我来说，关键是你想避免瀑布式的问题，即试图先构建整个规范。它必须是，做你能做的最小量的规范，你可能能够取得一些进展。循环它，构建它，进行测试，如果可能的话，将其投入生产，然后用这些薄片进行循环。无论哪种情况，规范可能扮演的角色都可以被认为是规范驱动开发的一种形式。但对我来说，重要的是紧密的循环，薄片，那种东西。
>> 我知道 Big 肯定同意这一点。因为她和你必须是那个每次都进行验证的人，这显然是至关重要的，而规范驱动开发又会再次变得有趣，它又回到了构建领域语言和特定领域语言以及类似东西的想法。我们能否制定一种更严格的规范来讨论，你知道，我提到了 Unmesh 在做什么，使用它来构建一个抽象，因为本质上我们说的是，它给了我们一种比我们纯粹在代码库本身中构建它们时更流畅地表达抽象的能力。但我们仍然不希望它们与代码库偏离太多，对吧？我们仍然希望普遍存在的语言概念，即我们脑海中的语言与代码中的语言相同，并且我们看到相同的名称，并且它们在做同样的事情。结构显然是平行的，但显然，我们的思考方式比代码的思考方式更灵活。然后，你知道，我们能否通过使用 LLM 作为该领域的工具来模糊这个界限？所以，我认为这是那个方向上一个有趣的领域。
>> 这很有趣，因为我我感觉我们从未能够使用如此接近代码的语言，或者像业务逻辑，这是非常新的。
>> 是的。尽管人们，我的意思是，有很多人将这种 DSL（领域特定语言）思维融入到他们的编程中，我也会，我知道有些人会说，是的，我会达到这样的程度，我可以用一种编程语言，比如 Ruby，来编写业务逻辑的某些部分，然后给领域专家看，他们就能理解。他们不会觉得他们自己能够编写它，但他们能够理解它，足以指出其中的错误或正确之处。这只是编程代码，但这需要一定程度的投影语言的方式才能获得这种流畅性。所以，但是那种思维方式，比如试图将编程语言变成内部 DSL，或者构建自己的外部 DSL，DSL 意味着领域特定语言，比如如果你与会计师一起工作，你将使用他们使用的术语，他们使用的方式等等。
>> 是的。而你当然在试图做的是创建那个沟通渠道，让非程序员至少能够阅读正在发生的事情，并理解它，以便能够找出其中的错误并提出更改，这些更改可能在语法上不正确，但你可以很容易地修复它们，因为你作为程序员，可以看到如何做到这一点。这就是目标，有些人已经在某些地方实现了这个目标。所以有趣的是，LLM 是否会使我们在这个方向上取得更多进展，并看到这种情况更广泛地发生。
>> 我猜这一定，我只是假设，如果我错了，这一定对那些软件开发人员不是大多数人的企业来说尤其重要，比如他们是员工的 10% 或 20%，而且还有会计、营销、特殊业务部门，他们都想要编写软件，他们知道自己想要什么，而且历史上一直有人在翻译，无论是项目经理、技术专家等等。所以，你是在说，这可能是一个非常有趣的机会，或者只是一个实验，通过 LLM，我们可以让双方都更容易一些。
>> 那是我最熟悉的世界，对吧？就是那个世界。我的意思是，我我的感觉是你非常熟悉大科技公司和初创公司，但这个企业世界当然是另一回事了，因为正如你所说，软件开发人员突然只占一小部分，而且有很多复杂的业务事情需要我们以某种方式进行交互，当然，通常还有一个更糟糕的遗留系统问题。而且会有法规，会有历史，会有例外，因为所有的知识。我认为我们可以想到银行的所有事情，因为那里有一个完美的风暴，对吧？他们有不断变化的法规。他们有想要避免的事件。他们会有特殊的 VIP，我不知道，账户或其他什么。当然，他们有所有这些业务部门，他们都知道自己的规则和框架。而且他们存在的时间比技术还要早。有些银行已经存在了 100 多年了。
>> 是的。而且请记住，银行通常比大多数其他公司在技术上更先进。 [笑声]
>> 你在谈论银行时看到了好的一面。[笑声]
>> 你也和一些不太先进的人打过交道。
>> 我的意思是，是的，零售商、航空公司、政府机构，诸如此类。我的意思是，这很有趣。我曾与一些在波士顿联邦储备银行工作的人聊天，你知道，他们必须极其谨慎。他们目前不允许触碰 LLM，因为你知道，当你处理一个主要的政府银行组织时，错误的后果是相当严重的。所以你必须非常非常小心那种事情。是的，他们的限制非常不同，这让我想起了一句格言，它说要理解软件开发组织如何运作，你必须看看组织的核心业务，看看他们做什么。有趣的是，我参加了波士顿联邦储备银行的一个敏捷会议，他们带我参观了联邦储备银行，他们处理金钱的地方。所以我看到了他们把从银行送来的钞票进行处理、清洁、计数等等的地方，然后再次发出。你看看他们付出的关怀和控制的程度。正如你可以想象的那样。我的意思是，当你带来巨额现金，并且必须对其进行分类、计数等等，控制措施必须非常非常严格。你看看这个，看看他们做所有这些事情的谨慎程度，然后说，“是的，我可以看到为什么在软件开发方面，这种心态会渗透进去，因为他们习惯了事实上，他们在这里必须非常小心每一件小事。”许多公司当然也有类似的观念。如果你在一家航空公司工作，你非常关心安全。你非常关心把人们送到目的地，这会影响你的整个思维方式，或者应该如此，而且确实如此。我猜这就是为什么我们清楚地看到技术使用上的分歧，因为你有初创公司，这是一群人，他们刚刚筹集了一些资金，或者没有资金。他们没有什么可失去的。他们没有客户。他们可以获得一切。他们需要抓住最新的潮流。他们想尝试最新的技术。通常建立在它们之上，或者销售工具来使用最新的技术，他们在这里打破规则。你知道，当你在一家拥有一些客户的企业中时，你会开始变得更加谨慎，当然，你知道，50 或 70 年后，当创始人离开，现在是一家大型企业时，你就会有不同的风险承受能力。
>> 完全正确。是的。
>> 但我发现关于这个的迷人之处在于，我不确定是否有任何新技术被如此迅速地普及到各地。你提到，比如说，联邦储备银行或其他政府组织可能会说，我们现在还不碰这个，但他们也在评估，听起来是这样。所以，如果他们是，他们是最落后的技术曲线之一，原因很充分，他们已经意识到了这一点，或者正在使用它，这可能意味着它现在无处不在了。
>> 哦，是的。我的意思是，是的。我的意思是，我们到处都能看到它，但再次强调，在企业世界中，他们更加谨慎，他们说，“是的，我们也看到了这里的危险。”
>> 然后你看到你合作的那些更灵活的公司和更注重企业的公司。你会说他们与人工智能的关系最大的区别是什么？他们的处理方式是怎样的？是这种谨慎，还是有其他特征，使得那些更传统、风险规避程度更高的公司采取不同的方法？
>> 重要的是要记住，任何这些大型企业都不是铁板一块。所以，这些公司的小部分可能非常大胆，而其他部分则可能非常不那么大胆。所以你会看到小的，我的意思是，就像你知道，当我开始在 Cheetah Lightwe 工作时，我是在那个非常非常积极地做一些疯狂事情的小部分中，对吧？你在任何大公司都会发现一些小部分在做一些事情。所以，企业内部的差异通常比企业之间的差异更大。
>> 很好地记住了。所以，说到重构，LLM 非常擅长重构，你早在 1999 年就写了《重构》这本书。这是第二版，20 年后进行了更新。它实际上是一本非常详细的书，介绍了各种代码异味，可以显示代码在哪里，重构它的技术。在第一页，我真的很喜欢它。它有一个重构列表，我不知道出版商是如何印刷的，因为它非常非常不寻常，但它就在目录里。你为什么决定在 1999 年写这本书？你能带我们回到当时的环境，以及第一版这本书的影响是什么？
好的。我第一次接触重构是在克莱斯勒。是的。当我早期与 Kent Beck 合作时。我记得在底特律的酒店房间里，庭院之类的，他向我展示了他如何重构一些 Smalltalk 代码。我的意思是，我一直是一个喜欢回到我写过的东西并使其更易于理解的人。我一直非常关心事物的可理解性。这在我的散文写作和软件写作中都是如此。所以我知道，但他所做的就是采取这些微小的步骤，我惊叹于每一步有多小，但因为它们很小，所以它们不会出错，而且它们会完美地组合起来，你可以通过这一系列的小步骤做很多事情。这真的让我大开眼界。我想，“哇，这是一件大事。”但当时 Kent 的精力都放在写第一本极限编程书，也就是白皮书上。他没有精力写一本重构书。所以我想，好吧，那我来做吧。[笑声]
我开始，你知道，每当我重构某样东西时，我都会仔细做笔记。部分原因是我自己需要。我如何提取一个方法，这样我就不会搞砸它？所以我会在每个上面仔细做笔记。然后，重构书中的每个机制都是那个步骤。然后，我会为每个步骤做一个例子。这就是第一版书。然后，我用 Java 来做，而不是 Smalltalk，因为 Smalltalk 不幸正在消亡。而 Java 是未来的语言，是我们未来唯一需要的编程语言，在 90 年代末。这就是导致第一本书的原因。
至于影响，嗯，我的意思是，而且我也应该强调，重构并不是 Kent 发明的。我的意思是，它在伊利诺伊大学厄巴纳-香槟分校的 Ralph Johnson 的团队中得到了很大的发展。他们构建了第一个 Smalltalk 重构浏览器，这是我们现在谈论的第一个自动重构工具。那是 John Brandt 和 Don Roberts 构建的原始重构浏览器。然后，当这本书出来时，引起了更多的兴趣，IBM Visual Age 的人已经有一些兴趣，因为他们来自 Smalltalk。Visual Age 的原始版本实际上是用 Smalltalk 构建的。所以他们一定程度上已经知道了发生了什么，但 Jet Brains 的人真正抓住了人们的想象力，因为他们将其融入了 IntelliJ IDEA 的早期版本，并真正地将其发扬光大。然后你当然遇到了 ReSharper。他们确实让自动化重构成为人们可以依赖的东西，但了解如何自己做仍然很好，因为你经常会遇到一种语言，而你没有那些重构可用。所以能够提取那些东西是很好的，而且有些东西并不明显存在。是的，所以它的影响是重构成了一个词，当然，就像所有这些词一样，它被严重滥用，人们用重构来指代任何对程序的更改，当然它不是，因为重构是非常严格的，这些非常小的、保持行为的更改，你做的是微小的微小的步骤。我总是喜欢说，每一步都小到不值得去做，但你把它们串联起来，你就能做惊人的事情。我想我们都有过这样的经历。至少我有一个故事，我的一个同事，或者你知道，可能是我自己，但通常是我的一个同事会说，比如，站起来说，哦，我只是要做一个重构，然后第二天，哦，我还在做重构，第二天，哦，我还在做重构，然后 [笑声] 你知道，那肯定错过了小改动的环节。
是什么让你在 20 年后的 2019 年写了第二版？
嗯，这是一种想要更新书中一些东西的感觉。我也有一些新东西。我也担心，我的意思是，当一本书是用 90 年代末的 Java 写的，它会显得有点过时。
>> 是的。[笑声]
>> 尽管我认为核心思想是健全的，人们仍然可以使用它，但我认为你应该在一个更现代的环境中这样做。然后问题是，我是否会继续使用 Java，还是切换到另一种语言？最终，我决定切换到 JavaScript。我认为这样可以触及更广泛的受众，并且可以以一种不那么面向对象的方式来描述事物。所以，与其说提取方法，不如说提取函数，因为当然，对于函数来说，这是相同的过程，而且有些事情你不会一定在面向对象的语言中考虑。但主要是为了更新，重新做例子，希望能再给它 20 年的生命，因为它必须让我活到我咽气为止，你知道。[笑声]
>> 是的。所以你 25 年前或 26 年前出版了这本书，根据你与开发者的互动，行业对重构的看法发生了怎样的变化？因为你在书中明确写道，你认为重构是软件开发生命周期中的一个关键要素，你也谈到过如何重构，随着时间的推移改变代码的总体成本会便宜很多。有没有一个时期，人们对它的接受度更高，还是仍然存在，或者你觉得它有点像被遗忘了，就像当时一些非常创新的工具，比如 Jet Brains 等等，它们可能不再像以前那样被提及了，尽管它们无处不在。
对我来说很难说。我的意思是，我的意思是，我大部分的互动都是与 Thought Works 的人进行的。他们往往比普通开发者更了解这些东西。当然，我在网上读到很多让我摇头的东西，关于重构是如何被描述的，更不用说缺乏以我喜欢的那种结构化、受控的方式进行重构了，因为我喜欢快速有效地进行。而且，你知道，这是其中之一，尽管听起来可能很奇怪，但有纪律的方法实际上更快。但我的意思是，我必须，它至少已经成为我们语言的一部分了，人们谈论这样做。它存在于这些工具中，而且它们做得非常有效。它们进行的重构，我的意思是，在你可以自动完成这么多事情的环境中工作真是太棒了。所以我认为我们肯定取得了一些进展。可能没有我希望的那么多，但你知道，事情往往就是这样。
展望未来，随着 AI 工具生成更多代码，速度更快。所以，我们将拥有更多的代码。我们已经有了更多的代码。
你认为重构的价值，考虑到你对那些持续的小改动的意图，将变得多么重要？你是否已经看到其中一些变得重要了？
>> 我不会说我已经看到了。但可以肯定的是，我预计它会越来越重要。因为，再次强调，如果你要生成大量质量可疑但能工作的代码，那么重构就是一种在保持其工作的同时将其提升到更好状态的方法。目前的这些工具肯定无法自行重构。尽管我们已经与其他东西结合了。Adam Tornhill 在结合 LLM 和其他工具方面做了一些有趣的工作，以获得更有效的方法，我认为那种结合的方法可能是一个好方法。但绝对是重构的心态和思考方式，我如何通过将其分解为易于组合的非常小的步骤来做出改变。这才是诀窍。小巧和可组合性。将这两者结合起来，你就能取得很多进展。
这很有趣，因为现在如果你想重构，你肯定需要打开你的 IDE。我的意思是，最快的方法就是使用内置工具，或者你移动东西。我也发现，描述它，当我打开一个带有 Clock Code 或类似东西的命令行时，这很困难，或者我花在解释上的时间比我做那个小改动的时间还多。我确实想知道，我们是否会看到更多的集成，这样 LLM 就可以真正做到这一点，或者其中一些可能会自动做到，因为正如你所说，它开箱即用不起作用，但我认为对于任何高质量的软件，我的意思是，我们都吃过苦头，如果你只是放任不管，不回去改变它，当你的函数变得太长，当你的类变得太长时，把它分开，否则你以后就无法理解它了。
是的，看看它是否为我们提供了一种控制工具，这也会很有趣。我的意思是，我感兴趣的一件事是人们如何使用 LLM 来描述对关系数据库的查询，这些查询会变成 SQL。你不知道如何正确地获得 SQL，但如果你在 LLM 中输入内容，它会返回 SQL，然后你可以查看它，并说，“哦，这是对的还是不对的。”然后进行调整，它会让你开始，对吧？同样，对于重构，它可能会让你开始，并说，“哦，这些是我正在关注的更改类型，并能够取得一些进展。”我的意思是，特别是当你谈论跨大型代码库的自动化更改时。
大约一年前，有一家大公司谈到了这个巨大的变化，对 API 进行了更改并清理了代码，他们称之为 LLM 的事情，但它不是 LLM。它是另一种工具，我完全记不起所有这些东西的名字了。哦，我有一个 60 岁的脑子，我什么都记不住了。它会想起来的。但实际上，它是，你知道，大约 10% 的 LLM 和 90% 的其他工具的组合。但那再次提供了额外的杠杆，使他们能够取得进展。我认为这些事情非常有趣，使用 LLM 作为起点来驱动一个确定性工具，然后你就能看到确定性工具在做什么。我认为那里有一些有趣的相互作用。
说到从重构到软件架构，你在 2000 年代初期非常忙于写书。你在 2002 年写了《企业应用架构模式》这本书，这是一本收集了 40 多个模式的书，比如懒加载、身份映射、模板视图等等。我记得当时有你关于企业架构模式的书，还有 GoF 的书，我当时面试时有很多关于如何做工厂模式和单例等等的谈话。软件架构被谈论得很多，我的感觉是，在很多地方，比现在多得多。然后发生了一些事情，从 2010 年开始，我再也听不到大多数技术人员谈论模式或架构模式了。你如何观察这本书出版的这段时期？它的影响是什么？为什么谈论它并将其引入行业很重要？你如何看待这种变化，即我们不再谈论模式，以及你认为为什么会发生这种情况？
是的，我的意思是，我一直觉得它很有趣，我的意思是，你用模式来尝试创建一种词汇，以便更有效地谈论这些情况。我的意思是，就像在医学领域一样，他们会用希腊语和拉丁语的术语来更精确地谈论一些非常复杂的事情。
>> 是的。
>> 而用模式，我们试图做的是进化出同样的语言，只是我们不是用希腊语和拉丁语来做。我当然觉得它们有助于更有效地进行沟通。一旦人们熟悉了这些术语。我的意思是，你不会把它们看作是某种，你知道，你能把多少个塞进你正在构建的系统中。它更多的是一种如何利用它们来描述你的替代方案和你的选择，以及更多地思考何时应用它们或不应用它们。我的意思是，模式只在某些上下文中才有用。所以你必须非常了解何时使用它们的上下文。是的，有点可惜的是，其中一些风头已经过去了，也许是因为人们过度使用了它们，试图将它们用作某种，就像在胸前别上奖章一样。但它仍然非常有益，我的意思是，我的意思是，我最近与 Unmesh 合作编写了关于分布式系统模式的书，我认为那是一种很好的方式，再次创造一种语言来描述我们如何思考核心元素，并更好地理解分布式系统是如何工作的，这是当今生活中处理事情的一个重要方面，因为我们都在构建这类分布式系统。所以我仍然认为它们可以是一种很好的表达方式。我很难感觉到为什么它们变得不那么流行了。也许它们会再次变得更流行。谁知道呢？但我一直在寻找传播知识和让事情更容易理解的方法。而且我确实认为，这种识别、创建我们可以更精确地谈论事物的名词的想法是其中的一部分。
我不知道，因为我我我见过我工作过的地方，我们使用过这些东西，然后又在一些地方我们就像把它们扔掉了，没有人使用它。而区别老实说只是公司的年龄和态度，因为有一段时间，人们认为模式是为遗留公司准备的。所以初创公司会从一张白纸开始，你知道，一个白板，你知道，UML 是一个完美的例子，UML 有非常严格的关于如何画箭头的规则。如果你做得对，你甚至可以生成代码并做所有这些事情。而在初创公司，软件架构仍然存在，但你只是把它画在白板上，画一个方框或一个圆圈，你不在乎箭头。这只是，我想我们不会将自己锁定在现有的做事方式中。而且这也有点像教育，你需要入职这些东西。你们都需要有共同的理解，也许这只是这两者的结合。而且我认为这也是一种代际现象。你知道，每隔几年就会有一代新人出现，就像我上大学时，用 Facebook 非常酷，当时只有大学生，然后当我的父母上去时，用 Facebook 就非常不酷了，或者我的祖父母上去时，就像他们开始使用 Facebook 时我就停止使用它了。所以我想知道是否会有这样的来回的波浪，因为在这些初创公司内部，有一种语言，你知道，行话，关于他们如何谈论架构，并且随着时间的推移开始形成。你开始看到它，无论是长期任职的员工，你越来越多地听到行话，只是它不在一本任何人都可以阅读的书里，但你必须进去，或者去类似的公司，他们会把行话带走。
>> 完全正确。人们会创造这些行话。这是沟通不可避免的一部分。你需要，你不能每次都用五段话来解释一切。如果你一直在使用这个词，你就把它变成了一个词。然后每个人都创造自己的词。你所做的，当你提出一本像《分布式系统模式》这样的书时，你是在说，“好吧，这里有一组词，有大量的定义和解释。我们希望我们能够就此达成一致，以便我们能够更广泛地沟通。”但人们说，“你知道，在我们的小环境中，我们创造我们自己的行话。”也是很自然的。所以，我们不注意这一点，然后就会出现不匹配，你只有在你跨越这些不同的环境时才会真正注意到。
>> Grady Booch 对此有一个有趣的看法。所以我也问过他同样的问题，因为他一直非常热衷于软件，他仍然热衷于软件架构，并且他极大地推动了该领域的发展。他说，他认为发生的是，从大约 2010 年开始，模式就从主流行业中消失了，我再说一遍，它仍然存在于一些领域，但大约在 2010 年，发生的一件有趣的事情是云计算开始变得越来越大，AWS、Google Cloud，许多公司开始构建类似的东西。他们开始构建，最初是在本地后端服务，你的大部分业务逻辑在那里，后来它转移到了云端。Grady 说，这些超大规模服务提供商，云提供商，例如 AWS，他们构建了所有这些服务，这些服务都经过了非常好的架构设计，你可以一个接一个地使用它们，而且做得很好，你不需要太担心你的数据存储，你只需要使用，比如说，DynamoDB 或托管的 PostgreSQL 服务。突然之间，架构就不那么重要了，因为这些块为你处理了。你有这些构建块，现在你正在谈论在某个系统之上使用这个数据库。他的观察是，也许架构已经通过你可以使用的良好架构的构建块得到了解决，而你不需要重新发明轮子。
>> 是的。但我怀疑仍然存在使用这些东西的模式，而我还没有深入研究，因为我还没有机会专注于此，或者更确切地说，我还没有足够多的同事敲我的门给我草稿文章来发表。
>> 嗯，我确实看到了一个模式，那就是每家公司，你知道，都会给他们的系统命名。有些有奇怪的名字，有些有合乎逻辑的名字。但当你谈论架构时，你通常会谈论，你知道，就像在 Uber，我们有一个银行表情符号服务，叫做 Bank Emoji Service，后来迁移到了 Gulfream，你知道，这些听起来都不太合理，如果你是从外面来的。有时他们有合适的名称，他们会尝试，比如支付配置文件服务，但然后有一个新版本，现在是支付 Pro，也就是 PP PP2，总之。但在任何公司内部，你都会谈论这些特定的名称，你会谈论它们是如何工作的，它们有多小，有多大，而这我觉得，这通常就是行话。
>> 是的，就是这样。它又变成了大型组织行话的一部分，而且再次强调，你看看一家比 Uber 存在时间更长的公司，当然，这种行话已经根植于组织中。你可能需要几年时间才能弄清楚到底发生了什么，因为你需要那么长时间才能了解所有这些系统以及它们如何相互连接。
>> 嗯，我多年前有过一次非常有趣的谈话，是和一个美国运通公司的高层人士谈论的，我们谈论了他如何负责将他们的系统重新架构到下一代。他正在想办法如何传播想法并将其付诸实践。我问他这个工作做了多久了？他说是三年。我当时想，“好吧，我们现在在哪里？你完成了吗？”他说，“不，不，这只是规划，就像 [笑声] 我们快要完成规划了。”对我来说，这不合逻辑，因为三年都在规划。但再次强调，一旦你开始理解业务的规模，有多少钱，有多少遗留系统，他所做的一半就是与业务利益相关者交谈，说服他们或获得他们的支持。我想这种情况最终会发生在大多数公司身上，只是当你在一家年轻的公司或数字优先或技术优先的公司，也就是说，成立于 2010 年或之后的公司时，你仍然看不到这一点，但这可能会在 10 年后发生。
>> 哦，是的，肯定会的。哦，这很有趣。我记得我曾和一位加入一家银行的人聊天，一家老牌银行，他从一家初创公司加入。他的工作之一是现代化银行的运作方式。他评论说，我们在这里已经三年了，我想我能理解问题了，我对可以做什么，什么可以做有一些想法，但你需要那么长时间才能真正理解你身处的新景观，因为它很大，而且已经存在了很长时间，而且很复杂，而且不合逻辑，因为它是由人类而不是计算机构建的。它不是一个逻辑系统。而且里面有各种各样的历史，因为各种各样的事情发生了，因为某某遇到了某某，并与某某发生了争执。所有这些事情都会随着时间的推移而渗透进来，这个供应商来了这里，在那里很受欢迎，然后喜欢这个供应商的人被调到了组织的另一个部门。然后来了另一个人，他想要另一个供应商。所有这些东西都会随着时间的推移堆积起来，形成一个复杂的混乱。任何大公司都会有这种复杂的混乱，因为很难避免这种情况。是的，我的意思是，Uber 很幸运，它相对年轻，但它会，你知道，假设它能存活 50 年，它就会像美国运通一样，对吧？
>> 是的。你已经可以看到变化，流程的层级等等，这就像是必需的，随着你的成长。说到变化和迭代，以及敏捷，你参与了创建敏捷宣言的 17 个人之一。我之前问过参与其中的另一位人物 Ken Beck。你能从你的角度告诉我，你们是如何走到一起的，这个混乱的一天是如何展开的，以及你回忆起当时的反响如何？这是 2001 年，对吧？
所以，我的意思是，它的起源，我一直觉得实际上是一年前我们举行的一次会议，由 Kent 主持，关于极限编程的聚会，我们当时正在使用极限编程，我们在 Kent 当时住的地方附近的一个地方举行，在俄勒冈州的荒郊野外。他还邀请了一些不直接属于极限编程团队的人，比如 Jim Highsmith 等人。我们讨论的一个问题是，极限编程应该是 Kent 在白皮书中描述的相对狭窄的东西，还是应该是一个更广泛的东西，它有许多类似的原则。Kent 决定他想要更具体和狭窄的东西，然后问题是
嗯，我们该如何处理这个更广泛的事情，以及它如何与像敏捷开发人员所做的事情以及所有这类事情重叠，这就是促使我们召集来自这些不同群体的人们的想法，然后我们争论是否要在犹他州举行会议，因为 Alistister 想在犹他州举行，然后 Dave Thomas 想在加勒比海的安圭拉举行，出于某种原因，我们最终去了犹他州，嗯，还有滑雪，所以我们召集了我们召集的人，当然，这取决于谁真的来了，因为显然很多人被邀请了但没来，嗯，我并没有过多地参与其中，尽管 Bob Martin 坚持认为我参与了，他提到了芝加哥的一次午餐，这很有可能，因为我当时经常因为工作去芝加哥。所以，我可能去了，但我记不清了。嗯，至于会议本身，我实际上记不太清了，这很可惜。我，我，我，你知道，我责怪自己没有写下那几天的详细日记。嗯，我很想知道，你知道，我们是如何想出那个关于价值观的结构，比如，我认为那真的很棒，但我不知道它是如何形成的。所以，不幸的是，我对于实际的执行过程非常模糊。我确实记得，虽然我们要对此保持警惕，但我有一个相当清晰的记忆。我稍后可能会谈到为什么 Bob Martin 是那个真正坚持要写宣言的人，而我当时想，哦，好吧，我们可以做到，宣言本身将是完全无用的，当然会被忽略，但写作的过程会很有趣，嗯，这是我的反应，无论我对宣言有什么感觉，我都觉得，哦，没人会注意到这个，哦，哇，但是，嘿，我们写得很开心，我们互相理解等等。这就是价值所在，对吧？我们会更好地理解彼此。然后，当然，它产生了一点影响，这有点令人震惊。然后，当然，它经常被滥用，因为 Alistister Cobin 有一句很棒的话：“你绝妙的想法要么被忽略，要么被误解，而你无法选择是哪一种。”嗯，宣言有四条不同的线索也有帮助，所以人们只是选择他们想强调的那一条。12 条原则。哦，还有 12 条原则，是的。以及它开头说“我们正在揭示”，并且这是一个持续的过程，而宣言只是“这是我们所拥有的，我们是如何走到这一步的”，所以它是一个时间点的快照，我们当时在 20201 年。是的，宣言中有各种各样的微妙之处，但我想它产生了影响，因为我的感受是，我们希望在 Fort Works 为我们的客户在 2000 年编写软件，这非常困难，因为他们不想以我们想要的方式工作。我们说我们想把所有精力都投入到编写测试中，我们想有一个自动化的构建过程，我们想做这些事情。我们想能够以小的增量进步。所有这些事情都是令人厌恶的。你知道，不，我们必须有一个五年的大计划，我们将花两年时间进行设计，然后我们将产生一个设计，然后将在接下来的几年里实现，然后我们将开始测试，对吧？我的意思是，这就是事情应该如何做的思维方式。是的。那只是普遍理解的智慧，对吧？是的。而我们的想法是，不，我们希望在一个月内为一部分需求完成整个过程。只有一个月。当然，我们真的很想在一周内完成，但你知道，循序渐进。所以对我来说，敏捷的伟大之处在于，我们可以真正进入组织并以更接近我们想要的方式运作。我们的客户允许我们以我们想要的方式工作，这比我们在 2000 年能够做到的要大得多。这就是成功。我只是希望世界对那些想以那种方式工作的人是安全的，让他们能够以那种方式工作。是的。所有这些都导致了各种其他糟糕的事情。但总的来说，我认为我们好了一些。你是否看到，尤其是当你看到你有很多可见性的企业客户时，你是否看到从 25 年前到现在有明显的改变，敏捷的概念被广泛接受，与客户合作，进行更多的增量交付，忘记这些非常长期的工作，这在任何地方都很普遍，对吧？我们可以这样说吗，或者至少？我们取得了重大进展，但与我们想要的以及我们的愿景相比，它仍然是我们想要的苍白影子。我的意思是，我怀疑我们剩下的 17 个人都会同意这一点。我们仍然觉得我们可以做得比现在好得多，但我们确实取得了实质性的进展。而且，我们一直处于那种情况，你知道，我们以比我们想要的慢得多的速度向前推进。现在，当然，人工智能正在到来，它现在无处不在，而且将无处不在，而关于人工智能，敏捷的核心思想是进行增量改进，越短越好。现在，你可以构建软件，然后逐步开始改进。但今天，随着人工智能，尤其是人工智能，将会有更多的软件，到处都是。已经有了。而且客户不一定想等待增量改进。他们希望一开始就看到质量。你认为敏捷在人工智能方面也会同样有效，甚至更短的增量，或者你认为我们可能开始考虑一些不同的方式来处理人工智能，一开始就考虑质量，并回到一点点，你知道，基于规范的开发，一开始就得到一个很棒的软件版本。我不知道人工智能会如何发展，因为我们还处于早期阶段。我仍然觉得通过小切片构建东西，由人类审查，仍然是最好的方法。希望人工智能能让我们更快地完成这些切片，也许在每个切片中做更多的事情，但我们需要，我宁愿有更小、更频繁的切片，而不是每个切片中做更多的事情。我认为我们最主要的收益来自于提高频率，而不是试图在同一个周期内做更多的事情。我仍然感觉到这一点，当我和人们交谈时，他们仍然说，“你能看看你在软件开发中所做的一切，并提高频率吗？做一半的事情，但花一半的时间，并加速这个周期。寻找加速它的方法。而且，你知道，看看你在做什么。寻找你流程中的线索，找出如何减少这些线索。如果你能从想法到运行代码在两周内完成，你如何将其缩短到一周？不断尝试改进这个周期时间。我仍然觉得这是我们目前最好的杠杆形式，就是改进周期时间。是的。我一直在与一些领先的人工智能实验室交流，了解他们如何使用它，因为当然他们将处于最前沿。他们也会使用它。使用他们自己的工具对他们自己也有好处。在 Entrophic，云代码团队， clot code 的创造者之一 Boris 分享了他如何为一个功能制作了 20 个原型，关于任务的进度条如何列出不同的步骤以及它如何显示你所处的位置，他构建了 20 个不同的原型，他都尝试了并获得了反馈，并决定了哪一个将在两天内完成。他向我展示了，他实际上有视频，他只是记录了这些，他使用的确切提示和输出，这些都是交互式原型。所以它们不仅仅是，你知道，像纸上的那样，而是它们在里面。对我来说，这就像，哇。如果有人告诉我我构建了 20 个原型，然后问我花了多长时间，我会说两周，也许一周，如果它们很小，像纸质原型。但你仍然可以加速它，而且它仍然是可管理的。其中一些他扔掉了。其中一些他与小团体、大团体分享。所以，我觉得你关于我们还没有达到我们能多快地看待事物的极限的说法是正确的。是的。这又回到了反馈循环。我的意思是，其中很大一部分是尝试，我们如何将反馈循环引入流程？我的意思是，我们如何收紧这些反馈循环，以便我们更快地获得反馈，以便我们能够学习，因为最终，你知道，我们必须学习我们试图做什么。说到学习和跟上最新信息，你是如何学习人工智能的？你如何跟上正在发生的事情？哪些方法对你有效？你看到你的同事们也跟上潮流的方法是什么？我这些天学习的主要方式是与那些正在撰写文章的人合作，他们会把文章发到我的网站上，因为我这些天主要的工作是把好文章发到我的网站上，我的观点是，我不是写这些东西的最佳人选，因为我没有做日常的生产工作。我已经很久没有做了。我唯一写的生产代码就是运行网站的代码，这很有讽刺意味。我仍然写代码，我仍然生成堆栈跟踪，但它只在这个非常非常晦涩的小领域内。因此，对我来说，最好是与那些真正从事这类工作的人合作，帮助他们表达他们的想法和经验，并尽可能多地传达给尽可能多的人。所以，我通过与人们合作写下他们的想法来学习，这是一种非常有趣的学习方式，因为当然，你在编辑过程中会非常深入地参与其中，而这就是我的主要形式。我确实会做一些实验，当我有机会的时候，虽然不像我希望的那样多，但我确实认为这是我的第二优先事项，仅次于与人合作。所以，你知道，只有在我能抽出时间的时候，我才会这样做。嗯，当然，从我认为的一些更好的来源阅读。我的意思是，幸运的是，其中一个更好的来源是 Bita，他一直在和我一起写作。所以，这很好。Simon 他很棒。是的。Spittita 的东西很棒。我一直关注 Simon Willis 在做什么。我希望我能有他的精力来发布东西。实际上，我希望我能有你的精力，你现在发布的东西太多了。所以我寻找这样的来源。我一直对 Kent 这样的人在做什么很感兴趣，因为说实话，我的职业生涯很大程度上是依赖于 Kent 的想法，而且，如果它仍然有效，就没有理由停止这样做，对吧？所以，这些就是我寻找的来源。有时也会有一些书出来，然后我也会看一看。所以，很多都是朝着这个方向。我偶尔也会看视频，尽管我真的很讨厌看视频。所以，是的。听起来就像是找到你信任的人，你信任的来源。再次，你的博客我强烈推荐，因为你有几个人在上面写作。所以，你实际上有很多关于有趣话题的深度文章，我很少看到有话题被深入讨论，所以我很喜欢查看，因为这个。我的意思是，我一直在思考的一个问题是，当被问到，你如何识别一个好的信息来源？这更普遍，这是由于我们的职业，当然也是由于整个世界，因为我们似乎正处于一个认识论危机中，试图理解世界上正在发生什么。总有一天我会坐下来写下来，我会从中得到一个更连贯的答案，但我的一个一直在寻找的东西是，不确定性我认为是一件好事。当人们告诉我，哦，我知道答案时，我通常会更加怀疑，而且我更加意识到当人们说，这是我目前理解的，但它相当不清楚。我记得我早期最喜欢的书之一，当我写关于软件架构时，我记得我拼命地在微软世界里寻找东西，而不是在 Java 世界里。那是在 90 年代末。Java 世界里有很多东西在写，微软世界里不多。当我发现这个瑞典人 Jimmy Nielson 时。他的书里充满了这样的内容，他说，这就是我对这个东西的看法，这就是处理这些东西的方法。他总是很谨慎，非常清楚这是他当时的感受，但他明白事情可能会改变。我后来和 Jimmy 认识了，他是个很棒的人。但让我印象深刻并影响我如此之深的是，我感觉到了这种程度，哦，这是我能信任的人，因为他们没有试图给我这种虚假的确定性和自信感，我认为这也很重要，而且有人热衷于探索细微差别，并说，嗯，这在某些情况下是有效的，而不是有人告诉我，哦，你应该总是使用微服务，或者有人说你不应该使用微服务。我的意思是，这两种论点都可以完全忽略。当你说，“啊，这些是你应该考虑的因素，是选择这个方向还是那个方向。”当有人退一步说，“啊，这是一个权衡。有各种各样的事情涉及。这是你应该考虑的因素。”它不会有一个简单的答案。你必须深入研究细微之处。然后，这又增加了我的信心，因为我又觉得，这个人正在认真思考这些问题，而不是仅仅走上了一条简单的轨道。我想，通过这些来源，你也可以相信，我们在软件工程中所做的一切，都会有权衡，对吧？最常见的答案是，它需要多长时间？这取决于。这取决于我们是在做一个原型，这取决于我是否了解技术等等。所以，如果你在阅读来源，或者你正在访问来源，他们告诉你，在我的情况下，你实际上了解他们的情况，你可以弄清楚，好吧，在他们这个特定的案例中，这个有效或无效，稍后你可能会更好地应用它，因为再次，如果你要在一家拥有 70 年历史的高度管制的零售商那里担任软件工程师，与你刚刚创办一家全新的初创公司，零客户，这有很大的不同。是的。然后，再次，你看到了，我的意思是，我们经常看到客户说，给我们答案，给我们食谱，直接的答案，我只需要应用。如果你在寻找那种食谱式的答案，你就会遇到麻烦，因为任何告诉你有一个食谱答案的人，他们要么不理解，要么故意对你隐瞒，因为总是有大量的细微之处。我们一直在回到这个，现在已经超过 50 年的艺术，没有银弹。一个在线问题，我问人们想问你什么，你今天对初级软件工程师有什么建议？有很多人工智能的东西在进行，我们知道，关于学习，我认为你也提到过，或者可能是 Umesh 提到的，对于初级工程师来说，如果你过度依赖人工智能，这可能会阻碍你的学习，因为学习很重要。如果这些工程师中的一个问你，“嘿，我是一名初级工程师。我想最终成为一名更有经验的工程师，你有什么策略可以建议我，尤其是在人工智能工具方面？我应该依赖它们吗？不应该吗？有没有什么可能比其他事情更好？”嗯，当然，我们必须使用人工智能工具并探索它们的使用。如果你是初级的话，难点在于你没有一种感觉，就是我得到的输出有多好，在很多方面，答案和以前一样：找到一些好的高级工程师来指导你，因为这是你学习这些东西的最佳方式，一个好的有经验的导师是无价的，事实上，在很多方面，它比你职业生涯中的许多其他事情都更重要，那就是获得指导。我的意思是，再次，我在职业生涯早期找到 Jim Odell 是非常有价值的。对我来说，最幸运的事情就是纯粹的运气。但是，寻找这样一个人来指导你。我的意思是，虽然我们在某些方面是同龄人，但我经常认为 Kemp Beck 是我的导师。因为，你知道，我们可能年龄相同，但他的思维总是向前跳跃。所以，观察他所做的非常有价值。所以，再次，找到一个像他这样的人。人工智能可能很有用，但永远要记住，它是容易上当的，而且很可能会骗你。所以要对它进行探究。为什么给我这个建议？你的来源是什么？是什么让你这么说？我记得，这通常是一件好事，每当人们给你一些东西时，都要说是什么让你这么说？背景是什么？你来自什么背景？是什么让你得出这个观点？通过探究这一点，你可以更好地理解他们来自哪里。而且，我认为你必须对人工智能做同样的事情，因为最终，人工智能只是在重复它在互联网上看到的东西。所以问题是，它在互联网上看到了好东西，还是看到了互联网上大部分的垃圾，对吧？但是，如果你能找到好东西，那会更有用。在看到人工智能、大型语言模型所有这些变化时，你对整个科技行业有什么感觉？嗯，从广义上说，我是积极的，因为我仍然觉得科技和软件有很多巨大的事情可以做。而且，我们仍然处于需求远远超过我们想象的情况。但这是长远的看法。我的意思是，目前我们正处于一个非常，我将说非常，生活一直是一个奇怪的阶段。我的意思是，在不同方面都很奇怪。目前的奇怪之处在于，我们基本上处于一个巨大的，尤其是在发达国家，我们正处于一场萧条之中。我的意思是，我们已经看到了大量的裁员。我的意思是，我听说过几十万、几十万的工作岗位流失。我的意思是，就是那种规模。我的意思是，我们看到了。我的意思是，在 Fort Works，我们过去每年都以 20% 的速度增长，直到大约 2021 年。我的意思是，我们已经，我们已经，我们已经撞墙了，我们看到我们的客户不再花钱在这些东西上。我的意思是，人工智能正在做它自己的事情，但它几乎是分开的，而且它显然是一个泡沫，但我们不知道。但泡沫的问题在于，你永远不知道它会增长多大。你不知道它会在什么时候破裂。你也不知道破裂后会发生什么。我的意思是，所有这些事情都是不可预测的。我认为人工智能有价值，就像区块链和加密货币没有价值一样。人工智能肯定有东西，但确切的会如何发展，谁知道呢？我的意思是，我经历过 90 年代和 2000 年代的这个周期。所以，这只是一个重复，但规模可能大了一个数量级。所以，所有这些都在发生，但实际上发生的最重要的事情不是人工智能。是零利率的终结。这是真正打击我们的重要事情。而这才是工作岗位的流失在人工智能之前就开始了，因为这个原因。而且我们不知道这会如何改变，因为这是一个更宏观的经济问题。在美国，我们有卢尼在掌舵。我们在国际上也有各种各样的压力。目前存在巨大的不确定性，这对我们产生了影响，因为这意味着企业没有投资。而当企业不投资时，软件世界就很难取得多大进展。所以，我们有一个奇怪的组合，几乎没有投资，软件行业一片萧条，同时又有一个人工智能泡沫。而且它们同时发生。而在另一端，是的，这取决于你在哪里。就像我在硅谷，如果你是一家人工智能公司，一切看起来都很棒。如果你在外面，你可以从中受益，但它更加谨慎。如果你不在这个泡沫之外，比如说你在一家初创公司，或者一家不是人工智能的公司，那会很艰难。所以，你看到了这些世界正在发生。我的意思是，我认为，这仍然是一个未来潜力巨大的行业。我认为这是一个不错的行业，值得进入。它不像，你知道，在 2005 年进入这个行业那样好的时机。但是，你知道，我仍然觉得这里有一个很好的职业。我认为人工智能不会消灭软件开发。我认为它会以一种真正明显的方式改变它，就像从汇编语言到高级语言的改变一样，但核心技能仍然存在，而且在我看来，成为一名优秀的软件开发者的核心技能仍然是，不仅仅是写代码。那是技能的一部分。很多技能是理解写什么，那就是沟通，尤其是与软件用户沟通，以及跨越那道鸿沟，那一直是至关重要的沟通路径。你还提到专家通才变得越来越重要，所有这些细节，我会在节目笔记中链接，我想那篇文章又是，嗯，Umesh 一直很火，他很火，但所有这些特质似乎都与人工智能无关。它关乎好奇心。它关乎深入。它关乎广泛。它听起来就像我听到越来越多的人在思考，成为一名杰出的软件工程师意味着什么。基础知识似乎没有改变，对吧？是的。而且，我认为，而且一直以来，沟通和能够有效地与人合作，一直是我认为真正造就最优秀的开发者的杰出品质。尤其是在企业商业世界中，这是我最熟悉的，因为我们编写的所有软件都是为那些做与我们截然不同的事情的人准备的。我记得当我还在医疗服务部门工作时，我总是说，你知道，我在这里进行医疗保健的概念建模。我非常了解医疗保健的过程。你不会想让我治疗你的任何医疗问题，因为我永远不会拥有那种技能，因为我不是医生。是的。因此，医生必须参与到这个过程中。所以，作为结束，我想做一些快速提问，我提出问题，然后你给出你脑海中浮现的答案。你最喜欢的编程语言是什么？为什么？嗯，我得说，目前我最喜欢的编程语言是 Ruby，因为它已经变得，我非常熟悉它，我使用它已经很久了。但我的挚爱是 Smalltalk，毫无疑问。Smalltalk。在我能够使用 Smalltalk 的 90 年代，编程就像 Smalltalk 一样有趣。那是一个如此棒的环境。你和 Kenbeck，Kenbeck 正在编写他的 Smalltalk 服务器。这是他的宝贝。我认为他正在取得进展。而且，我的意思是，仍然有一些事情在进行。有 Smalltalk 的 Pharaoh 项目。我一直在想，你知道，如果我能抽出几周时间，停止我正在做的其他所有事情，也许可以调查一下，再次看看 Smalltalk 世界里发生了什么，因为它曾经，我的意思是，而且仍然拥有如此强大的语言。你会推荐一两本书？为什么？所以，我特别喜欢推荐的一本书是丹尼尔·卡尼曼的《思考，快与慢》。我喜欢它，因为它很好地试图让你对数字产生直觉，并发现我们在思考概率和统计时犯的许多错误和谬误。这在软件开发中很重要，因为我的意思是，我们所做的很多事情都得到了极大的增强，如果我们能理解我们所看到的事物的统计效应，而且在生活中也是如此，因为我认为，如果更多的人对概率和统计有更多的了解，我们的世界会好很多。比他们现在了解的要多。我的意思是，我喜欢大多数孩子在学校学数学时，它主要是基于微积分的。我真的觉得，如果，你知道，它更多地基于统计学，那会好得多，因为能够使用它的知识。嗯，我的意思是，帮助我更多地理解概率和概率推理的事情是，我非常喜欢桌面游戏，在这些游戏中，你必须不断地从概率的角度来思考，而且，我真的觉得知道这一点很重要，而这本书我认为是一个很好的入门方式，所以它是我过去几年读过的最好的书之一。另一本我将要提到的书，完全不同，而且在挑战方面也完全不同，我一直非常着迷的是一本名为《权力掮客》的书。所以，这是一本关于一个叫罗伯特·摩西的人的书，大多数人从未听说过他，但他在纽约市最有权势的官员长达 40 年，大约从 1920 年代到 1960 年代。他从未当选过任何职位。他控制的资金比当时的纽约市长或州长还要多。这本书讲述了他如何崛起。权力在民主社会中是如何运作的，通常不是公开的。而且这本书非常迷人。它也写得非常出色。有些时候，我只是，你知道，我读了几页，我不得不停下来，只是欣赏我刚刚读到的内容有多么出色。这很有价值，因为要成为一个更好的作家，我认为我们都能从成为一个更好的作家中获益，阅读真正优秀的写作非常重要。他的写作是杰出的。缺点是它有 1200 页。这是一本非常长的书，但我读得非常享受，所以我并不介意。然后，一旦你从那里继续，你就会转向他的第二本传记，因为他只写了两本传记，那就是他目前五卷本的林登·贝恩斯·约翰逊（LBJ）的传记，同样出色，我一直在读，但要求更高，因为到目前为止有四卷，他还没有完成第五卷。但同样，有些时候，我只是因为写作的精彩程度而目瞪口呆，也因为权力在民主社会中的运作方式而目瞪口呆，而且我认为要理解我们的世界是如何运作的，这类书籍真的非常有价值。最后，你能推荐一个棋盘游戏吗？你非常热衷于棋盘游戏。你的网站上也有一个列表。是的，这有点棘手，因为这就像说我对看电影很感兴趣。你会推荐哪部电影？因为我明白。有太多的口味和事物。如果我要选择一个我认为不太复杂，容易上手，而且我认为仍然有相当多丰富性的游戏，那么我会选择一个叫做 Concordia 的游戏。它的本质相当抽象，但很容易上手，而且在过程中有相当多的决策。马丁，非常感谢你。很高兴我们能亲自见面。是的，这真的很好。我碰巧在阿姆斯特丹有别的事情，我知道阿姆斯特丹有人，所以我想联系一下，我们终于有机会面对面见面了。太棒了。谢谢。非常感谢马丁进行这次有趣的对话。让我印象深刻的一件事是，人工智能带来的最大变化是如何从确定性系统转向非确定性系统。这意味着我们现有的软件工程方法，这些方法是基于假设一个完全确定的系统，比如测试、重构等等，这些可能不太好用，我们可能需要新的方法，除非我们能让一些元素更加确定。也就是说，我也喜欢马丁提到的关于代码辅助的问题，当你停止关注生成代码时，你就停止学习，然后你就停止理解，你最终可能会得到你完全不理解的软件。所以，在你对这种权衡感到满意的情况下要多加注意。有关人工智能工程最佳实践的更多阅读以及对过去 50 年软件工程领域如何变化的概述，请查看 Pragmatic Engineer 中相关的深度探讨，这些内容将在下面的节目笔记中链接。如果你喜欢这个播客，请在您喜欢的播客平台和 YouTube 上订阅。这有助于更多人发现播客，如果您留下评分，我们将特别感谢。谢谢，下次再见。