一个通用组件是一个库或一些其他代码，由一个组创建和维护，并被许多组使用。
我们遇到的一些问题是：
您的组织如何处理常见组件？
我的想法：
答案 0 :(得分：2)
你在这里所拥有的可能是人为因素问题，而不是技术问题。事实上，它可能主要是一个学习问题（加上典型的未发明的这种综合症）。
在大公司工作之后，我意识到新人很难理解他可用的所有资源（即共享代码库），更不用说正确使用它们的方式和时间。
当您有新员工时，他/她是否在您的公共组件库中接受过正式培训？
然后是人们获得奖励的问题。在审核时，管理人员会奖励人们使用通用组件，改进它们并将改进提交回图书馆吗？或者管理者只关心他们自己的项目。
对于维护公共图书馆的小组，他们给那些花时间建议或提交改进的人提供了什么形式或重新定义？他们是否写在公司简报中？获得现金奖励？在bulliten板上拍照？
请记住，人们极不可能为没有得到认可或奖励的公司做点什么。
答案 1 :(得分：2)
我们正在努力转向更多基于服务的系统，因此，如果我们为一个项目创建特定功能，则可以通过Web服务从另一个项目中使用它。这种方式只有一个代码实例。
当然，这对某些类型的组件（例如：我们最近创建了一个PDF创建服务）比其他组件更好（对于字符串操作实用程序可能有点过分）。
答案 2 :(得分：1)
我在这里看到的唯一成功的组件是在编译版本（* .dll）中重新分发的。用户直接向拥有团队报告错误和请求功能，他们自己实现。有一个api用于为最有可能改变的东西编写自己的插件，因此人们可以在很多情况下扩展功能。
总是需要权衡
不确定在您的情况下做什么是最好的事情，但一般情况下尝试自己实现核心逻辑，保持组件可配置/可扩展，这样人们就不需要一直改变核心并提供良好的支持。出于某种原因，一些开发人员总是倾向于重新发明轮子，但它是愚蠢的，所以我不会太担心它。
答案 3 :(得分：1)
一种好方法是定期进行代码审查。在这些期间，如果您发现轮子重新发明，您可以利用这个机会教育开发人员使用通用组件，或者为什么他们觉得需要重新发明它并与原始代码结合起来。这样就可以满足每个人的需求，并且每个人都可以改进组件。
答案 4 :(得分：1)
以与第三方库相同的方式对待它们。我甚至不会让其他团队看到消息来源 - 这样做会导致大量浪费时间的批评和反咬。
答案 5 :(得分：1)
该组织有多大？我已经看到这个东西在一个小型组织（总共几十个程序员）处理得非常好，其中一个或两个人知道每个组件的所有权，并且对功能请求做出响应。
更容易前往某人的办公室（或邮寄他们），解释您的需求，并获得以下其中一个：
只是开始编写解决方法，启动fork或编写等效的新组件。如果您的程序员很聪明，他们会做他们认为最简单的事情。诀窍是确保这是正确的。
除了链接列表之类的非常简单的东西之外，还没有进行大量的轮盘改造。对于特定产品，很少有私人叉子，最常见的是通过砍掉东西来减少代码大小。但通常的做法是修改原始组件以获得更多构建选项。