过早优化的实用规则
看来，“ 过早优化 ”这个词是当天的stream行词。 出于某种原因，iphone程序员似乎认为避免过早优化作为积极的目标，而不是简单地避免分心的自然结果。 问题是，这个词已经开始被越来越多的应用于完全不合适的案例。
例如，我看到越来越多的人说，不要担心algorithm的复杂性，因为这是过早的优化（例如， 帮助对两个属性（使用NSSortDescriptor？）进行NSArraysorting ）。 坦率地说，我认为这只是懒惰，令人</s>然心动的计算机科学。
但是我想到，也许考虑到algorithm的复杂性和性能正在成为组装循环展开的方式，而现在被认为是不必要的其他优化技术。
你怎么看？ 我们现在在哪里决定O（n ^ n）和O（n！）复杂度algorithm是不相关的？ 那么O（n）和O（n * n）呢？
你认为“过早优化”是什么？ 你有意识或不自觉地避免使用哪些实用的规则？
编辑
我知道我的描述有点普遍，但我对特定的实用规则或人们用来避免“过早优化”的最佳实践感兴趣， 特别是在iphone平台上 。
回答这个问题需要你首先回答“什么是先期优化？”的问题。 由于这个定义明显变化很大，任何有意义的答案都需要作者定义这个术语。 这就是为什么我不认为这是一个CW问题。 再次，如果人们不同意，我会改变它。
什么是过早优化？
不成熟的优化是在你知道是否值得这样做之前优化你的代码（通常是为了性能）的过程。 过早优化的一个例子是在对代码进行分析之前优化代码以找出性能瓶颈。 过早优化的一个更极端的例子是在运行程序之前进行优化，并确定运行速度太慢。
我们现在在哪里决定O（n ^ n）和O（n！）复杂度algorithm是不相关的？ 那么O（n）和O（n * n）呢？
这取决于n的大小以及代码被调用的频率。
如果n总是小于5，则渐近性能是无关紧要的。 在这种情况下，常量的大小将更重要。 一个简单的O（n * n）algorithm可以击败小n的更复杂的O（n log n）algorithm。 或者可测量的差异可能很小，无关紧要。
我仍然认为有太多的人花费时间来优化90％的代码，而不是10％的代码。 如果代码几乎不被调用，那么没有人关心一些代码是否需要10ms而不是1ms。 有些时候，只要做简单的工作，继续前进是一个不错的select，即使你知道algorithm的复杂性不是最优的。
您花费的每个小时优化很less被调用的代码less了一个小时，您可以花费在添加人们想要的function上。
我的投票是为了让大多数人优化他们认为的薄弱点，但是他们不会介绍。
所以无论你如何知道algorithm，也不pipe你写了多less代码，你不知道模块外还有什么事情发生。 你所说的API在幕后做了什么？ 你可以总是保证操作的顺序是最快的吗？
这是过早优化的含义。 任何你认为是没有经过性能testing或其他权威工具严格testing的优化（ops的时钟周期不是坏事，但它只能告诉你性能特点〜实际调用比时间更重要），是一个不成熟的优化。
@k_b表示远高于我，这也是我所说的。 把它做好，把它简单化，然后configuration文件，然后调整。 根据需要重复。
优先顺序：1.必须工作 2.必须可维护 3.必须是机器效率
那是我第一次编程课程的第一周。 1982年 。
“不成熟优化”是任何时候在优先级1或优先级2之前已经考虑过优先级3。
请注意，现代编程技术（抽象和接口）旨在使此优先级更容易。
一个灰色地带：在最初的devise中，你必须检查你的解决scheme是不是本质上缓慢的。 否则，不要担心性能，直到你至less有一些工作代码。
对于一些人来说，优化是编写代码乐趣的一部分，不成熟或不成熟。 我喜欢优化，为了易于理解而克制自己。 不要优化太多的build议是喜欢优化的人。
特别是iPhone程序员似乎认为避免过早优化是一个积极的目标
大多数的iPhone代码是与用户界面相关的。 没有太多需要优化。 有一个不需要select一个糟糕的devise，会导致不良的performance，但是一旦你开始编码一个好的devise，几乎没有优化的需要。 所以在这种情况下，避免优化是一个合理的目标。
你认为“过早优化”是什么？ 你有意识或不自觉地避免使用哪些实用的规则？
使用敏捷方法（快速迭代，通过与用户进行交互来细化需求）非常有用，因为人们认识到当前界面在下一次会话之后可能会发生巨大变化，用户可以更轻松地专注于开发基本function应用程序而不是性能。
如果不是这样，那么你花了很多时间来优化一个被用户会话之后完全丢弃的特性的迭代应该会给你提示信息。
algorithm的复杂性，甚至是select，都是一个应该隐藏在接口后面的问题。 例如，List是一个抽象，可以针对不同的情况以不同的方式实现不同的效率。
有时避免过早优化可以帮助devise，因为如果你devise的想法是需要稍后进行优化的话，那么你更倾向于在抽象级别（例如列表）而不是实现（例如数组或链表）级别上进行开发。
这可以导致更简单，更可读的代码，除了避免分心。 如果编程到接口，不同的实现可以稍后交换到优化。 过早优化会导致实现细节可能过早暴露，并与其他不应该看到这些细节的软件组件耦合。
你有意识或不自觉地避免使用哪些实用的规则？
避免不必要的优化的一个方法是考虑相对成本收益：
A）程序员优化代码+成本以testing所述优化+维护由所述优化产生的更复杂代码的成本的代价
与
B）升级软件运行的服务器的成本或者仅仅购买另一个（如果可扩展的话）
如果A >> B考虑是否是正确的做法。 [暂时忽略可能或不可能成为贵组织关注的B的环境成本]
这种方法不仅适用于不成熟的优化，而且可以帮助灌输开发人员，使他们花时间进行优化工作是一种成本 ，不应该进行，除非真正重要的东西存在真正可衡量的差异 ：通过改进响应时间来满足服务器或客户满意度
如果pipe理层看不到减less收益的好处，并且客户在更好的响应时间内看不到收益，那么问问自己为什么要这样做。
我认为这是一个常识问题。 有必要了解大局，甚至是发生了什么，能够考虑什么时候所谓的“过早”举措是合理的。
我已经与需要Web服务调用的解决scheme合作，根据本地列表的内容计算新的值。 实施的方式是通过每个价值的Web请求。 一次发送多个值不是不成熟的优化。 对于多个操作使用数据库事务也是如此，即多次插入。
说到algorithm，最重要的是要做到最好，尽可能简单。 担心在这一点堆栈与堆问题将是疯狂的。
