代码优化的另一面

　　优化软件是一件好事，但如果使用不当，就会好事变坏事。如果你在优化代码时走向了错误的道路，那么这种优化会提高开发成本、降低生产力。在软件开发过程中，成本需要时刻谨记在心。一般来说，优化的软件需要花费更长的时间来交付，因为你需要花费精力使它质量更高。有时候，你并不是为了运行速度而做优化。对于嵌入式系统来说，可能是减少内存使用，对于手持设备，可能是硬件资源限制。优化的代码通常难以调试和维护，因为你需要牺牲一些代码可读性。优化良好的软件带来的好处要多于坏处，但是如果你做了错误的优化，那么结果恰恰相反。

　　到底怎么才能做好代码优化呢？Rick Cook 给出了一些有用的建议。

　　你到底为了什么而优化

　　如果在优化过程启动时搞不清楚为什么而优化，那么你基本会走向错误的道路。你需要清楚的理解你准备完成的目标和相关的优化选择。这些目标需要清晰而且简洁，简单到项目经理能够理解它，你需要在优化过程中始终坚持这些目标。在软件开发过程中，变更是常有的事情。你可能一开始想优化这个目标，然后又发现需要优化其他目标。事实也是如此，但是请把这些目标的变更记录清楚。

　　性能测试团队报告的性能缺陷可能是优化的主要目标，一方面它来自于开发人员之外的客观性能问题，另一方面这些缺陷报告会明确的指出存在哪些问题，是运行缓慢，还是磁盘换页频繁等等。开发人员从这些缺陷中开始入手优化，比自己空想出的性能目标要合理、客观的多。

　　小心对待优化的衡量标准

　　选择正确的衡量标准是优化的重要步骤。你需要利用这些标准来衡量自己的优化进度。如果衡量标准是错误的，那么你的努力就白费了。即使是正确的标准，也需要正确的运用。有时候，把主要精力放在应用程序运行时间最多的代码部分上市正确的做法。不过请记住，Unix/Linux 内核在空闲循环（idle loop）中花费的时间最多。这里的问题是，如果你不小心对待，那么你可能会选择一个不能帮助你解决问题的衡量标准。

　　衡量标准的选择应该取决于哪些标准能够确实提高用户体验。例如，有关数据库的性能分析指标有很多，开发人员和性能测试人员需要确定哪些指标是真正影响应用程序速度的，是 bufferpool 的大小，还是数据库连接池的大小。这是一个渐进的认识过程。

　　优化且只优化关键部分

　　这是有效优化的关键。寻找能够达到目标（性能、资源）的代码部分并集中精力。一个典型的例子是把时间花费在优化数据库上，而实际的性能杀手是缓慢的网络连接。

　　不要被映入眼帘的表象所吸引。这些表象并不一定会解决你的问题。只是因为某些事情易于发现而且易于优化并不意味着它们值得关注。 

　　高层次优化更好

　　一般来说，优化的层次越高，优化的效果就越明显。按此标准，最好的优化方法是寻找更好的算法。例如，在一些 IT 部门，员工花费几个月的时间来对某个软件做优化但是没有进展，然后找来一批新员工来做这些优化，他们很快就会发现性能的问题在于代码某处使用了冒泡排序或者某张数据库表增加了数以万条的记录等等。

　　建议大家花时间看看基本的应用架构，找找有没有可以优化的线索。但是，高层次优化不是银弹。一些基本的技术，比如把代码尽可能的移到循环体外面等等。

　　另外，高层次优化可以避免对代码细节的复杂重构。开发人员往往对低层次的优化最感兴趣，请控制住自己的欲望，从高处着手！ 

　　不要过早优化

　　开发人员有一种冲动，那就是在编码的时候就准备优化了。一般来说，这不是个好主意。有时候，开发人员并不确定这样的优化工作是否值得。例如，你可能通过移位操作来代替乘法操作，但是这种性能优化的做法会产生让人非常难以理解的代码。

　　最好把开发和优化工作分开，先开发出正确的代码，然后再优化。过早优化的问题在于开发人员会有意的对软件的架构设计和代码结构等做一些预先的设想，而其中有相当一部分都是多余操心的，你可能不得不对这些多余的部分再做优化。

　　依靠性能分析数据，而不是直觉

　　你以为自己知道软件系统哪里需要优化，但是直觉是第二位的，数据是第一位的。否则，你会发现可能把一段代码优化的非常快，但是实际上很少被调用。

　　优化的一个有效的策略是，你要根据所做工作对优化效果的影响来进行排序。在开始工作之前找到影响最大的“路障”，然后再处理小的“路障”。 

　　不能指望优化解决所有问题

　　优化的重要法则之一是不能让优化解决所有问题，比如，提高运行速度会耗费更多系统资源。你必须为了主要的优化目标做出权衡。

　　读者对代码优化有什么看法，欢迎发表自己的意见！