这主要是由于对 SQL 问题的回答。出于性能考虑，有意省略了 UDF 和子查询。我没有包括可靠性，而不是认为它应该被视为理所当然，但代码必须工作。
性能永远是第一位的吗？以性能为主要优先事项提供了如此多的答案。我的用户似乎更关心代码的修改速度。因此，运行报告需要 15 秒而不是 12 秒。只要我不为不提供解决方案找借口，他们就可以忍受。
显然，如果 15 秒变成 15 分钟，那就有问题了，但用户想要这个功能。他们希望应用程序适应业务规则更改和增强请求。我希望能够在 6 个月后查看代码，并且能够在一个容易识别的位置进行更改，而不是追查所有那些有人复制和粘贴代码的地方，因为他们认为调用另一个函数或子例程或 Udf 会阻碍性能。
说了这么多，我要订购：可维护性（改变是生活中的事实。），性能（没有人喜欢盯着沙漏。），可重用性（很难确定应该再次使用什么代码。）。
1. 可维护性：如果代码不可读，不管它有多快，它都是无用的。而且绝对不会被重复使用。
2. 可重用性：并非所有代码都是可重用的，但很多是可重用的。如果可以的话，一定要让你的代码更简单。最简单的就是分而治之。例如，创建您将反复使用的简单组件。UI 小部件是最常见的。但公用事业也是如此。同样，为您的代码创建结构/框架也会有所帮助。错误验证码等
3. 性能：通常大多数代码都足够性能。如果没有，请使用代码分析器。通常，瓶颈会远远超过任何以可读性或可重用性为代价的小代码优化。
我认为您错过了列表中的一项：可靠性；
所以我的订单是
不正确的代码有多快并不重要，首先代码必须是可靠的。
性能位于列表的底部。永远不要过早优化，只有在性能出现问题时才提高性能。
我曾在包括飞行模拟在内的实时系统上工作过，即使在那种环境下，性能也被考虑在内，但并不是最重要的首要问题1。
我想说，根据我的经验，我只需要优化不到 1% 的代码。
1有时有些东西不够快，当然在设计和编码时会考虑性能，它只是不在列表的顶部。
2010-03-02 编辑：问题最初开始：
每个人都为 NASA 工作吗？性能永远是第一位的吗？这么多答案...
不，我们大多数人都不为 NASA 工作。
不：可靠性和可维护性高于性能。可重用性也很好。
在广泛的范围内，性能并不重要。
傻瓜的答案当然是“这取决于”。
在业务线应用程序的情况下，所涉及的活动的响应时间需要与其运行的频率成反比。如果这是一个用户需要每小时访问 4 或 5 次的功能，它最好比提取月末报告更快。
我认为，在某种程度上，你已经回答了你自己的问题，并为此提供了一些非常正当的理由。你唯一错过的是可靠性——这就是 NASA 类比的用武之地。如果你正在为 NASA 或金融机构编写代码，那么它最好是健壮和可靠的......我认为这是第一要务。
我是一名 NASA 承包商，主要出于管理目的开发和维护软件，例如运行报告和跟踪项目。
我已经在那里工作了大约 1.5 年，我相信他们主要关心的是可维护性以及部署新功能或模块的速度。
就像问题中所说的吉尼斯一样，只要软件不花费大量时间，他们似乎并不介意。
他们似乎关心的另一个主要问题是可用性。该应用程序必须易于使用。
总之，可维护性、可用性和性能似乎是 NASA 对内部报告和跟踪工具的主要关注点。
您必须能够根据项目重新安排这些优先级，而当您在项目甚至不同代码部分之间切换时，困难可能是快速改变行为。我在三个具有非常不同配置文件的应用程序上工作。
一个是实时的，并且需要做大量工作来确保其性能是可预测的（不一定是快速闪电），但变化不是主要问题，只有当 IETF 更改/废弃 RFC 并且几乎没有迹象时，它才会发生显着变化那个。（也就是说，我为它的可维护性水平感到自豪）。
另一个应用程序有时需要 16 小时来处理 1 天的数据。毋庸置疑，绝对性能很快成为重中之重。但即使在这个应用程序中，性能的强调也有很大的不同，从每个批处理代码中的“不重要”到每个客户端代码、每个任务代码、每个文件代码、每个记录代码、每个-field-code 在每字节码中“极其重要”。
最终的应用程序包含大部分业务逻辑，性能永远不是问题，可维护性和敏捷性是关键，这个应用程序从所有流行的方法中获益最多，但是，当我刚刚花了数周或数月的时间来重构性能时，这非常困难写“string1 + string2 + string3 + string4”，即使那是最易读的并且性能无关紧要。
这是一个有趣的问题，答案也很有趣。优先级取决于实施。我想展示一个用户不会为了可维护性或可重用性而牺牲性能的例子。是的，有一个可靠性因素——应该有任何错误/错误。因此，当我们比较可维护性、性能和可重用性时。
我们的一位客户有在线交易网站。在峰值负载下，在中间件级别完成平均事务大约需要 14 毫秒。一段时间后，应用程序的性能下降（由于某些原因），事务平均时间增加到 24 毫秒。现在，作为一个普通的开发人员，我们会认为 10 毫秒并不是那么关键。但如果我们从商业角度思考，那就令人担忧了。如何？让我们分析一下：
让我们假设在峰值负载下，资源被充分利用，并且我们能够在 14 毫秒内完成 100 个事务。现在随着性能的下降，事务需要额外的 10 毫秒，即 71.42% 的额外时间。现在这意味着我们将只能处理 28.58 个事务，而不是 100 个事务。这意味着业务的严重损失。
事实上，有很多关于应用程序性能重要性的文献。有一本很好的书“计算机体系结构的定量方法”解释了如何在业务/用户方面量化性能、可维护性、可靠性、可用性等因素。
我不会指定重要性顺序，因为它是特定于上下文的。
他们认为调用另一个函数或子例程或 Udf 会影响性能
这是错误的想法。
我会订购：可维护性、性能、可重用性。
有时（通常是 IMO）可重用性是可维护性：这是因为您重用了某些东西，您“能够在一个容易识别的地方进行更改，而不是追查所有那些曾经复制和粘贴代码的地方”。
即使在 NASA，性能也不是第一位的！在 NASA，如果代码不正确和不可靠，人们就会死亡。
此外，根据我的经验，即使性能很有价值，也有一定的意义。通常有一个性能水平，在超越时几乎没有附加价值。相比之下，无论一段代码多么可靠，提高正确性都有额外的价值。一段代码不能经常按预期运行。
对我来说，顺序是：
在一个孤立的答案中，性能几乎总是第一位的。
我们不知道您是否会连续敲击这段代码一百万次，因此默认情况下性能是一个问题。我们不知道我们宝贵的代码片段是否会成为您应用程序的瓶颈，因为我们不知道它是如何交互的。（在编写库代码时也会发生同样的情况：我不知道这是如何使用的。IMO 代码重用的一个原因不仅仅是“将类似代码移动到共享实体”。）
代码如何与我们未知的代码交互对可维护性的影响更大。答案将在您设置的范围内解决问题：您可以要求或标记为 SQL、SQL Server 或 MySQL。其余的，我们只是不知道：你有多少类似的代码路径？在项目的生命周期中，这段代码多久更改一次？你会坚持使用那个特定的数据库服务器版本十年，还是会经常更新？
解决可维护性在很大程度上是您的工作：您问的问题是否应该隔离的实体？
可读性大部分已经完成，剩下的就是你的工作了。在回答时，我们通常对您理解答案感兴趣，因此它至少需要对您来说是可读的。如果您将该片段复制粘贴到您的代码中并对其进行// That weird query评论，那么不再是我的问题了。
除此之外，性能更容易理解这一事实：从两个功能相同的答案中，您总是会选择一个说“像 Joes 的答案，但要快一点”的答案，除非它在 M+R 部门犯了大错。
现在写这个，看起来过早的优化很诱人是有原因的。由于几个原因，这是错误的优先级。
但是，优化的低优先级有两个主要原因：
正确性比可维护性、可重用性或性能更重要。如果您的目标是正确性，那么您很可能会在讨价还价中获得其他三个。
以下是基于标签计数的结果：
这是什么意思：性能一定很重要？性能更难，因此会提出更多问题。性能问题更具体/更适合在本网站上提问？
我在 NASA 工作。但是，我（目前无论如何）不维护或开发实时代码或任何对性能至关重要的东西。大多数在 NASA 完成的软件可能不是。在我看过一些可怕的代码之后，我也会选择 Jonathan 关于可靠性和可维护性的回答，其次是性能，然后是大多数应用程序的可重用性。
我最喜欢的名言之一来自 SICP ...
“计算机程序旨在供人类阅读并由计算机偶然运行。”
我评价我工作的所有这些方面；但是我的代码和与我一起工作的代码的可读性（有些人使用术语表达能力）在我的重要性列表中名列前茅。
就我的2c，周末愉快！