在开发的开始或结束时，优化软件以获得更好的性能是更好的吗？

Question

我是一个初级软件开发人员，我想知道什么时候才是优化软件以获得更好性能(速度)的最佳时机。

假设软件不是非常大和复杂的管理，那么最好是在开始时花更多的时间来优化它，还是应该只开发正确执行所有功能的软件，然后继续优化它以获得更好的性能？

Answer 1

第一件事应该永远是可读性的。如果它慢但易读，我可以修复它。如果它坏了，但可读，我可以修复它。如果它是不可读的，我必须问其他人，它甚至应该做什么。

值得注意的是，当您只关注于可读性时，代码的性能是多么出色。如此之多，所以我通常忽略表现，直到有理由去关心。这不应该被理解为我不在乎速度。我知道。我刚刚发现，只有极少数问题的解决方案在很难理解的情况下才会更快。

只有两件事让我脱离了这种模式：

1. 当我看到一个完全成熟的大O改进的机会时，即使是当n大到任何人都会关心的时候。
2. 当我的测试显示出真正的性能问题时。即使有了几十年的经验，我仍然比我的数学更相信考试。我擅长数学。

无论如何，通过让自己认为不应该尝试解决方案来避免分析性瘫痪，因为它可能不是最快的。如果您尝试多种解决方案，您的代码实际上将受益，因为进行更改将迫使您使用一种易于更改的设计。在以后真正需要的地方，灵活的代码库可以变得更快。选择灵活的速度而不是速度，你可以选择你需要的速度。

Answer 2

如果一定程度的性能是必需的(非功能性需求)，那么从一开始就应该是设计目标。例如，这可能会影响哪些技术可能是合适的，或者您如何在程序中构造数据流。

但是一般来说，在编写代码之前不可能进行优化：先使它起作用，然后使它正确，最后，使它快速。。

在实现大多数功能之前进行优化的一个大问题是，您已经将自己锁定在错误的地方进行次优设计决策。在可维护性和性能之间经常存在(但不一定)权衡。程序的大部分部分与性能完全无关！典型的程序只有少数几个值得优化的热点。因此，在所有不需要性能的地方牺牲可维护性以获得性能是非常糟糕的交易。

优化可维护性是较好的方法。如果您将聪明用于可维护性和清晰的设计，那么从长远来看，您会发现更容易识别关键部分，并在不影响总体设计的情况下安全地优化它们。

Answer 3

什么时候才是优化软件以获得更好性能(速度)的最佳时机。

首先，从你的脑海中移除一个概念，即性能和速度是一样的。性能是用户认为性能是什么。

如果应用程序对鼠标单击的响应速度是鼠标单击速度的两倍，并且从10微秒到5微秒，用户不会在意。如果应用程序对鼠标单击的响应速度是鼠标单击速度的两倍，并且从四千年到两千年，用户也不会在意。

如果您将应用程序的速度提高了一倍，并且耗尽了机器上的所有内存并崩溃，用户并不关心它现在的速度是原来的两倍。

性能是对资源消耗进行有效权衡以获得特定用户体验的科学。用户的时间是一个重要的资源，但它从来没有仅仅是“更快”。实现性能目标几乎总是需要权衡，而且它们通常是用时间换取空间，反之亦然。

假设软件不是非常大和复杂的管理

这是个糟糕的假设。

如果软件不是大型的和复杂的管理，那么它可能解决不了一个有趣的问题，用户关心，它可能是超级容易优化。

最好是在开始时花更多的时间来优化它，还是应该开发一个软件来正确地执行所有的功能，然后继续优化它以获得更好的性能？

你坐在一个空白页上，写void main() {}，你开始优化了吗？没有什么需要优化的！正确的顺序是：

• 使其编译
• 使它正确
• 使它优雅
• 快一点

如果你试图按任何其他顺序去做，你最终会得到错误的代码，这是一个混乱，现在你已经有一个程序产生错误的答案非常快，并抵制变化。

但那里缺少了一步。真正正确的顺序是：

• 与客户和管理层合作，制定切合实际的、可衡量的性能指标和目标，记住速度并不是客户唯一关心的指标。
• 实现一个测试工具，可以根据您的目标跟踪项目的当前状态。
• 使其编译
• 做测试。如果你不再在你的目标之内，要意识到你可能很早就走上了一条糟糕的道路。用科学。你介绍了一个坏的算法，可以修复，还是从根本上说是错误的？如果这根本是错误的，那就重新开始。如果可以修复，请输入一个bug，稍后再返回。
• 使它正确
• 再做一次测试..。
• 使它优雅
• 再做一次测试..。
• 你是否遵守了你的目标？如果是，去海滩。如果没有，那就快一点。