74. 性能调优的道路上遍布脏代码炸弹

性能调优的道路上遍布脏代码炸弹

        通常，系统的性能调优需要你修改代码。当你需要修改代码的时候，每个过于复杂或者高耦合的代码块都是一个脏代码炸弹，随时会让你需要付出的努力变得失控。脏代码对你造成的第一个伤害就会是你的日程安排。如果能顺畅地前进，就很容易预测结束时间；遇到非预期的脏代码会让进行明智的预测变得非常困难。
        考虑当你遇到一个执行热点的情况。通常的做法是减少底层算法的强度。假设你回应你的经理，回答说估计时间需要3到4个小时。当应用你的修改时，你很快发现自己破坏了一些依赖。由于紧密相关的东西经常有必需的耦合，破坏这个依赖很可能已经预计并考虑到了。但是如果修复这个依赖时导致了其它部分的依赖性被破坏会怎么样？此外，远一点的依赖不太可能在你预估时发现并考虑到。于是突然之间，原先3到4个小时的预估很容易就膨胀到了3到4周。通常，这种非预期的膨胀每1到2天就发生一次，“快速的”重构实际上需要几个月才能完成的情况并不罕见。这些情况对你的信誉及负责团队的政治资本就会严重损失甚至是终结了，除非我们有用来帮助发现并度量这种风险的工具。
        事实上，我们有很多度量并控制我们代码的耦合性和复杂性的维度和深度的方法。软件度量就可以用来计算指定的特性在代码中出现的次数。这些计数确实与代码的质量相关。度量耦合性的两个数字是fi和fo。类的fo是：某个类直接或者间接引用的其它类的数量。你可以认为在你的类编译之前必需编译的其它类的数量。另一方面，fi是依赖某个类的类的数量。知道fo和fi后，我们可以计算不稳定性，使用公式：I = fo / (fi + fo)。随着I趋近于0，包变得更加稳定；I趋近于1，包变得更不稳定。稳定的包是记录的低风险目标，而不稳定的包则很可能充满了脏代码炸弹。重构的目标就是让I更接近于0。
        使用软件度量时，需要记住它们只是经验法则。纯数据上看，通过增加fi、fo不变也能将I趋近于0。但是，非常大的fi类也会非常难以在不打破依赖的情况下改变。同样，不改变fo也不算真正减少了风险，所以必须做一些平衡。
        软件度量工具的一个缺点是工具产生的大量数字可能让缺少相关知识的人望而却步。尽管如此，软件度量工具可以在我们为干净代码的战斗成为一个强大的工具。它们可以帮我们找到并消灭脏代码炸弹，在它们成为性能调优过程中的严重问题之前。

原文：The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine