As a matter of fact, many projects fail due to lack of software quality. Therefore, having an eye on code quality is not just an option, but may well prove mission critical. Furthermore, it's not appropriate to push quality control to the end of the software engineering process. Since early detection of quality issues makes them easy to resolve, monitoring quality should be placed as close as possible to the developer.
Over the past few years we observe that more and more companies recognize the importance of software quality. As part of this trend, testing has been widely accepted as an integral part of development. However, testing alone is only one step to go on our way to high quality software products. Equally important, we need to continuously validate our software against well established design principles, helping us to improve maintainability, flexibility as well as – testability.
When looking for solutions to ease development, control design and improve quality, it is worth considering the integration of structure analysis into the software engineering process. This is where STAN, a new structure analysis tool for Java, comes into play. STAN puts quality assurance to the hand of the developer, thereby achieving these goals with minimal effort.
Artifacts are the things that make up a code base. For example, in Java, methods and fields are the building blocks for classes. Classes are organized into packages and packages are bundled into libraries. Finally, a set of libraries makes up an application. Members and classes lie on the code layer, whereas packages and libraries lie on the design layer.
Software Structure is understood as the way
During development, the structure constantly changes. E. g., a new class is placed into a particular package or a new method adds dependencies to other classes and packages. Structure is not just something hidden in the background. Structure reflects our design. Structure is our design!
Rotten versus Good Design
As long as a project is small, developers have a vital image of their design in mind. They know every corner of their code and everything seems to be under control. As the project size evolves, however, things change: suddenly the software is hard to test, extend and maintain. It tends to be monolithic and somehow everything seems to depend on everything else. Robert C. Martin describes this as “The software starts to rot like a piece of bad meat”. Moreover, he identifies the following odors (among others):
To the contrary, a good design turns out to be flexible, solid, mobile, fluid and transparent.
The structure of large code bases tends to become very complex. Over-complex systems are hard to understand and maintain and thus do often break. Keeping complexity on a manageable level is a challenge.
We certainly must fail if we let our software structure evolve arbitrarily. It is therefore essential to keep an eye on it. Fortunately, there are common design principles which – if we follow them – can help us to succeed. We need to continuously validate our structure against these principles. And we need to discover and fix design violations early, before our software starts to rot!
|< Prev||Next >|