您的组织如何处理通用组件？

Question

公共组件是由一个组创建和维护并由多个组使用的库或其他一些代码段。

我们遇到的一些问题是：

• 用户不会报告组件的问题。
• 用户构建组件的解决方法以满足他们的需求。
• 他们破坏了与主干版本的兼容性只是为了赶上最后期限。
• 用户最终会编写自己的（不太健壮的）解决方案，因为他们认为这样更好。

您的组织如何处理通用组件？

我的想法：

• 将组件视为开源项目，并要求团队提交补丁。
• 完全不允许对代码进行自定义修改。
• ...

Answer 1

您遇到的问题可能是人为因素问题，而不是技术问题。事实上，这可能主要是一个学习问题（加上典型的“未发明此处综合症”）。

在大公司工作过，我意识到对于一个新人来说很难理解所有的资源（即共享代码库）可供他使用，更不用说如何以及何时正确使用它们了。

当您雇用新员工时，他/她是否在您的通用组件库中接受了正式培训？

然后是人们因什么而得到奖励的问题。在审核时，管理者是否会奖励人们使用通用组件、改进它们并将改进提交回库？或者管理者只是关心他们自己的项目吗？

至于维护公共库的团队，他们会给花时间提出建议或提交改进的人提供什么形式或重新认识？他们是否被写在公司时事通讯中？获得现金奖励？把他们的照片放在布告栏上？

请记住，人们不太可能为一家他们没有得到认可或奖励的公司做一些事情。

Answer 2

我们正在尝试转向更多基于服务的系统，这样，如果我们为一个项目创建特定功能，就可以通过 Web 服务从另一个项目使用它。这样，代码就只有一个实例。

当然，这对于某些类型的组件效果更好（例如：我们最近创建了一个 PDF 创建服务）比其他服务（对于字符串操作实用程序来说可能有点过分）。

Answer 3

我在这里见过的唯一成功的组件是以编译版本（*.dll）重新分发的。用户直接向所属团队报告错误并请求功能，然后他们自己实现。有一个 API 可用于为最有可能更改的内容编写自己的插件，因此人们可以在许多情况下扩展功能。

总是需要权衡

• 说服人们使用你的组件
• 同时保持合理的质量水平

不确定在您的情况下最好做什么，但通常尝试自己实现核心逻辑，保持组件可配置/可扩展，这样人们就不需要一直更改核心并提供良好的支持。由于某种原因，一些开发人员总是倾向于重新发明轮子，无论它多么愚蠢，所以我不会太担心。

Answer 4

一个好方法是定期进行代码审查。在这些过程中，如果您发现重新发明了一个轮子，您可以利用这个机会教育开发人员使用通用组件，或者为什么他们觉得需要重新发明它，并将他们的推理与原始代码结合起来。这样每个人的要求都会被提出，组件也会为每个人而得到改进。

Answer 5

像对待第三方库一样对待它们。我什至不会让其他团队看到源代码 - 这样做可能会导致大量浪费时间的批评和中伤。

Answer 6

该组织有多大？我见过这些东西在一个小型组织（总共有几十名程序员）中处理得很好，其中已知一两个人拥有每个组件的所有权，并且对功能请求做出响应。

前往某人的办公室（或邮寄给他们），解释您的需要，并获得以下之一会更容易：

• 做你想做的事情的预期方式，
• 同意添加所需的功能（或指示下属这样做），
• 在公共组件中实现所需功能的权限，

不仅仅是开始编写解决方法、启动分支或编写等效的新组件。如果你的程序员很聪明，他们就会做他们认为最简单的事情。诀窍是确保这是正确的事情。

除了像链表这样非常简单的东西之外，没有进行大量的轮子改造。很少有针对特定产品的私有分叉，最常见的是通过删减内容来减少代码大小。但通常的方法是修改原始组件以获得更多构建选项。