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.然而，又一个非常高的扇入值是很糟糕的：如果破解依赖关系，很多类就难以再修改。当然，如果不解决扇出问题，你就不可能切实降低风险，所以必须保持一定平衡。
软件指标的一大缺点是，计量工具所产生的大体量的软件指标数字可能会震惊到初学者。就是说，软件指标可以变成我们争取干净代码的利器。它们可以帮助我们辨别并消除脏代码炸弹，以免它们严重影响性能调整工作。
