1 component integration principle
1.1 producers and consumers
The developers of different components are usually in a production person and consumers, that is, the production person delivery workpiece is provided to consumers. Producer delivery workpieces are: Original workpiece (source code, build script, profile, etc.), middle (Derive) workpiece (OBJ file, library, etc.), final product (PRODUCT) workpiece (executable file, DLL Library, etc.), other temporal workpieces (temporary files generated by the compiler). Consumers will use these workpieces. This consumption relationship in the C project contains: compiles the public (public) header file that references them, links the static library files (or OBJ files) of the other party, and the generated final execution file calls the dynamic link library of others.
In addition to the original (Original) workpiece, other derived workpieces can be generated by building a process, in order to simplify the dependence of producers and consumers, maintain the consistency of the original workpiece version, and reduce the overhead of configuration management, producers Try to use the original workpiece to consumers, consumers rely on building scripts to generate the derived workpieces they need (for efficiency, consumers can also directly use the final product workpiece built by producer, The consequence is that the risk of version conflicts becomes large, and the overhead of configuration management is increased).
In order to meet the needs of only submit the original workpiece, the high-quality building script has become particularly important. If the build process adds the consumer's burden, or the construction failure occurs, the consumer will be more direct. The product workpiece after the producer is taken in the hands of the producer.
Ideally, producers may deliver their dependencies before consumers, but usually teams will use parallel development models, consumers must start working before the producer is completed, so develops alternative piles (STUB) ) The code, even for the convenience of debugging, specializing in the imitation (MOCK) code, it has become a homemade. According to the actual needs, the alternative code can be developed by the producer itself or consumers. In response to this situation, when writing build scripts, the corresponding compile, link options should be provided so that consumers can freely choose to compile the delivery code or pile (stub) code, link to his constructed work version, while the members also These options can be utilized to carry out incrementally iterative integration.
1.2 Source Catalog Organization Organization
The development of directory organizational structure has never been related to the key factors of healthy growth. Development (Product) Catalog provides a unified share place for project team development, management, etc., which needs to meet a variety of scene requirements for different types of workpieces in different stages, access to different types of artifacts. Because the project's code implementation, integration and other activities are far more difficult than other documents, it is more difficult to complicate, and the synergistic integration is more difficult, making reasonable source organizational structures extremely important, architects and configuration administrators must invest more Multi-energy attention to the source code organization part in the development (product) directory.
The primary principle of the source catalog organization is the unity of the directory structure. In the project, a unified classification method, the same style, consistent naming format should be used to create the source directory of all components. This project involves a third-party library, project component, subsystem, system four-class component, and its source catalog structure adopts the same basic directory structure, and has done corresponding extensions according to their respective needs.
The organization of the development (product) catalog should try to use the same classification standard in the directory of the same level. The catalog classification standard is: according to the workpiece type (SRC / BIN / LIB / DOC / MDL / SCRIPT / Web / XDOC), according to the workpiece function or use (Build / Test / Interface / Example), according to the activity organization (Plan / Requirement / Design ), According to the home relationship (third-party library 3rd lib / base component Components / Subsystem), and so on. As shown in the figure below, in this project, the first level directory is divided according to the home relationship, the second-level directory of the source code component is divided according to the component design package structure, and the third-level directory of the source code component is in accordance with the workpiece type and combined with the workpiece purpose. Divide.
Development (Product) Catalog should collaborate for teams. It is necessary to do relationships to be relatively independent in private space development, and to ensure synchronization with others, and achieve integration smoothly. This will rely on the support of the software configuration management tool, which can better reach the above objectives.
The development (product) catalog itself can be seen as a workpiece of the project. As the project progresses, the code needs to experience the reconstruction, the directory structure is no exception. The fully fixed directory structure is unrealistic in the initial stage of the project. Currently supports the contents of the directory, and can easily modify the configuration management tools for the directory structure, which is one of the reasons why ClearCase is the main representative, which is one of the reasons why this item uses ClearCase.
