在初始编码过程中遵循优化技术是一种好的做法，还是应该首先集中精力实现功能？
如果在初始编码期间纯粹专注于功能，那么以后如何轻松或难以处理优化？
答案 0 :(得分：16)
优化您的设计和架构 - 不要将自己锁定在永不扩展的设计中 - 但不要微观优化您的实施。特别是，不要牺牲微优化实现的简单性和可读性......至少在没有首先对代码进行基准测试（理想情况下是整个系统）的时候。
在性能方面，测量确实是关键。瓶颈几乎从未像你期望的那样。有许多不同的测量方法;没有任何测量的优化是徒劳的IMO。
答案 1 :(得分：2)
我们应该忘记小的效率，比如大约97％的时间：过早的优化是所有邪恶的根源
答案 2 :(得分：1)
这取决于您所看到的“优化”。微观优化不应该在早期阶段完成，之后只有在你有正当理由的情况下才能完成（例如，探查者结果或类似的）。
然而，按照最佳实践和通用编码指南编写结构良好，干净的代码是一个好习惯，一旦习惯了它，它不会花费太多时间来编写草率代码。这种“优化”（不是正确的词，但有些人认为是这样）应该从一开始就完成。
答案 3 :(得分：0)
请参阅http://en.wikipedia.org/wiki/Program_optimization以获取Knuth的报价。
如果您认为优化可能会使您的代码更难以（a）从一开始就正确，或者（b）从长远来看，那么最好先将其弄好。拥有良好的开发流程（例如测试驱动开发）可以帮助您稍后进行优化。
让它工作正确而缓慢，而不是错误和快速总是更好。
答案 4 :(得分：0)
Donald Knuth说道：“过早优化是所有邪恶的根源”，它会使你的编码速度变慢。优化的最佳方法是再次访问代码库并重构。通过这种方式，您可以了解代码的哪个部分经常使用或者是瓶颈，应该进行微调。
答案 5 :(得分：0)
过早优化并不是一件好事。 这尤其适用于低级优化。但是在更高的层次上，您的设计不应该锁定任何未来的优化。
例如。
集合的检索应该隐藏在方法调用之后，最后你总是可以决定是否缓存集合的检索。 在你有一个稳定的应用程序和（！）后，你已经开发了回归单元测试。您可以分析应用程序并优化热点。请记住，在每个优化步骤之后，您应该运行完整的单元测试集。
答案 6 :(得分：0)
在初始编码过程中遵循优化技术是一种好的做法，还是应该首先集中精力实现功能？
如果您知道性能至关重要（或重要），请在设计中考虑并在第一时间正确编写。如果您在设计中也没有考虑到这一点并且这很重要，那么您就是在浪费时间或“开发概念验证”。
部分原因归结为经验;如果您知道优化和程序的问题区域或过去已经实现了类似的功能，那么您的经验肯定会帮助您在第一次创建更接近最终结果的实现。如果您仍然需要概念证明，那么在完成之前不应该编写实际的程序 - 踢出一些测试以确定适合该问题的解决方案，然后正确实施。
如果在初始编码期间纯粹专注于功能，那么以后如何轻松或难以处理优化？
一些修复很快，其他修复完全重写。事后需要改变和适应的越多，浪费重新测试和维护一个执行不良的程序的时间就越多。最容易维护和维持需求的库通常是工程师理解设计理想的库，并且在初始实现期间努力满足这一理想。
当然，这也假设你喜欢长期计划！
答案 7 :(得分：-1)
过早优化是万恶之源
要详细说明这个着名的引语，尽早进行优化有一个缺点，就是分散你做好设计的注意力。此外，程序员在查找代码的哪些部分会导致更多麻烦方面非常糟糕，因此请尽量优化不那么重要的事情。您应该始终先测量以找出需要优化的内容，而这只能在后期阶段进行。