由于日程表压力困扰着许多项目,开发者经常用实现的第一个算法解决一个细节问题。除了引入通常的bug来实现之外(像在一个循环内部初始化变量),开发者没能考虑他们选择的算法的负载特性。在开发过程的早期阶段的小心计划可以预防这种问题。就像在大部分软件工程中,这是最常用的“最少花费”的解决方案。如果无意中做出未经周全考虑的选择,那么在选择测试中越早发现问题损失也越少。
未能及时得发现性能缺陷直到项目开发周期的最后实在不是一个有效的算法。比如说,如果测试数据容量较低且是不过分混乱,冒泡排序在测试中似乎运行的很好。可是,在一个真实世界的条件下其性能将陷入一个无法接受的水平。在另一个极端,一些运算法则可能对大容量的数据更快速更有效,但是对于小容量数据却不是最好的选择。如果一个算法不经过预想条件下的全面测试,对于性能的影响将是非常消极的,你的客户也许开始在其他的地方寻求解决方案。
上一页 | 下一页 |
拙劣地调整数据库 | 提供不充分的性能测试 |