The Road to Performance Is Littered with Dirty Code Bombs
来源:互联网 发布:新浪云平台数据库 编辑:程序博客网 时间:2024/05/16 17:11
The Road to Performance Is Littered with Dirty Code Bombs
Kirk Pepperdine
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 eas- ily balloon to 3–4 weeks. Often, this unexpected inflation in the schedule hap- pens 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….
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
148 97 Things Every Programmer Should Know

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 calcu- late 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. Pack- ages 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.
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.
One downside to software metrics is that the huge array of numbers that met- rics 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.
- The Road to Performance Is Littered with Dirty Code Bombs
- The Road to Performance Is Littered with Dirty Code Bombs
- CodeForces 228E The Road to Berland is Paved With Good Intentions 2Sat求解
- CodeForces 228E The Road to Berland is Paved With Good Intentions (2-Sat)
- Add Code to caculate the Scanner Performance
- Codeforces 228E The Road to Berland is Paved With Good Intentions 枚举dfs判断可行性 || 并查集
- Codeforces Round #141 (Div. 2)E. The Road to Berland is Paved With Good Intentions(2-SAT模板题)
- The road to a lover’s house is never long
- How to write the fast code/ high performance in C#
- The Volume is dirty 的解决方法
- The volume is dirty,出现蓝屏,解决方案
- dirty code
- How to solve “add/remove operation is impossible, because the code element 'Cxxx' is read only” With
- How to fetch the SQL scipts with worst performance
- The road to xunlei
- The Road to Success
- The Road to RAD (A)
- The road to Java(1)
- 甘特图——Excel搞定
- Android——SharedPreferences实现登录界面的记住密码和自动登录功能
- PHP的包依赖管理工具Composer简介
- Resist the Temptation of the Singleton Pattern
- HDU 1385(Minimum Transport Cost)floyd+正向返回路径
- The Road to Performance Is Littered with Dirty Code Bombs
- PHP管理依赖(dependency)关系工具 Composer的自动加载(autoload)
- Object-c分类和协议
- 计算机网络概述
- String to Integer (atoi)
- 黑马程序员——反射高级应用之动态代理
- 关于mvc的一些体会,看到这一篇感觉领悟到了,所以记录下来
- Android编程读写首选项
- 关于pymongo中“False is not a read preference”问题的解决方案