Last month we looked at several principles of object-oriented design and tried to translate them, into principles of version-control for task-based development with workspaces, changes, and baselines. This month we extend our "translation" efforts from OOD principles to codelines, branching and promotion. The result is that we expand our scope from task-based development (TBD) to project-oriented branching (POB).
Principles of Object-Oriented Design
The principles of object-oriented design address the need to minimize the complexity and impact of change by minimizing dependencies through the use of loosely coupled and highly cohesive classes, interfaces, and packages. Classes, interfaces and packages are the logical containers of software functionality. These logical entitities are realized in "physical" containers of version control (configuration elements) in the form of files, libraries and components, and are as follows:
| Principles of Class Design | ||
|---|---|---|
|
SRP |
A class should have one, and only one, reason to change. |
|
|
OCP |
A class should be open for extension (of its behavior) but closed against modification (of its contents). |
|
|
LSP |
Derived classes must be substitutable for (require no more, and ensure no less than) their base classes. |
|
|
DIP |
Depend on abstract interfaces, not on concrete details. |
|
|
ISP |
Make fine grained interfaces that are client specific. |
|
|
LOD |
The Law Of Demeter |
Objects and their methods should assume as little as possible about the structure or properties of other objects (including its own subcomponents). |
|
DRY |
Don't Repeat Yourself! Every piece of knowledge should have one authoritative, unambiguous representation within the system |
|
| Principles of Package Design | ||
|
REP |
The granule of reuse is the granule of release. |
|
|
CCP |
Classes that change together are packaged together. |
|
|
CRP |
Classes that are used together are packaged together. |
|
| Principles of Package Coupling | ||
|
ADP |
The dependency graph of packages shall contain no cycles. |
|
|
SDP |
Depend in the direction of stability. |
|
|
SAP |
Abstractness increases with stability. |
|
Last month we derived from the above several principles related to version control containers in general. This month we wish to go a step further and apply those translations to changes/workspaces, baselines, and codelines to arrive at a concrete set of principles for version control.
As a refresher, when translating the OOD terms to version control terms, we concluded the following:
- Classes & packages correspond to any version control " container": changes, workspaces, versions, configurations, baselines and codelines. Our version control objects are "containers" that have their own state, contents and unique identifier. Previously published notions of container-based/component-based SCM are a precedent for this frame of thinking.
- Abstraction/Abstractness relates to the "liveness" or "velocity" of the flow of change/activity for an item's contents. A more "conservative" flow tries to conserve "present value" while a more "progressive" flow tries to add value at a faster rate of progress.
- Stability directly relates to the level of quality assurance of an item. The stability of a container is the extent to which its contents are of consistently reliable quality.
Now lets use these to derive and explore principles of Task-Based Development and principles of change-flow across multiple codelines to support Project-Oriented Branching , which is a natural extension of task-based development at the next level of scale and visibility.
General Principles of Container-Based Versioning
First let's review our more general translations from last month, and refine them a bit (and give them some names). The ones that are still too
About the author
Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.
About the author
Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.
