Database Reference
In-Depth Information
Sometimes requirements also impact the architecture by imposing limits on the utilization of a specific resource.
For example, the architecture of an application to be used by mobile devices connected to the server through a
slow network must absolutely be conceived to support a long latency and a low throughput. As a general rule, the
architects have to foresee not only where the bottlenecks of a solution might be, but also whether these bottlenecks
might jeopardize the fulfillment of the requirements. If the architects do not possess enough information to perform
such a critical estimation a priori, one or even several prototypes should be developed. In this respect, without the
performance figures gathered in the previous phase, making sensible decisions is difficult. By sensible decisions,
I mean those leading to an architecture/design that supports the expected workload with a minimal investment—
simple solutions for simple problems, elegant solutions for complex problems.
Coding and Unit Testing
A professional developer should write code that has the following characteristics:
Robustness:
The ability to cope with unexpected situations is a characteristic any software
should have. To achieve the expected quality, performing unit testing on a regular basis is
essential. This is even more important if you choose an iterative life cycle. In fact, the ability
to quickly refactor existing code is essential in such models. For example, when a routine
is called with a parameter value that is not part of a specific domain, it must nevertheless
be able to handle it without crashing. If necessary, a meaningful error message should be
generated as well.
Maintainability:
Long-term, well-structured, readable, and documented code is much
simpler (and cheaper) to maintain than code that is poorly written and not documented.
For example, a developer who packs several operations in a single line of cryptic code has
chosen the wrong way to demonstrate his intelligence.
Speed:
Code should be optimized to run as fast as possible, especially if a high workload
is expected. It should be scalable, and therefore able to leverage additional hardware
resources to support an increasing number of users or transactions. For example,
unnecessary operations, serialization points, as well as inefficient or unsuitable algorithms,
should be avoided. It is essential, however, to not fall into the
premature optimization
trap.
Shrewd resource utilization:
The code should make the best possible use of the available
resources. Note that this does not always mean using the fewest resources. For example,
an application using parallelization requires many more resources than one where all
operations are serialized, but in some situations parallelization may be the only way to
handle demanding workloads.
Security:
The ability to ensure data confidentiality and integrity, as well as user
authentication and authorization, is undisputed. Sometimes non-repudiation is also
an issue. For example, digital signatures might be required to prevent end-users from
successfully challenging the validity of a communication or contract.
Instrumented:
The aim of instrumentation is twofold. First, it allows for the easier
analysis of both functional and performance problems when they arise—and they will
arise to be sure, even for the most carefully designed system. Second, instrumentation is
the right place to add strategic code that will provide information about an application's
performance. For example, it is usually quite simple to add code that provides information
about the time taken to perform a specific operation. This is a simple yet effective way
to verify whether the application is capable of fulfilling the necessary performance
requirements.
