代码重用的问题陈述

Question

我坚信，好的用户故事应该阐明要解决的问题和谁(通常说成是“作为一种角色，为了解决一个问题，我们想要一个建议的解决方案”)，这些故事最好能提供真正的、即时的和有形的价值。

我是一名测试自动化架构师，是我们公司自动化基础设施团队的一部分。在该团队成立之前，不同的团队通过相互复制基础结构代码来创建单独的自动化项目。显然，随着时间的推移，随着时间的推移，这些代码开始出现分歧，因为每个团队都开始进行自己的更改，就像重复的代码经常发生的情况一样。现在，作为一个基础设施团队，我们的主要目标之一是通过创建可重用组件(.Net NuGet包)来删除这种复制。

虽然我完全看到了重复代码的问题和创建可重用组件的好处，但我很难表达这个价值(更不用说，因为它是直接的和有形的)。关键不在于如何表达这句话，而在于如何将工作分解成小的、有价值的、可交付的部分，为团队提供即时价值，并对其进行排序。

显然，我看到我们的主要“客户”是编写和维护他们独特的自动化项目的团队，通过创建这些可重用的组件，我们减轻了他们的可维护性负担，并(以一种集中和更有效的方式)承担了这些负担，但这似乎是一个相当模糊和长期的问题，而不是提供有形和即时价值的东西。

我想，同样的问题可以推广到任何技术债务故事中，但是当技术债务在一个团队/项目中时，团队可以清楚地看到消除它的好处，而在我的例子中，在技术债务跨团队的情况下，每个团队都觉得他们可以更好地解决自己的问题，但他们忽略了整个公司正在发生的问题(浪费)的大局。

我想听听你对这种情况的看法:你会用不同的方式表达故事吗？我们应该关注不同的短期价值吗？我们是否把注意力集中在错误的事情上？或者其他你可能有的洞察力。

Answer 1

在回答这个问题之前，我们必须记住这里涉及的权衡。

当您集中这类事情时，您确实会减少所有其他团队的维护负担，但您也会在团队之间引入一种组织依赖性。

我的意思是，团队不必担心解决共享代码中的问题，但是，在您的团队免费并准备好实现它们之前，他们也无法拥有所需的新特性。这种类型的事情会导致团队的优先级与其他团队的优先级之间的冲突(或者即使是在其他团队之间，如果它们同时需要不同的特性)。

现在，要更直接地回答这个问题，只有当您试图推出影响所有自动化管道的整个组织范围的更改时，才有直接的价值。

否则，恐怕在这种情况下没有直接的价值。复制代码永远不会立即引起重大问题，它始终是一个随着时间推移而发展的问题。通常，出现的问题是由于重复的代码包含重复的bug，或者当影响所有自动化的更改必须实现时(总会有一些人落后)。

也许更好的解决方案是编写自动化代码，以便团队能够对其进行扩展。保持一个共同的核心来处理典型的用例，但是提供单个团队可以用来定制行为的钩子。

Answer 2

我们是否把注意力集中在错误的事情上？

很有可能:是的。首先，我要说我备份了上帝，猪的答案，因为额外的组织依赖性带来了很高的风险，可能不值得。几年前，我在一个巨大的项目中工作，这个项目严重低估了这个风险，这也是五年后这个项目被取消的原因之一。

然而，为了给您一个更积极的答案，让我们关注一种有时仍然有效的方法，至少当您的组织中有几个团队正在开发许多重复的东西时。

让我们从这里开始：

显然，我看到我们的主要“客户”是编写和维护他们独特的自动化项目的团队.

好的，这是你的用户。从他们的角度，问他们什么新的“标准组件”，他们实际上希望得到某个第三方(你的团队)，所以他们不需要自己开发。当然，您的团队只会提供标准组件，您也希望这些组件能够“销售”给其他的子团队，因此不同的团队不必开发它们两次。

因此，如果您要使用“用户故事”，从这个角度编写它们，比如--“作为一个来自计费部门的开发人员，为了让我们的程序与我们的新的集中日志系统通信，我想为此提供一个标准的API”。

通过创建这些可重用的组件，我们可以减轻它们的可维护性负担，并(以一种集中和更有效的方式)来承担它，但这似乎是一个相当模糊和长期的问题，而不是提供有形和即时价值的东西。

这可能是因为您只关注维护，并试图将重点放在已经存在的事情上。将这些东西捆绑在一个新组件中很少有价值--它只会给所有必须用新的集中式代码替换其工作代码的团队带来重构负担，而不会对他们的“客户”带来直接的好处，但会带来引入新bug的一定风险。

但是，也许有新的需求，需要真正的新组件，但到目前为止还没有开发出来。或者至少，在技术上可能需要对现有的东西进行更大的更新，每个现有的团队都必须以类似的方式重写或修改他们以前复制粘贴的代码。当您的团队能够在这里提供一个解决方案时，其他五个团队就可以省去五次做类似工作的麻烦了，我认为这是一个非常实际和直接的价值。

最后:不要低估编写组件所面临的挑战，这些组件可以很容易地被不同的团队使用，以及它们各自的细节。这是坚实的原则变得重要的地方，而不是标准的“应用程序”代码，过多的坚实有时会导致过度设计。对于创建可重用组件(特别是“黑匣子”组件)，提供正确的扩展点和参数化点至关重要，同时也提供了良好的文档。比起编写不可重用的组件，它的工作量很容易提高三到四倍(这就是为什么只有在至少有四到五个团队能够重用某个组件时，它才会有回报)。