关于软件开发:软件开发中的上游和下游

What is Upstream and Downstream in Software Development 的中文翻译版本。

在最近一段时间，我开始在软件开发环境中接触到“上游”和“上游”这两个词，经常疑惑不解。每次我都必须查一下它的含意，因而决定将它们写成 blog 来帮忙了解。

生产过程中的上游和上游

让咱们从一个简略的生产过程开始，只管它与软件开发无关，然而咱们能够在此基础上定义软件开发的上游和上游。

在下面的例子中，咱们有三个步骤:

1. 收集整机
2. 组装整机
3. 绘制拆卸体

下面的生产过程与河流十分类似，因而很容易了解 随着流程从一步到下一步，逐渐向 ” 上游 ” 挪动

咱们能够推断以下规定:

1. 依赖规定: 每个以后的我的项目都依赖于上游的所有我的项目
2. 增值规定: 在向上游挪动的过程中，每一步都为产品减少更多价值

当初，让咱们尝试将这些规定利用于不同的软件开发环境。

软件依赖中的上游和上游

大多数软件组件都依赖于其余组件。那么什么是上游依赖和上游依赖呢？

如图所示:

组件 C 依赖于组件 B，而组件 B 又依赖于组件 A。

利用 依赖规定，咱们能够必定地说组件 A 是组件 B 的上游，而组件 B 是组件 C 的上游（即便箭头指向另一个方向）。

在这里利用 价值规定 有点形象，但咱们能够说组件 C 领有最大的价值，因为它“导入”了组件 B 和 A 的所有特色，并将本人的价值增加到这些特色中，使其成为上游组件。

上游和上游开源我的项目

另一个常常应用“上游”和“上游”这两个词的环境是开源开发。它实际上与下面探讨的组件依赖关系十分类似

思考我的项目 A 和 B，其中 A 是原始我的项目，B 是 A 的分支：

这是开源我的项目中相当常见的开发格调：咱们创立我的项目的分支，修复谬误或在该分支中增加性能，而后向原始我的项目提交补丁。

在这种状况下，依赖规定 使我的项目 A 成为上游我的项目，因为它能够在没有我的项目 B 的状况下很好地生存，但如果没有我的项目 A（原始我的项目），我的项目 B（分叉）甚至不会存在。

价值规定 在这里也实用：我的项目 B 增加了新性能或谬误修复，它为原始我的项目 A 减少了价值。

因而，每次咱们向开源我的项目奉献补丁时，咱们都能够说 咱们曾经向上游发送了补丁。

微服务架构中的上下游

在由微服务（或者只是老式分布式服务）组成的零碎中，也有对于上游和上游服务的探讨。

依赖规定 和价值规定 也实用于这种状况

服务 B 是上游服务，因为服务 A 依赖于它。服务 A 是上游服务，因为它减少了服务 B 的价值。

请留神，在这种状况下上游和上游的定义中的“流”不是通过服务 A 进入零碎的数据流，而是 数据流零碎始终到面向用户的服务。

服务离用户（或任何其余最终消费者）越近，它离上游越远。

论断

在应用“上游”和“上游”概念的任何上下文中，咱们能够利用两个简略的规定来找出哪个我的项目是另一个我的项目的上游或上游。

如果一个我的项目为另一个我的项目减少价值或以任何其余形式依赖它，它必定是上游。