(Difference between revisions)
|-|Performance problems are a direct result of how you coded your application to use the available hardware. While one can sometimes solve the problem by adding more hardware, quite often the best or only solution is to alter code . By starting down that path you've just agreed to take on all the risk that comes when you start to change code. Furthermore, the quality of the code will have an inverse affect on your ability to estimate how long it will take to finish the recoding. |+|
to is code
| || |
|-|Take the case where you find an execution hotspot in the application. You then proceed to reduce the strength of the underlying algorithm and in the process you break some a dependent part. You then are required to fix the dependency. If in that process of fixing the dependency you happen to break one or more other dependent parts, once again you will be forced to fix those also. While you may have accounted for some of the dependencies, if the code is highly coupled you may have missed a few which will result in an under-estimation of the amount of work needed to get the job done. In this case we have a clear definition for loose coupling and a dependency. So why can' t we have a tool count the violations and report back to us? Such a count should help us understand our risk to schedule. |+|
of and . of youwill . you of the is highly coupled a in to the . a 'to a .
| || |
|-|In fact we have many ways of measuring the degree and depth of couplings in an application. Included in the list are Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, depth of hierarchy and so on. These metrics describe features in our code that we can enumerate using a metrics tool. With a little experience, we can infer code quality by inspecting the magnitude of the counts. Consider fan out for example. Fan out is defined as the number of classes that is dependent upon a class of interest. Think of it as a count of the number of classes that require the class of interest to be compiled before it can be compiled. That number represents the fan out value for the class of interest. If for every class in an application this value is small, you'd conclude that the application was loosely coupled. The upside is that I can refactor with minimal risk that my breakages will also fan out. |+|
the an . the of of . that a . , . that is dependent . the the to it for of . the was coupled. risk.
| || |
|-|Though the discussion has focused on measuring couplings , it could have easily focused on complexity, vocabulary and volume, cohesion and a host of other metrics. Each of these metrics is a measure of code quality and hence a way to determine risk to schedule should you have to touch the code. |+|
measuring couplings complexity , and , and . metrics code and the code .
| || |
|-|We all believe that we write good code. That said, the truth is as close as a good metrics tool. And if you don’t like what the metrics tool is telling you, try a good dose of Uncle Bob’s book, Clean Code. |+|
is as a . the is , a
of , .
| || |
| || |
Revision as of 13:52, 31 October 2008
New title, The road to performance is littered with dirty code bombs
There are two distinct sources of performance problems, those from configured and those from code. Getting rid of performance problems you've coded into your system will necessarily involve refactoring. When you set out to performance tune, every bit of the system that is overly complex or highly coupled is a dirty code bomb laying in wait to derail the exercise. While traveling down a smooth road makes it easy to prediction when you'll reach your destination, lining that same road with dirty code makes it just about impossible to make a sane prediction.
Consider the case where you find an execution hot spot. You will quickly realize that you’re going to need to reduce the strength of the underlying algorithm by recoding it. lest say you respond to your managers request for an estimate with an answer of 3-4 hours. You apply the fix only to realize that you’ve broken a dependent part. Since closely related things are often necessarily coupled, you’ve expected this to happen. But what happens if that dependent part is far away and what happens if in fixing that dependency you break other dependent parts. The farther away from the dependency is from the source the less likely you are to recognize it and account for it in your estimate. Breaking even more dependent parts will have just put your schedule at risk if it already hasn’t been blown. All of a sudden your 3-4 hour estimate may have ballooned to 3-4 weeks often 1 or 2 days at a time. In cases where the code was highly coupled, “quick” refactorings ended up taking several months to complete. In these cases, damage to the credibility and political capital of the refactoring team has ranged 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 the degree and depth of couplings and complexity of our code. Included are; Law of Demeter, Coupling between Objects (CBO), fan in, fan out, efferent and afferent couplings, McCabe cyclometric and so on. These metrics describe features in our code that we can look for and count. More over, the magnitudes of these counts infer code quality. Consider fan out for example.
Fan out is defined as the number of classes that is dependent upon a class of interest. Think of it as the number of classes that must be compiled in order to compile the class of interest. If for every class in an application this value is small, you can conclude that couplings were shallow. Conclusion: couplings pose a minimal risk were I to refactor.
A downside of software metrics is that the huge array of numbers that metrics tools will produce can be intimidating to the uninitiated. That said, software metrics is a powerful tool in our fight for clean code that can help us eliminate dirty code bombs before they are a serious risk to a performance tuning exercise.
By Kirk Pepperdine
This work is licensed under a
Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page