Large-Scale C++ Volume I: Process and Architecture (Terrence A. Young's Library) by John Lakos

Author:John Lakos
Language: eng
Format: epub
Publisher: Addison-Wesley Professional
Published: 2020-07-15T00:00:00+00:00

2.16.4 Metadata Summary

In summary, software metadata is as much an engineering work product as the code that the metadata describes; metadata is written by developers and is explicitly not discoverable from the code. Metadata captures the design, policy, and build intents and requirements in a compact form that is both human readable and readable by tools that variously enforce and act on the design rules in the metadata. For large code bases, metadata is not only cost effective, but its relatively small cost returns enormous value, both in routine developer productivity and in safeguarding the value of the software assets.

Of the various kinds of metadata, by far the most important is the dependency metadata. It ensures cycle-free design (vital for both human understanding and for testing) and facilitates communication on design ideas across development teams in large organizations, where daily collegial interactions may not be possible.

Dependency metadata allows clients to specify exactly what they do — and do not — wish to depend on, at any needed level of granularity, and to have tools guarantee that their intentions are enforced.

Policy metadata allows an organization to integrate its specific needs on scales ranging from global across the enterprise to the parochial purview of small teams whose requirements may differ from the enterprise as a whole.

Policy metadata takes the form of boolean predicates that must be satisfied by all code throughout the enterprise, although, as alluded to above, any given policy may apply to an arbitrarily small amount of code. A key example of policy metadata is the explicit specification of the public and private portions of a library.

Build metadata can be partially machine-extracted from dependency and policy metadata (not from the code), and can also be augmented by manually maintained entries. The net result is that even irregular, problematic code can be built with fully automated build tools with a high likelihood of success.

Tom Marshall was the first person I hired (from my previous company, Bear Stearns) after joining Bloomberg back in December, 2001. Tom initially served as a senior developer on my original BDE team (from 2001 to 2005) before moving on to become the founder and leader of the Architecture Office (AO) in Software Infrastructure (SI). The AO coordinates the physical structure of the software that powers the Bloomberg (Professional) Terminal, implementing existing processes, and contributing to the design of new policies that aid in governing that software. Under Tom’s direction, his team manages physical dependencies among discrete software entities, and assists developers in creating, reorganizing, and refactoring new and existing libraries. Separately, Tom has developed numerous software tools used by the AO and its customers to analyze, maintain, and improve the hierarchy, restructure/refactor production code, and facilitate routine operations. Finally, the AO has a strong educational component to its mission: (1) formal training, and (2) informal collaboration and consulting.

Peter Wainwright joined the BDE team (c. 2003) as its first tools developer. Seeded with the basic ideas presented in this chapter, Peter began to design a data model (consisting

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.