Title: Optimal

Author: Bob Schmidt

Date: 08 September 2020 18:49:54 +01:00 or Tue, 08 September 2020 18:49:54 +01:00

Summary: 

Body: 

One persistent theme in programming is that before we attempt any kind of optimisation, we should measure what needs to be optimised. This is certainly true when we’re optimising for speed or memory consumption. It’s rare, even for the most experienced programmers, to identify the real bottlenecks or memory hogs just by looking at source code. Performance analysis tools and run-time profilers very often find things we completely overlook as the actual culprits.

There are, however, other kinds of optimisation, not related to CPU cycles, or mega-bytes of memory. One of the rationales behind the advice often paraphrased as “the first rule of optimisation is: don’t” is that altering code to be faster or use less memory very often makes the source code less clear. Source code is read more often read by humans than computers, and optimising for clarity is something we can do that doesn’t usually require us to measure its effects.

Another target for optimisation is testability, at all levels, but especially the unit-test arena. Designing code so that it can be tested with automated tools quickly, and without needing access to environmental facilities like networks, databases and file systems, has consequences that go far beyond the tests. One side-effect is that, more often than not, the code is clearer for human readers, too.

Other targets for optimisation include ease of deployment, robustness under error conditions, supportability and uncomplicated maintenance. Not all of these things are the responsibility of the code, of course, but they all start there. Modular components make it easy to split applications into parts that can be deployed independently of each other. Supportability probably involves some kind of monitoring, with easy-to-understand logging messages. Maintenance often requires someone other than the author of some code to alter its behaviour.

There is one thing that unites them all. Before the first rule of optimisation is the first target of optimisation: clear code.

Notes: 

More fields may be available via dynamicdata ..