编码优先级:性能、可维护性、可重用性?

1。可维护性: 如果代码不可读,不管它有多快,它都是无用的。它绝对不会被重复使用。

2。Reusability: 并非所有的代码都是可重用的,但很多代码是可重用的。如果可以,一定要使代码更简单。最简单的是分而治之。例如,创建将反复使用的简单组件。UI小部件是最常见的。但公用事业也一样。此外,为代码创建结构/框架也有帮助。错误验证码等。

三。性能: 一般来说,大多数代码都具有足够的性能。如果没有,使用代码分析器。通常情况下,瓶颈将远远超过任何以可读性或可重用性为代价的小代码优化。

我想你错过了名单上的一个:可靠性;

所以我的订单是

• 可靠性和准确性
• 维修性
• 可重用性
• 性能

当代码不正确时,不管代码有多快,首先代码必须是可靠的。

性能在列表的底部。不要过早优化,只有在性能有问题时才能提高性能。

我研究过包括飞行模拟在内的实时系统,即使在这种环境中,性能也会被考虑在内,但并不是最主要的问题。 ^一 .

我会说,根据我的经验,我只需要优化我所写代码的不足1%。

^一 有时候有些东西不够快,当然在设计和编码时会考虑性能,只是不在列表的顶部。

最糟糕的答案当然是“视情况而定”。

对于业务线应用程序,所涉及活动的响应时间需要与运行频率成反比。如果它是一个用户每小时需要访问4到5次的功能,那么它最好比提取月末报告更为迅速。

我认为,在某种程度上,你已经回答了自己的问题,并提供了一些相当合理的理由。唯一你错过的是可靠性——这就是美国宇航局的类比。如果你在为美国宇航局或是金融机构编写代码,那么它最好是健壮可靠的…我认为这是第一要务。

我是NASA的承包商,主要为管理目的开发和维护软件,如运行报告和跟踪项目。

我在那里工作了大约1.5年,我相信他们最关心的是 维修性 以及部署新功能或模块的速度。

就像问题中提到的Guiness一样,只要软件不需要特殊的时间,他们似乎并不介意。

另一个主要的问题是可用性。该应用程序必须易于直接使用。

总之,可维护性、可用性和性能似乎是NASA对内部报告和跟踪工具的主要关注点。

您必须能够根据项目重新排列这些优先级,当您在项目之间甚至代码的不同部分之间切换时,最困难的事情就是快速地改变行为。我在三个具有非常不同配置文件的应用程序上工作。

1. 一个是实时的,很多工作都要确保它的性能是可预测的(不一定快速减轻),但是变化不是一个主要问题,它只在IETF改变/废弃RFC时发生显著变化,而且几乎没有这种迹象。(也就是说,我为它的可维护性水平感到骄傲)。

   • 另一个应用程序有时需要16小时来处理1天的数据。不用说,绝对性能很快就成了首要任务。但即使在这个应用程序中,对性能的强调也大不相同,从每批代码中的“不重要”,到每客户端代码、每任务代码、每文件代码、每记录代码、每字段代码,再到每字节代码中的“极其重要”。

   • 最终的应用程序包含很多业务逻辑,性能从来不是问题,可维护性和敏捷性是关键,而且这个应用程序从所有流行的方法中受益最多,但是,当我花了几个星期或几个月的时间重构性能时,很难编写“string1+string2+string3+string4”,即使这是任务ST可读性和性能无关。

编辑日期:2010-03-02 :问题最初开始于:

每个人都为国家航空航天局工作吗?表演总是第一位的吗?这么多答案…

不,我们大多数人都不为国家航空航天局工作。

否:可靠性和可维护性先于性能。可重用性也很好。

在广泛的范围内,绩效并不重要。

这是一个有趣的问题,答案非常有趣。优先级取决于实现。我想举一个例子,用户不会为了可维护性或可重用性牺牲性能。是的,有一个可靠性因素-应该有任何错误/错误。所以当我们比较可维护性、性能和可重用性时。

我们的一个客户有在线交易网站。在峰值负载下,平均事务需要大约14毫秒才能在中间件级别完成。后一段时间,应用程序的性能下降(由于某些原因),事务平均时间增加到24毫秒。现在作为一个普通的开发人员,我们认为10毫秒并不是那么危急。但是,如果我们从商业的角度来思考,那就太令人担忧了。怎样?让我们分析:

假设在峰值负载下,资源被充分利用,有了14毫秒,我们就可以完成100个事务。现在随着性能的降低,事务需要10毫秒的额外时间,即71.42%的额外时间。现在这意味着我们只能提供28.58笔交易,而不是100笔交易。这意味着严重的商业损失。

事实上,关于应用程序性能的重要性有很多文献。有一本非常好的书“计算机体系结构的定量方法”,它解释了性能、维护性、可靠性、可用性等因素如何可以用业务/用户术语进行量化。

我不会指定重要性的顺序,因为这是上下文特定的。

他们认为调用另一个函数、子例程或UDF会阻碍性能

那是错误的想法。

我会订购:可维护性、性能、可重用性。

有时(通常是IMO)可重用性 是 可维护性:因为您重用了一些东西,所以您“能够在一个容易识别的地方进行更改,而不是追查所有这些地方,只有一个复制并粘贴了代码”。

即使在美国国家航空航天局,表现也不是第一位的!在美国宇航局,如果代码不正确和可靠,人们就会死亡。

此外,根据我的经验,即使绩效很有价值,也有一定的意义;通常有一个绩效水平,即没有或几乎没有额外的价值可以超越。相反,无论一段代码有多可靠,提高正确性都有额外的价值;一段代码不能像预期的那样经常运行。

对我来说,订单是:

• 维修性 :如果不容易改变,即使现在是正确的,也不会长期保持正确。
• 重复使用性 :重用提高了生产效率,代码越少通常比代码更可靠。
• 性能 :有时性能很重要,但即使在性能关键的应用程序中,有多少代码不是性能关键的,您也会感到惊讶。性能优化只对瓶颈很重要。

在一个孤立的答案中,性能实际上总是第一位的。

我们不知道您是否要连续点击这段代码一百万次,所以默认情况下性能是一个问题。我们不知道我们宝贵的代码片段是否会成为您应用程序的瓶颈,因为我们不知道它是如何交互的。 (在编写库代码时也会发生同样的情况:我不知道这是如何使用的。IMO代码重用的一个原因不是简单地“将类似的代码移动到共享实体”。)

维修性 更受代码如何与我们未知的代码交互的影响。答案将解决您设置的作用域中的问题:您可以请求或标记为SQL、SQL Server或MySQL。剩下的,我们只是不知道:您有多少相似的代码路径?在项目的生命周期中,这段代码多久更改一次?您将坚持使用特定的数据库服务器版本10年,还是将经常更新?

解决可维护性在很大程度上是您的工作:您所问的问题是应该隔离的实体吗?

可读性 大部分都完成了,剩下的是你的工作。 回答时,我们通常对您感兴趣,请理解答案,因此它至少需要对您可读。如果你复制粘贴到你的代码中,然后 // That weird query 评论一下,不再是我的问题了。

除此之外,性能更容易理解:从两个功能相同的答案中,您总是会选择一个说“像Joes答案,但速度更快”的答案,除非它在M+R部门犯了巨大的错误。

现在写这个看起来有一个原因,过早的优化是诱人的。这个 是 有几个原因导致优先级错误。

优化的低优先级有两个主要原因,尽管:

正确性 比可维护性、可重用性或性能更重要。如果你的目标是正确的话,你很可能在交易中得到另外三个。

• 只写必要的代码。
• 利用标准库。
• 与其聪明,不如透明。
• 编写小的、可测试的函数。

以下是基于标记计数的结果:

• 性能-952
• 可重用性(几个相关标签)-43
• 可维护性-14

这意味着什么: 性能一定很重要吗? 性能更难,所以会问更多的问题。 性能问题是否更具体/更适合在此网站上提出?

我 做 在美国国家航空航天局工作。但是,我(目前无论如何)不维护或开发实时代码或任何对性能至关重要的东西。在美国国家航空航天局做的大多数软件可能不是这样的。在我那一天看到了一些可怕的代码之后,我还将遵循乔纳森关于可靠性和可维护性的回答,接着是性能,然后是大多数应用程序的可重用性。

我最喜欢的一句话是来自SICP…

“计算机程序被设计成可以被人阅读,也可以由计算机偶然运行。”

我对我工作中的所有这些要点都进行了评价;但是代码的可读性(有些使用了表示性这个术语)和我工作的代码的可读性是我最重要的清单。

就我的2c,祝你周末愉快!