|
Diagram
|
|
|
|
|
Title
|
|
|
Readability and Authoring Standards
|
|
Building Architecture
|
|
|
Typography and photography at the Bauhaus helped to give birth to modern graphic design and commercial art in print and other media. The Bauhaus popularised the use of lower case as a standard. The "Bauhaus" type font was also one of the first of the modern fonts that could be used in magazines, television and computer screens. The simple lines made the font easier to read. In turn improved readability created a culture for the rapid consumption of information.
|
|
Architecture Intensive Disciplines
|
|
|
When developing authoring standards, one of the key objectives is readability - a form of internal architecture that balances structure, function and aesthetics. Readability of source code in programming can improve not only the quality of the software but also the productivity in the team development process. Teams often strive for a programming standard that produces source code that seems to have been written by one person rather than individuals with varied approaches.
|
|
Case Study A: Large Corporate IT
|
|
|
|
|
|
One of the challenges in architecture and software quality is to get developers to conform to standards. It is not simply a matter of autocratically enforcing compliance. The best results came from winning people over to accept common values and principles. For instance, if the practice being encouraged involved authoring standards (naming conventions, lower case, identation, prefixes and use of standards for variables and data types), we found it better to first establish an appreciation for the value and principles associated with "shared ownership of code", "oneness", "readability" and "ease of maintenance". We enforced the standards with one project group and built shared values with another. We found that the latter not only complied but taught and defended the standards.
|
|
Case Study B: Small Commercial Team
|
|
|
|
|
|
One of the first documents to be produced was an Authoring Standard agreed to by the team. We had discussed the various abstraction layers - conceptual, logical and physical - illustrating how names and terms can be defined or written in different ways depending on the abstraction layer. For instance the term "customer transaction" could be found in a business analysis document describing real world scenarios. A logical design may involve the naming of an abstract module as "CustomerTransaction". A physical component or unit of construction could be named "cls_customer_transaction" or "prc_customer_transaction". The prefix "cls" indicates the unit of construction to be a class as opposed to "prc" which indicates a stored procedure. We then determined to use prefix for all physical components or source code units. As part of the source code, we included an XML file called "the prefix map" which mapped all prefixes and their description or logic and rules.
|
|
|
