Editor’s Note: We believe that performance should be at the forefront of the minds’ of any software developer. Kirk Pepperdine is one of the foremost experts on Java performance tuning, and here shares his wisdom on the whys and hows of removing dirty code to improve software performance.We’d love to know your thoughts on this piece from 97 Things Every Programmer Should Know.

编者注： 我们认为，性能应该在任何软件开发人员的思想中都处于最前沿。 Kirk Pepperdine是Java性能调优的最重要专家之一，在这里他分享了删除脏代码以提高软件性能的原因和方式的智慧。我们很乐意从 每个程序员应该知道的97件事中 了解您对本文的看法 。

More often than not, performance tuning a system requires you to alter code. When we need to alter code, every chunk that is overly complex or highly coupled is a dirty code bomb lying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the way forward is smooth, it will be easy to predict when you’ll finish. Unexpected encounters with dirty code will make it very difficult to make a sane prediction.

通常，对系统进行性能调整需要您更改代码。 当我们需要更改代码时，每个过于复杂或高度耦合的块都是一个肮脏的代码炸弹，它在等待使工作脱轨。 肮脏代码的第一伤亡将是您的日程安排。 如果前进的道路很顺利，那么很容易预测何时完成。 肮脏代码的意外遭遇将使做出明智的预测变得非常困难。

Consider the case where you find an execution hot spot. The normal course of action is to reduce the strength of the underlying algorithm. Let’s say you respond to your manager’s request for an estimate with an answer of 3–4 hours. As you apply the fix, you quickly realize that you’ve broken a dependent part. Since closely related things are often necessarily coupled, this breakage is most likely expected and accounted for. But what happens if fixing that dependency results in other dependent parts breaking? Furthermore, the farther away the dependency is from the origin, the less likely you are to recognize it as such and account for it in your estimate. All of a sudden, your 3–4-hour estimate can easily balloon to 3–4 weeks. Often, this unexpected inflation in the schedule happens one or two days at a time. It is not uncommon to see “quick” refactorings eventually taking several months to complete. In these instances, the damage to the credibility and political capital of the responsible team will range from severe to terminal. If only we had a tool to help us identify and measure this risk…

考虑一下您发现执行热点的情况。 通常的做法是降低基础算法的强度。 假设您以3-4个小时的回答回答了经理的估计要求。 应用此修复程序时，您很快就会意识到自己已经破坏了一个从属部件。 由于密切相关的事物通常必须结合在一起，因此很可能会预料到并造成这种破坏。 但是，如果修复该依赖关系导致其他依赖部件破裂，会发生什么情况呢？ 此外，依赖关系离原点的距离越远，您就越不可能这样认识并在估计中考虑它。 突然之间，您的3到4个小时的估算值很容易膨胀到3到4周。 通常，计划中的这种意外的通货膨胀一次发生一两天。 经常需要数月才能完成“快速”重构，这种情况并不罕见。 在这些情况下，对负责团队的信誉和政治资本的损害将是严重的甚至是最终的。 如果我们只有一个工具可以帮助我们识别和衡量这种风险……

In fact, we have many ways of measuring and controlling the degree and depth of coupling and complexity of our code. Software metrics can be used to count the occurrences of specific features in our code. The values of these counts do correlate with code quality. Two of a number of metrics that measure coupling are fan-in and fan-out. Consider fan-out for classes: it is defined as the number of classes referenced either directly or indirectly from a class of interest. You can think of this as a count of all the classes that must be compiled before your class can be compiled. Fan-in, on the other hand, is a count of all classes that depend upon the class of interest. Knowing fan-out and fan-in, we can calculate an instability factor using I = fo / (fi + fo). As I approaches 0, the package becomes more stable. As I approaches 1, the package becomes unstable. Packages that are stable are low-risk targets for recoding, whereas unstable packages are more likely to be filled with dirty code bombs. The goal in refactoring is to move I closer to 0.

实际上，我们有很多方法可以测量和控制耦合的程度和深度以及代码的复杂性。 软件指标可用于计算代码中特定功能的出现次数。 这些计数的值确实与代码质量相关。 衡量耦合的许多指标中的两个是扇入和扇出。 考虑类的扇出：它定义为直接或间接从感兴趣的类引用的类的数量。 您可以将其视为在编译类之前必须编译的所有类的总数。 另一方面，扇入是依赖于感兴趣类别的所有类别的计数。 知道扇出和扇入，我们可以使用I = fo /(fi + fo)来计算不稳定性因子。 当我接近0时，封装变得更稳定。 当我接近1时，包装变得不稳定。 稳定的程序包是进行重新编码的低风险目标，而不稳定的程序包则更可能充满脏代码弹。 重构的目的是使I接近0。

When using metrics, one must remember that they are only rules of thumb. Based purely on math, we can see that increasing fi without changing fo will move I closer to 0. There is, however, a downside to a very large fan-in value: these classes will be more difficult to alter without breaking dependents. Also, without addressing fan-out, you’re not really reducing your risks, so some balance must be applied.

使用指标时，必须记住它们只是经验法则。 纯粹基于数学，我们可以看到，不改变fo而增加fi会使I接近0。但是，很大的扇入值有一个缺点：这些类在不打破从属关系的情况下将更难更改。 另外，如果不解决扇出问题，实际上并不能降低风险，因此必须保持一定的平衡。

One downside to software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics can be a powerful tool in our fight for clean code. They can help us to identify and eliminate dirty code bombs before they are a serious risk to a performance-tuning exercise.

软件度量标准的一个缺点是，度量标准工具产生的大量数字可能会吓到未开始的人。 也就是说，软件指标可以成为我们争取干净代码的强大工具。 它们可以帮助我们识别和消除肮脏的代码炸弹，以免它们严重影响性能调整工作。

学得更快。 深入挖掘。 看得更远。 (Learn faster. Dig deeper. See farther.)

Join the O’Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

加入O'Reilly在线学习平台。 立即获得免费试用版，即时找到答案，或者掌握一些新的有用的知识。

Learn more

学到更多

Kirk Pepperdine has been performance-tuning Java applications for more than 20 years. He is the author of the original Java Performance Tuning Workshop. In 2006, Kirk was named a Java Champion for his thought leadership in the Java performance space. He speaks frequently at user groups and conferences and has been named a JavaOne Rockstar numerous times. Kirk continues to be an ardent supporter of the Java community as the cofounder of JCrete, a Java unconference that has been used as a template for a number of other unconferences in Europe, Asia, and North America. In 2019 Kirk’s start-up, jClarity, was acquired by Microsoft, where he is now employed as a principal engineer.

Kirk Pepperdine一直在优化Java应用程序的性能超过20年。 他是原始的Java Performance Tuning Workshop的作者。 2006年，Kirk因其在Java性能领域的思想领导力而被任命为Java冠军。 他经常在用户组和会议上发表演讲，并多次被评为JavaOne Rockstar。 作为JCrete的联合创始人，Kirk继续是Java社区的热心支持者，JCrete是Java非会议，已经被用作欧洲，亚洲和北美许多其他非会议的模板。 在2019年，柯克(Kirk)的初创公司jClarity被微软收购，现在他被聘为首席工程师。