[續上兩篇的內容] 在 paper 中一共提到 11 個 patterns（參考下表），前兩天 Teddy 介紹（其實也不算介紹，只是把內容貼出來）了其中兩個，今天把剩下的用 Problem-Solution 的簡短形式全部介紹完畢。相信大部分的鄉民們應該都沒把內容看完... 如果是換作 Teddy，應該也是看不下去... XD... 但是切記這幾篇的目的是『作帳』，對於內容是否過於文言文就不要太計較啦。
Category | Patterns |
| Project | Installation Project, Single Shared Library Project, Interface Project, Cross-Platform Project, Native Project, Patch Project |
| Build | Local Private Build, Remote Private Build, Cross-Platform Integration, Integration Workflow |
| Good Habit | Single Responsible Person |
Interface Project
Problem: How to isolate platform and implementation specific code from platform-independent projects?
Solution: Define programming interfaces to encapsulate platform-dependent services or to allow a service to have multiple implementations. Put the interface definition code in an interface project. Do not mix interface definition code with interface implementation one. “Programming to an interface, not an implementation” and “dependence injection” are well-know software development practices that require clearly defined interfaces. For cross-platform software, strictly separating interfaces from the implementation hides platform-dependent details and enhances the flexibility and maintainability of software systems.
***
Cross-Platform Project
Problem: How to organize platform-independent code?
Solution: Classify implementation code into two types: platform-dependent and platform-dependent. Put platform-independent code in cross-platform projects. From the continuous integration perspective, cross-platform projects are easier to build and test. They can be built and tested by using virtual machines such as VMWare, VirtualBox, and Xen. Developers can quickly verify cross-platform projects by making a Local Private Build before the projects are committed for integration.
***
Native Project
Problem: How to organize platform-specific code?
Solution: Classify implementation code into two types: platform-dependent and platform-dependent. Put platform-dependent code in native projects. Native projects can be built on virtual machines if they depend on operating systems rather than on hardware. For hardware dependent native projects, a Remote Private Build can be used before they are committed for integration.
***
Patch Project
Problem: How to produce quick fixes to resolve problems without reinstalling the whole software?
Solution: Create a patch project to generate patch files. One way to produce a patch file is to perform a “diff” on the two different software versions and package the difference in the patch file. The patch file also contains a script to upgrade necessary files on the system to be patched.
***
Local Private Build
Problem: How to prevent a broken build?
Solution: Build a project locally before it is committed. You can make a local build by pressing a build button in your IDE or by running a pre-defined build script. Use the same build script executed by the continuous integration system to make a local build can further reduce the possibility of causing a broken build.
***
Remote Private Build
Problem: How to prevent a broken build?
Solution: Use a remote agent to build a project before it is committed. The remote agent’s platform provides an environment that is required to build the project. This pattern is usually used to verify a Native Project that requires a build environment that is different from the local development environment. Continuous integrations systems such as JCIS, CruiseControl, Hudson, Buildbot, TeamCity, and Bamboo support this pattern.
***
Cross-Platform Integration
Problem: How to build cross-platform products?
Solution: Use a continuous integration system that supports cross-platform integration. Apply Integration Workflow to guide the continuous integration system to dispatch projects on suitable remote platforms for integration. Continuous integration systems supporting this pattern include JCIS, CruiseControl, Hudson, Buildbot, TeamCity, and Bamboo.
***
Integration Workflow
Problem: How to manage the continuous integration process for a cross-platform product containing interdependent projects?
Solution: Design integration workflows to control the continuous integration process. Two types of essential integration workflows are concerned: intra-project and inter-project. The former decides which integration activities (e.g., compilation, testing, test coverage analyzing, and packaging) to be included in a build and the execution order of each integration activities. The latter decides the build order of all projects according to the relations of project references.
***
Single Responsible Person
Problem: How to deal with a broken build?
Solution: Assign a person in your team who will be notified once a build was broken. This pattern prevents broken builds from being ignored; especially those caused by overnight build scripts.
***
看完這三篇並寫出心得者請向 Teddy 兌換綠色乖乖一包。
友藏內心獨白：To 某學弟 -- 『終於有新文章了，啊你有認真在看嗎？』
