When I say “our” I am of course referring to the editorial we. I did not mean to imply that your code stinks. How could I know that? I haven’t even seen it. If it does stink, it’s not for the reasons you think. The ultimate audience for your code is not another developer. It’s someone much more unpredictable: a user. The sooner you face up to the fact that your code stinks the easier the road ahead will be.
When a user declares that some piece of software stinks, the complaints normally fall into one of three categories:
- It is difficult to use
- It crashes
- Performance is poor
Notice what this list does not contain: lack of comments, bad framework choices, incorrect design patterns, lack of OO purity, poor variable naming conventions. You get the idea. All these things are important (and the subject of many good books) but users don’t care. Users want software that is easy to use, resilient, and impossibly fast (even when they try crazy stuff). There are people with fashion sense and trendy footwear who handle the interface design, so clearly if the software is difficult to use, it is through no fault of the developer. Since we’re all professionals, I am going to assume #2 is covered (mostly). That leaves us with #3: performance. Oh, how i hate that word. Buy faster hardware and leave me be!
Performance, it turns out, is not so difficult (well maybe it still is but you can at least make your life easier). It starts with your test data. Your goal as the developer should be to find a data sample that is so mind bogglingly huge that no user could ever even conceive of it. Finding that data is no easy task. You have to consider what a “big” sample looks like right now, what it will look like in a year, and what it will look like in five years. Oh sure, you’ll be long gone in five years but trust me, these things, much like a bad penny, have a way of finding you. Test with that five year data and you won’t be sorry. If someone tells you they have no idea what the data will look like in five years or even what a “big” sample looks like, then stop. Stop developing and don’t start again until you figure that out. Do yourself a favor and find the biggest insurance policy, table, spreadsheet, XML file or image you can, then use it, daily.
The second item you’ll need is a baseline. How fast does your application perform with that crazy test data? Write that number down and keep it in a safe place. After you make a change, re-test and compare the results to your baseline. Did the code get slower? You know immediately what you did and stand a better chance of fixing it. If you can, get multiple baselines with the same data and average them just as a sanity check.
The third key to ensuring proper performance is profiling. You have to understand what your application is doing at run-time. How many times will that method be called? How often are files being read? How long does it take to find an item in that collection? These are all good questions and a good profiler can answer all of them. It’s nearly impossible to guess these answers, so don’t even try. The profiler will tell you exactly where to look and what to fix. Every time I’ve ever tried to guess the source of a performance bottleneck, I wasted time optimizing code that wasn't really the problem. A profiler will quickly help you isolate the bottleneck. There’s even one built into Visual Studio. Multi-tier applications can be complex to profile but you can always divide and conquer by profiling each tier separately.
Once you have isolated you’re bottleneck, optimize it. Optimizing code is an art unto itself. All I’ll say about this topic is that unknown loops are the enemy. Always know what’s going on inside of a loop and how many times you’ll be doing it.
To sum it all up:
Big Data –> Baseline –> Profile –> Isolate –> Optimize –> Repeat
Follow these simple steps and you may hear “this code stinks!” from a user again. No guarantees about the coder in the next cubicle.
0 comments:
Post a Comment