简介
优化原则
不论最终的优化结果如何,代码优化工作总是有代价的。如果代码能够正常工作,却花了大量精力是其运行的更快,未必是一件值得尝试的有价值的事情。
进行代码优化,需要记住几条原则:
1) 确保代码能够正常工作之前不要考虑优化工作
应该避免在编写代码的同时,对其进行优化,这是程序员最常见的错误。因为实际情况是,对于复杂的系统,在你编写代码的时候,你并不能得到系统运行的完整视图,因此也无法确定当前的代码是否会成为系统性能的瓶颈。
但这并不意味着程序员不需要尝试编写运行更快的代码。这里强调的是首先保证程序能够正常的工作。在使代码能够正常工作并且进行代码的剖析之前,不要做代码优化工作,如用C/C++语言来对代码的一个部分进行扩展。
二八原则:1897年,意大利经济学家帕列托在对19世纪英国社会各阶层的财富和收益统计分析时发现:80%的社会财富集中在20%的人手里,而80%的人只拥有社会财富的20%,这就是“二八法则”。“二八法则”反应了一种不平衡性,但它却在社会、经济及生活中无处不在。在任何一组东西中,最重要的只占其中一小部分,约20%,其余80%尽管是多数,却是次要的,因此又称二八定律。
对于代码优化工作,帕列托定律同样适用。影响性能的代码往往集中在少部分代码,过早的或不必要的性能优化,往往是项目和程序员的噩梦。
用Kent Beck的话来作为本小结的小结:
Optimization is carried out on programs that already work.
“Make it work, then make it right, then make it fast.”
2) 做必要的优化
优化工作是有成本的,开发团队需要对优化进行仔细的评估并认真地安排优化的优先级。做相关工作时,不妨问问自己下列的问题:
- 优化的要求是否来自真正的客户(对开发框架或程序库,开发人员也是客户)
- 程序真的运行很慢,还是处于可以接受的范围;是否有相关的度量数据,还是用户的直观体验
- 提升运行速度的成本(时间成本,财务成本,对现有版本稳定性的影响等)是多少?是否值得做?
- 具体程序的哪部分需要优化?
3) 代码优化不应该牺牲代码的可读性和可维护性
优化工作可能使代码变得混乱,并且牺牲代码的可读性。如果确实发生这种情况,首先评估当前优化是否已经满足性能的要求;如果确实需要进一步优化,需要考虑替代的方案,如扩展或重新设计。总之, 需要在生成易读且易维护的代码和运行速度之间找到一个平衡点。
参考资料