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