脏代码炸弹搅乱性能之道路

The Road to Performance Is Littered with Dirty Code Bombs

通常,对系统性能调优需要你修改代码。当我们需要修改代码时,每处过于复杂或高耦合的代码块都是脏代码炸弹,等着蓄谋(让程序)跑飞。脏代码造成的第一批伤亡就会成为你的日程表。倘若前进的道路是平坦的,那你很容易预估完成时间。倘若遇到那些意外的脏代码,想要做出合理的预估就难咯。

试想一下你发现了某个执行热点的情况。常规的做法是将低基础算法的强度。假设你对经理的要求给出了预计3-4小时的答案。然后着手开始修复,你会很快意识到某个依赖部分被破坏了。通常关系密切的事物都是高内聚的,这次破坏更像是找到了原因并得到了解决。但如果把这里的依赖结果修复掉,那其他还在破损的抵赖部分又会发生什么呢?此外,这项依赖离它的发生出越远,你就越不可能在预估中辨别并解决它。很快,你的3-4个小时就会膨胀为3-4个星期。通常,这些意外会在日程表里放大到一两天。需要数月才能完成的“快速”重构并不常见。在这些情况中,一个有责任的团队的信誉及政治资本都会遭到极大(甚至是终极)的损害。如果我们能有个工具帮我们识别并量化这些风险。。。

事实上,我们有很多量化和控制代码耦合度及复杂度的方法。软件指标可以用来计数我们代码中具体功能出现的次数。这些计数与代码质量息息相关。衡量耦合度的指标之二即扇入和扇出。类中所谓的扇出:定义为直接或间引用感兴趣类的次数。你可以理解为你的类被编译之前需要编译的其它类的数量。另一方面,扇入就是指所有其它类对这个感兴趣的类的引用次数。知道了扇入和扇出,我们就使用I = fo / (fi + fo)计算一个不稳定因素。若结I趋近于0,这个包就会很稳定。若I趋近于1,这个包就不稳定。稳定的包对于重新写代码是低风险的,而不稳定的包更像是充满脏代码的炸弹。重构的目标当然是使I更接近于0.

使用指标时必须记住,它们只是经验法则。基于纯粹的数学,我们可以在fo不变的情况下增大fi,照样可以使I接近0.然而,又一个非常高的扇入值是很糟糕的:如果破解依赖关系,很多类就难以再修改。当然,如果不解决扇出问题,你就不可能切实降低风险,所以必须保持一定平衡。

软件指标的一大缺点是,计量工具所产生的大体量的软件指标数字可能会震惊到初学者。就是说,软件指标可以变成我们争取干净代码的利器。它们可以帮助我们辨别并消除脏代码炸弹,以免它们严重影响性能调整工作。

0%