代码质量还重要吗？取决于这四个因素 | Max Kanat-Alexander，Capital One

简要说明Brief Description

代码质量仍然重要吗？这取决于这一点——Max Kanat-Alexander，Capital OneDoes Code Quality Still Matter? It Depends on This — Max Kanat-Alexander， Capital One

目录Table of Contents

• “这取决于”——取决于什么？
  "It depends" — on what?
• 理解与执行
  Understanding and execution
• 为什么结构很重要
  Why structure matters
• 每项变更的两种风险
  The two risks of every change
• 一次性软件
  Disposable software
• 耐用的软件
  Durable software
• 让软件更易于弃用
  Making software more disposable
• 降低严谨性的成本
  Lowering the cost of rigor
• 答案
  The answer

“这取决于具体情况”——取决于什么？"It depends" — on what?

所以，今天我想，干脆挑个不错的、毫无争议的话题，反正没人对此有什么看法。对吧？你知道，社交媒体上根本没人提过这事。当然，社交媒体上关于这件事的各种观点都特别有深度、特别 nuanced——你知道，人们想得可深了，脑子里全是各种重大见解。So, today I figured I'd just pick a nice uncontroversial topic that nobody has any opinions about. Right? Nobody said anything about this on social media, you know, and of course every take about this on social media is like really deeply nuanced, you know, like people have lots of like depth and like, you know, really big thoughts.

你知道，也许事情并不只是简单的是或否。当然，如果你问一位资深工程师问题，我们对所有问题的回答总是一样的——每位资深工程师最喜欢的答案就是：这得看情况。不过坦白说，这并不是一个很有帮助的答案，因为到底得看什么呢？You know, maybe there's a little bit more to it than like yes or no. And you know, of course if you ever ask a senior engineer a question, we always have the same answer to every question, every senior engineer's favorite answer to every question, which is it depends. Now, that's not a very helpful answer though, frankly, because what does it depend on?

那么，我们从这里开始吧。代码质量一开始为什么会重要？我看到很多人会说：“嗯，这让我感觉很好。”So, let's start with this. Why did code quality ever matter in the first place? Like I see a lot of people be like, well, it made me feel good.

这并不是一个充分的理由。所以，我们看看能否为这场讨论增添一些细微差别，帮助大家至少在讨论时有据可依。That's not really a sufficient justification. So, let's see if we can inject some nuance into this conversation and help everybody at least be able to have a basis for reasoning about it while we're discussing it.

理解与执行Understanding and execution

那么，我们来看看能不能在这里建立一个框架。这就是我们这次演讲要尝试做的事情。好。So, let's see if we can make a framework here. That's what we're going to try to do with this talk. Okay.

所以，我们先从一个基本点说起：你想通过软件实现的任何目标，都只取决于两个因素，而且仅仅是这两个因素：理解，以及基于这种理解采取行动。无论是让模型与目标保持一致、扩展系统规模，还是推动用户采用，都是如此。软件能否成功，完全由这两个因素决定。So, we're going to start off with everything you want to ever accomplish with a piece of software depends on two factors and two factors alone. And that is understanding and executing on that understanding, whether that's aligning a model, scaling a system, driving adoption, anything. All software success is determined by these two factors.

这就是为什么我们会有调试器、可观测性、评估，甚至测试。所有这些东西实际上都是为了加深你的理解，或者提升你基于这种理解采取行动的能力。人们以为它们有其他用途，但归根结底，它们存在的原因就是这个。This is why we have things like debuggers and observability and evals and even tests. All those things actually are there to improve your understanding or ability to execute on that understanding. People think that they're there for other reasons, but fundamentally they're there for that reason.

我们在代码质量领域所做的一切，始终都只是为了这两件事。Everything we have ever done in the field of code quality is exclusively and only for these two things.

它不是用于其他任何事情。它与正确性或其他什么无关，只与这两件事有关。It's not for anything else. Not doesn't have something to do with correctness or something else. It has to do only with these two things.

如果你想成为一名软件工程师，有两种理解是最重要的。如果你要做产品或从事销售工作，也需要对软件有其他方面的理解；但如果你是软件工程师，最重要的就是这两点。第一，系统的行为是什么？Now, there's two understandings that are the most important to have if you're going to be a software engineer. There are other understandings to have about software if you're going to be a product, if you're going to be in sales, but if you're a software engineer, there's the two that are the most important. And the first is what is the behavior of the system?

比如，具——具体地说，不是文档说系统的行为是什么，而是系统实际的行为是什么？第二个问题是，我怎样才能正确且安全地修改这种行为，好吗？对于一个非常小的系统，如果你想了解它做什么，我直接告诉你它做什么。Like con- the concretely, not what does a doc say the behavior of the system is, but what is the actual behavior of the system? And the second one is how do I correctly and safely modify that behavior, okay? On a very small system, if you want to understand what the system does, I just tell you what it does.

它会打印“hello world”。你说：“我想让它说‘hi world’。”我说：“好的，我现在就让它说‘hi world’。”It prints hello world. You say, "I want it to say hi world." I say, "Okay, I will make it say hi world now."

为什么结构很重要Why structure matters

除了它具体做什么之外，几乎没有其他需要理解的。你只需要了解这些就够了。然而，任何真正的软件系统都极其复杂。There's very little to understand about it other than purely what it does. That's all of the understanding that you need. However, any real software system is enormously complex.

这是一张 Chromium 代码库的真实地图。Chromium 是 Chrome 背后的开源项目。想想这些组件之间可以互动的各种方式，它们本质上可能产生无限种行为。比如，我无法用语言向你描述 Chromium 作为一个整体系统的行为。This is a real map of the code base of Chromium, which is the open-source project behind Chrome. And if you think about all of the different ways that these components can interact, they have essentially infinite possible behaviors. Like, I could not describe to you in words the behavior of Chromium as a whole as a system.

不过，我能向你描述的是，正如我们都知道的，大家都已经做了一段时间的软件工程师了，我可以向你描述系统的各个组件。我可以准确地描述系统中某个组件的行为。比如，这是 Chromium 的 URL 解析器，以及它的实际函数等内容。However, what I can describe to you, and as we all know, everybody's been a software engineer for a while, I can describe to you components of the system. I can successfully describe to you how a component of the system behaves. So, this is the URL parser, the actual functions and stuff for the URL parser of Chromium.

它会解析 URL 的各个组成部分。这就是这段代码存在的全部原因。我们最初之所以要编写代码，根本原因就是为了构建结构。It figures out all the different parts of the URL. And this is the whole reason that code exists. The whole reason that we have code at all in the first place is for structure.

我这是什么意思？好吧。也就是说，左边和右边这两个东西在 Linux 机器上运行时都会打印 Hello World。What do I mean by that? Okay. So, both of these two things on the left and on the right will print Hello World if run on a Linux machine.

不过，在左侧，你可以看到它是“Hello World”。它具有“Hello World”的身份和结构。而在右侧，你只会看到一系列指令，没有任何特定的、可识别或可理解的身份。However, on the left, you can see that it is Hello World. It has the identity and structure of Hello World. On the right, you just see a series of instructions with no particular identity, recognizable or understandable identity.

它不是一个组件，只是一堆指令。在那里，这样做还可以理解；但如果这样的内容有数百万甚至数十亿行，就会难以理解得多。过去，我们谈过可读性、可测试性之类的东西，或者一些看起来像是关于代码的人类概念的东西，但实际上最重要的一直是，系统要有某种易于理解的结构。It's not a component, it's just a bunch of instructions. While that's understandable there, if that was millions or billions of lines of that, it would be much harder to grok. In the past, we've talked about things like readability or testability or things that seemed like human concepts about code, but what actually mattered the most always was that the system had some sort of understandable structure.

每次变更的两种风险The two risks of every change

所以，真正重要的是结构。当你想修改系统时，这一点尤为重要，也就是我们谈到的第二种理解。对系统的所有修改都伴随着两类风险。So, it's the structure that actually matters. It matters most when you want to modify the system, the second understanding that we talked about. All modifications to a system carry two categories of risk.

首先，你要引入某种问题。问题不只是 bug，而是任何可能发生的不良情况。比如，你的项目可能会比预期花费更长时间，也可能无法按照你希望的方式为用户提供服务。The first is that you will introduce some sort of problem. And a problem isn't just a bug, it's anything bad that could happen. Like your project could take much longer than you expect. it could not behave in the way that you wanted it to for your users.

项目可能会因预算超支而失败。仅仅是尝试推进这项变更的过程，就可能出现各种问题。第二个风险是，这可能会让今后的变更更难实现。The project could fail because you have budget overruns. Any kind of problem could happen from just you trying to go through the process of making this change. And the second is you could make it harder to make future changes.

具体来说，这意味着你可能会让它将来更容易出现问题，也可能增加系统未来面临的风险。这两件事都是由理解方面的问题造成的。In particular, what that means is you can make it more likely to have future problems. You could increase future risk of the system. These two things are caused by problems with understanding.

所以，第一个因素关乎一开始理解系统有多困难；第二个因素则是你让系统变得更难理解。我读过的所有事故复盘，都可以用某种方式归结为这两个因素：生产环境配置太难理解，有人把某些东西弄得让人无法理解，系统存在无法理解的涌现特性，诸如此类。So, the first has to do with the difficulty of understanding the system in the first place, and the second is you make the system harder to understand. I can reduce every postmortem I have ever read for any incident to these two factors in one way or another. The production configuration was too hard to understand, somebody made something impossible to understand, there were emergent properties of the system that were impossible to understand, whatever.

第二点会反馈到第一点，形成恶性循环，并以非线性的方式不断累积。因此，理解上的难度并非线性增长，而是会随着时间推移不断叠加。最终你会达到某个临界点——所有系统最终都会趋于这个临界点——到了这时，每次修改都会引发某种问题。你知道，有些系统甚至会变成这样：你根本没法修改它们。比如说，那些有着一亿、五亿行代码的大型主机代码库之类的，到了那种程度，每一次改动都会带来某种问题。Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion. So, the difficulty of understanding does not grow linearly, it compounds over time. You will eventually reach a point, and all systems eventually tend to reach this point, where every modification involves some sort of problem. and you know, some systems get to the point where like you can't modify them at like if you think of like, you know, some of like your giant 100 million 500 million line mainframe code bases and that everything, every change is some sort of problem.

你知道，你会在组织问题中看到它，在各处都能看到它，在时间线上也能看到它，诸如此类。听着，很多人都在争论未来的模型也许能解决这个问题。听着，也许它们能做到。也许未来的模型会以某种方式拥有无限处理复杂性的能力。但我们今天不必讨论这个，因为我认为模型现在正在做另一件非常有趣的事。You know, you'll see it in organizational issues, you'll see it all over the place, you'll see it in timelines, whatever. And look, there's a lot of arguments about maybe future models will fix this. Look, maybe they will. Maybe future models will have infinite ability to deal with complexity somehow. but we don't have to discuss that today because I think models are doing something else really interesting right now.

一次性软件Disposable software

他们正在创造一种全新类型的软件，一个全新的软件类别。这个类别一直以来都存在，但它即将变得比其他任何形式的软件普遍十万倍。这就是一次性软件。They are creating a new kind of software, a new category of software. This category has always existed, but it's about to become a hundred thousand times more common than any other form of software. And that is disposable software.

那么，那是什么？好吧，想象这样一个世界：你的系统即使失败，后果也微乎其微，甚至不存在。So, what is that? Okay. So, imagine a world in which the consequences of failure for your system are very minimal or non-existent.

设想依赖它的人寥寥无几，几乎没有其他系统依赖这款软件。变更管理少之又少，甚至不存在。再设想，替换成本降到了接近于零。Imagine that there's very few people that depend on it or and almost no other systems depend on that piece of software. Change management, very minimal, non-existent. Imagine the cost of replacement went to near zero.

你可以在几小时或几天内把整套东西替换掉，而且几乎没有维护成本。在那种情况下，代码质量并不重要。You could replace the whole thing in hours or days. And it had basically no cost of maintenance. In that world, code quality does not matter.

因为随着时间推移，我们一直试图防止的那些风险不断累积的情况并不存在。Because it all of those things we were trying to prevent about the compounding risks over time don't exist.

经久耐用的软件Durable software

传统上，我们一直致力于构建经久耐用的软件。你知道，它能运行多年，受到数百万甚至数千人的依赖。Traditionally, we've always built durable software. You know, it lives for years. It's depended on by millions or thousands of people.

失败的后果极其严重，甚至可能对业务造成灾难性影响。而且，这类系统需要投入大量精力进行维护。世界上大多数软件工程师都把大部分时间花在维护这些庞大且长期运行的系统上。There's huge consequences of failure, potentially business catastrophic consequences of failure. And it requires enormous maintenance. Most of the software engineers in the world spend most of their time maintaining these giant durable systems.

我预计这种情况会继续存在。所以，我认为这是有时会让讨论稍微偏离正题的领域之一，好吗？持久化系统很可能会继续成为世界上最重要的系统。I expect this to continue to exist. So, this is one of the areas where I think sometimes the conversation goes a little astray, okay? Durable systems will continue to probably be the most important systems in the world.

而且这类系统可能还会更多。但数量最多的将是一次性软件系统。它们可以在几小时内被替换。And there will be probably more of them. But the most numerous systems will be disposable software. They will be replaceable in hours.

少数人会依赖它们，否则变更管理就毫无意义了。They will be depended on by a few or change management just won't matter.

你看，如果这行不通，你就给每个人都配上智能体。他们会自己做出一个版本。维护就无关紧要了，或者几乎不花钱。And look, if it doesn't work, you will give everybody agents. They'll make a version of it themselves. You know, maintenance will be unimportant or nearly free.

不喜欢操作系统自带的计算器？那就自己做一个。想为孩子们策划一场派对吗？Don't like the calculator on your OS? Make your own. Want to plan a party for your kids?

编写一款只用于那场派对的派对策划软件。用完就扔掉。代码质量无关紧要。Write a party planner software just for that one party. Throw it away. Code quality doesn't matter.

没人关心。未来，我们会根据软件的可丢弃程度，采用相应的工程严谨性。左边什么也没有。Nobody cares. In the future, we will apply engineering rigor to the degree of disposability of the software. On the left, nothing.

我们的工程严谨性实践都完全无关紧要。而在右侧，我们过去几十年来积累的所有工程实践都至关重要。我们可以根据我一直在谈的这四个因素，确定你处在这个尺度上的什么位置。None of our practices of engineering rigor matter at all. On the right, all the practices of engineering that we have built up over the last many decades matter greatly. We can determine where you are on this scale by those four factors that I have been talking about.

后果、更换成本、依赖关系和维护成本。Consequences, cost of replacement, dependencies, and cost of maintenance.

如果这些指标都很低，那就是一次性软件；如果都很高，那就是经久耐用的软件。你看，任何长期编写软件的人都知道，应该尽量让软件更经久耐用。你应该尽量把这些指标设得比预期更高。If they're all low, it's disposable software. If they're all high, it's durable software. And look, any person who's written software for a long time knows you should err on the side of it being durable. You should err on these all being higher than you expect them to be.

让软件更具可替换性Making software more disposable

不过，现在还有一件新事可以做：你可以让软件变得更一次性。所以，嗯，这具体包括什么？But, there's also a new thing you can do in the world. You can make software more disposable. So, like, what do What does that involve?

嗯，设计出更好的隔离环境，对吧？也就是说，你只能部署到这样一个环境中，而且它只能访问你自己的数据。不包含客户数据，也不包含任何个人身份信息之类的。Well, come up with better isolated environments, right? So, hey, you can only deploy to this environment that has access to only your data. No customer data, no personally identifiable information, whatever.

你可以强制实现独立性。你可以说：“好，在这个环境中，不允许其他生产系统通过 API 调用这个系统，对吧？”因此，部署到该环境中的所有内容都是可随时弃用的。冗余。You can enforce independence. You can say, "Okay, no inbound API calls from other production systems are allowed to this system in this environment, right?" And so, everything deployed to that environment is disposable. Redundancy.

你可以有一个老旧、笨重、用起来很费劲的备份系统。然后你看，如果有人想用氛围编程给自己做个更高效的前端，那就让他们去做，因为还有一个老旧但可靠、笨重的备份系统可以用，万一他们那个糟糕的小氛围编程作品出了问题，也还有它兜底。You can have an old clunky backup system that is like hard to use. And then, like, look, if people want to vibe code their own like more efficient front ends, you let them vibe code their more efficient front ends because there is an old durable clunky backup system that they can use if their, you know, crappy little vibe coded thing fails.

这会失败，对吧？没关系。不过，它失败与否并不重要。你也可以限制作用域，就像我刚才说的那样，对吧？Which will fail, right? That's fine. But, it doesn't matter if it fails. and you can limit scope, just like I talked about, right?

这只是给一个人用的计算器，也只为这一场派对做计划。我们还可以在这方面做更多事，探讨如何提高一次性使用的程度。It's just a calculator for this one person. It just plans this one party. There's so much more we could do here and talk about ways of increasing disposability.

事实上，我认为这是软件工程中的一个全新领域：我们不再思考如何提高持久系统的严谨性，而是思考如何改造我们的系统，鼓励或允许它们更容易被弃用，让人们可以把这些东西扔掉。这想法很有意思。现在，我想再次强调，持久型软件工程并不会消失，因为这是我如今在社交媒体上看到的最大误解。In fact, I think this is a whole new discipline of software engineering, not to think about how we improve the rigor of durable systems, but how do we take our systems and how do we encourage disposability or allow more disposability, allow people to throw these things away. Interesting thought. Now, I want to re-emphasize that durable software engineering is not going away because this is the biggest confusion that I see on social media today.

事实上，我相信世界上耐用软件的绝对数量会不断增加，因为 AI 编程工具让开发更多耐用软件变得越来越容易。In fact, I believe the absolute amount of durable software in the world will increase because AI coding tools make it easier and easier to make more durable software.

另一个需要理解的重要事项是，一次性和持久性并非非黑即白。它们之间存在一个连续的光谱，就像我之前展示的那样；而在这个光谱上变化的是你要投入多少工程严谨性。好吗？这既包括眼下投入的精力，也包括长期投入的精力，就像我们一直以来讨论软件时所说的那样。And another important thing to understand is that disposable and durable are not black and white. There's a spectrum, like I showed before, but that spectrum what changes across the spectrum is how much effort you're going to put into engineering rigor. Okay? And that's both immediate effort and effort over time, just like we've always talked about for software.

降低严谨性的成本Lowering the cost of rigor

不过，你想做的事情——我认为你最关心的事情——是降低付出的成本，降低严谨的成本。也就是说，如果严谨起来的成本更低，做到严谨越容易，你就越不必担心自己处于这个尺度上的哪个位置。所以，这是你可以采取的另一种方法。However, what you want to do, and I think what you want to care about the most, is reducing the cost of effort, reducing the cost of rigor. Like, if rigor is cheaper, the easier and easier you make it to be rigorous, the less you have to worry about where you are on the scale. So, this is another approach you can take.

如果你改变主意了，就更容易说：“哦，我原以为这是一次性的，结果现在它需要经久耐用。”让它具备耐用性所需的成本越低，你就越容易改变主意，或者承认自己判断错了，因为你对这项估算不可能总是百分之百正确。所以，这需要一套不同的实践；这些实践本身并不是工程严谨性，而是关乎如何降低实现工程严谨性的成本。If you change your mind, it's much easier to go like you're like, "Oh, I thought this was going to be disposable and now it needs to be durable." The cheaper you make it to make it durable, the easier it is to change your mind or to be wrong because you're never going to be 100% right all the time on that estimate. So, that involves a different set of practices that are not engineering rigor themselves, but that are about how to decrease the cost of engineering rigor.

现在，我可以就此谈上好几个小时。我职业生涯中花了大量时间做这件事。但我没有10个小时。Now, I could talk about this for hours. I have spent a tremendous amount of my career doing this. I don't have 10 hours.

那个计时器大约还剩 5 分钟。所以，我能讲多少就讲多少，好吗？我们来谈谈标准化。I have about 5 minutes left on that timer. So, I'll talk about what I can, okay? Let's talk about standardization.

我们为什么要做标准化？有人会说：“嗯，我也不知道，因为老板这么说。”其实，我们做标准化是为了减少各种可能性。如果你的系统里没有 PHP，你就不必去弄清楚 PHP 有哪些代码检查工具、有哪些最佳实践，也不必操心有哪些安全漏洞需要修复。Why do we do standardization? People are like, "Well, I don't know because the boss said so." Well, now, we do standardization because it removes possibilities. If you don't have any PHP in your system, you don't have to figure out what are all the linters for PHP, what are all the practices, what are all the security holes I have to fix.

你只要通过标准化排除各种可能性，就能降低保持严谨的成本。框架也是一样。比如，为什么不想把现存的每一种前端框架或后端框架都用上呢？You just eliminate possibilities through standardization and it just reduces the cost of rigor. same thing with like frameworks. Like why don't you want to have every front-end framework or every back-end framework in the in existence?

因为这会让严谨变得更昂贵。没错，严谨依然做得到。没错，你仍然可以让智能体为你所有的工具编写代码，但每次都得这么做。你懂的，协议之类的。Because it makes rigor more expensive. Like yes, rigor is still possible. Yes, you could still have the agent code up all your tools, but you have to do it every single time. you know, protocols.

为什么要采用标准化的 RPC 协议？它们本质上都是同一回事。制定标准就是为了这个原因。Why do you want to have standardized RPC protocols? All the same thing. Standards are all for this reason.

好吧？我把它称为内向流工具。也就是说，内向流工具会自动运行，程序员不必选择是否运行它。Okay? what I call inward flow tooling. So, inward flow tooling is tooling that just occurs. The programmer doesn't have to choose to run it.

他们不必了解它是如何运行的。它就是自然而然地发生了。只要它存在，就会让人感觉似乎是免费的，而且可靠。They don't have to understand how it runs. It just happens. If it's there, it feels and seems free and it is reliable.

可靠性非常非常重要。它的误报不多，而且速度快。Reliability is very, very important. Like it doesn't have a ton of false positives. It's fast.

这种事就是会发生。而且这越是成立，你也越可以把它用到那些一次性软件上。如果免费又快，谁会在乎呢？It just happens. And the more that's true, like you can apply it to your disposable software, too. If it's free and fast, who cares?

让测试变得更容易。所以，这不仅仅是“嘿，我们怎样才能把测试做得更好？”你看，关键是怎样才能让大家都不必费心思考如何改进测试？怎样才能让每项测试都快速且结果可预测，而不需要任何人成为测试领域的专家？making testing easier. So, this is not just about like, "Hey, how do we do better testing?" Look, how do you make it so that nobody has to think about how to do better testing? How do you make it so that every test is fast and deterministic without anybody having to be a deep expert in testing?

要实现这一点，你得在测试基础设施上投入大量工作。比如说，作为测试负责人，我一直有一个很棒的梦想：每个人都能提供自己服务的内存版模拟实现，而我只要运行这些内存版模拟服务就行。猜猜怎么着？There's a ton of work that you have to put into test infrastructure to make that possible. For example, you know, one of the great dreams that I've always had as a test owner is that everybody would provide in-memory fake versions of their services and I could just run those in-memory fake versions of their services. Guess what?

编码代理可以做到这一点。所以，你现在就可以直接这么做，对吧？但你得主动选择去做，并让所有人都能使用。The coding agent can do that. So, you can just do that now, right? But you have to choose to do it and make it available to everybody.

还有一点，听着，要做到最严格。And another thing is, look, maximum strictness.

你只是在所有地方都提高了严格程度。你把所有 lint 规则都设为最高级别。你从不做任何妥协，结果只是让对话无法进行。You just turn the strictness up everywhere. You set all your lint rules to maximum. You never compromise on anything and it just eliminates conversations.

这与标准化非常相似。它能省去大量讨论。有时候，lint 检查也会出错。It's very similar to standardization. It eliminates a ton of conversations. Sometimes the lint is wrong.

只要误报率相对较低，而且不会造成灾难性后果，那就没关系，因为这样一来，之后就会少掉一大堆 lint 错误或其他问题，不用你再去处理。你可以问问那些曾经在一个百万行代码库里突然想启用 linter 的人。他们会说：“哦，天哪，现在我得做一个 10 万行的改动，对吧？”还不如一开始就做好，让所有人都启用它。Like as long as the false positive rate is relatively low and it doesn't have catastrophic consequences, it doesn't matter because all of a sudden there's a bunch of future lint errors or future issues that you don't have to deal with. Like, ask anybody who's been like, "Oh, I suddenly want to turn on my linter in this million-line code base." And they're like, "Oh, wow. Now here's my 100,000-line change that I need to make, right?" Much easier to just do that up front and have it on for everybody.

听着，就像我说的，我真的可以就站在这儿，跟你聊这个话题整整10个小时。Now, look. Like I said, I could literally stand here and talk to you about this straight for 10 hours.

在这里你还能做的事情要多得多。这只是其中几个方面，不过你也可以在另一个维度上应用一整套软件工程规范。There is much, much more you can do here. This is just a few areas, but also a whole area of software engineering discipline that you can apply on the other axis.

答案The answer

所以，现在我们可以回答这个问题了，不再只是说“这要视情况而定”，而是可以回答“是”或“否”。那么，代码质量真的重要吗？对于一次性软件来说，不重要；对于需要长期维护的软件来说，重要。我们还可以回答第三个更有意思的问题：这一定得很贵吗？不。非常感谢。So, this lets us now answer our question, not just it depends, but yes or no. So, does code quality even matter? For disposable software, no. For durable software, yes. And we get to answer a third and even more interesting question, which is does it have to be expensive? No. Thank you very much.