《持续交付 发布可靠软件的系统方法》读书笔记
当我们说起组件时，是指应用程序中的一个规模相当大的代码结构，它具有一套定义良好的 API，而且可以被另一种实现方式代替。 对于一个基于组件的软件系统来说，通常其代码库被分成多个相互分离的部分，每个部分通过个数有限的定义良好的接口提供一些服务行为，与其他组件进行有限的交互。
基于组件的设计通常被认为是一种良好的架构，具有松耦合性，是一种鼓励重用的设计。事实也确实如此。但它还有另外一个重要的好处：对于大型软件开发团队的协作来说，它是最有效的方法之一。
保持应用程序可发布
为了在变更的同时还能保持应用程序的可发布，有如下四种应对策略：
将新功能隐蔽起来，直到它完成为止。
将所有的变更都变成一系列的增量式小修改，而且每次小的修改都是可发布的。
使用通过抽象来模拟分支（branch by abstraction）的方式对代码库进行大范围的变更。
使用组件，根据不同部分修改的频率对应用程序进行解耦。
依赖
在构建或运行软件时，软件的一部分要依赖于另一部分，就产生了依赖关系。
组件（component）和库（library）之间的差异，库是指团队除了选择权以外，没有控制权的那些软件包，它们通常很少更新。相反，组件是指应用程序所依赖的部分软件块，但它通常是由你自己的团队或你公司中的其他团队开发的。组件通常更新频繁。这种区别非常重要，因为当设计构建流程时，处理组件要比处理库所需考虑的事情多一些。
构建时依赖与运行时依赖之间的差异，构建时依赖会出现在应用程序编译和链接时（如果需要编译和链接的话）；而运行时依赖会出现在应用程序运行并完成它的某些操作时。
组件
几乎所有的现代软件系统都是由组件组成的。
为什么说组件开发方式让软件开发流程更高效：
它将问题分成更小且更达意的代码块。
组件常常表示出系统不同部分代码的变化率不同，并且有不同的生命周期。
它鼓励我们使用清晰的职责描述来设计并维护软件，反过来也限制了因修改产生的影响，并使理解和修改代码库变得更容易。
它给我们提供了额外的自由度来优化构建和部署过程。
并不建议让每个团队各自负责一个独立的组件。因为在大多数情况下，需求不会按组件的边界来分。根据我们的经验，那些有能力开发端到端功能的跨功能团队更加高效。尽管一个团队负责一个组件看上去好像更高效，但事实并非如此。
常常很难只修改一个单独的组件就能实现和测试某个需求，因为通常实现一个功能需要修改多个组件。如果你按组件划分团队的话，就需要两个或以上的团队合作才能完成一个功能，自然会增加更多且非必要的沟通成本。而且，在围绕组件组成的团队中，大家倾向于形成“筒仓”（silo），并进行局部优化，从而失去从全局观点出发来评判项目的最佳利益的能力。
最好划分多个团队，以便每个团队都可以拿到一系列的用户故事（这些故事可能属于同一主题）。为了完成这些需求，每个团队都可以修改任何组件的代码。一个团队为了实现某个业务特性可以自由修改任何组件是一种更高效的工作方式。依据功能领域而不是组件来组建团队确保了每个人都有权力修改代码库的任何部分，同时在团队之间定期交换人员，确保团队之间有良好的沟通。
小结
讨论了既能让应用程序一直处于可发布状态，又能尽可能让团队高效开发的技术。原则就是确保团队尽快得到代码修改后所产生的影响。达到这一目标的一种策略就是确保将每次修改都分解成小且增量式的步骤，并小步提交。还有一种策略是将应用程序分解成多个组件。
将应用程序分解成一组松耦合且具有良好封闭性的协作组件不只是一种好的设计。而且，对于一个大系统的开发来说，还可以提高工作效率，得到更快的反馈。直到应用程序变得足够大时，才需要对组件进行分别构建。
4726
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
