通用组件是由一个组创建和维护并由多个组使用的库或其他一些代码。
我们遇到的一些问题是：
- 用户不会报告组件的问题。
- 用户构建组件的变通方法以满足他们的需求。
- 他们打破与主干版本的兼容性只是为了满足他们的最后期限。
- 用户最终会编写自己的（不太健壮的）解决方案，因为他们认为这样更好。
您的组织如何处理通用组件？
我的想法：
- 将组件视为开源项目，并要求团队提交补丁。
- 完全不允许对代码进行自定义修改。
- ...
问问题
326 次
6 回答
2
您在这里遇到的可能是人为因素问题，而不是技术问题。事实上，这可能主要是一个学习问题（再加上典型的非此处发明综合症）。
在大公司工作过，我意识到一个新人很难理解所有可用的资源（即共享代码库），更不用说如何以及何时正确使用它们了。
当您有新员工时，他/她是否在您的通用组件库中接受过正式培训？
然后是人们获得奖励的问题。在审查时，管理者是否奖励人们使用通用组件、改进它们并将改进提交回图书馆？或者经理们只是关心他们自己的项目。
至于您维护公共图书馆的小组，他们会给花时间建议或提交改进的人以什么形式或重新认识？他们会写在公司通讯中吗？获得现金红利？让他们的照片出现在公告板上？
请记住，人们极不可能为他们没有得到认可或奖励的公司做某事。
于 2009-05-06T12:59:31.477 回答
2
我们正在尝试转向更多基于服务的系统，以便如果我们为一个项目创建特定功能，则可以通过 Web 服务从另一个项目中使用它。这样，只有一个代码实例。
自然，这对于某些类型的组件（例如：我们最近创建了一个 PDF 创建服务）比其他组件（对于字符串操作实用程序来说可能是矫枉过正）更有效。
于 2009-05-06T12:59:40.070 回答
1
我在这里看到的唯一成功的组件是以编译版本 (*.dll) 重新分发的。用户直接向拥有团队报告错误和请求功能，然后他们自己实现它们。有一个 api 用于为最有可能更改的内容编写自己的插件，因此人们可以在许多情况下扩展功能。
总是需要权衡取舍
- 说服人们使用你的组件
- 同时保持合理的质量水平
不确定在您的情况下最好的做法是什么，但通常尝试自己实现核心逻辑，保持组件可配置/可扩展，这样人们就不需要一直更改核心并提供良好的支持。出于某种原因，一些开发人员总是倾向于重新发明轮子，无论它多么愚蠢，所以我不会太担心它。
于 2009-05-06T12:52:55.390 回答
1
一个好方法是定期进行代码审查。在这些过程中，如果您发现重新发明了一个轮子，您可以利用这个机会教育开发人员使用通用组件，或者为什么他们觉得需要重新发明它，并将他们的推理与原始代码结合起来。这样就可以满足每个人的要求，并为每个人改进组件。
于 2009-05-06T12:54:28.650 回答
1
像对待第三方库一样对待它们。我什至不会让其他团队看到源头——这样做会导致大量浪费时间的批评和回击。
于 2009-05-06T12:58:51.243 回答
1
组织有多大？我在一个小型组织（总共几十个程序员）中看到这些东西处理得非常好，其中一两个人已知拥有每个组件的所有权，并且对功能请求做出响应。
前往某人的办公室（或邮寄）更容易，解释您的需求，并获得以下之一：
- 做你想做的事情的预期方式，
- 同意添加所需的功能（或指示奴才这样做），
- 在公共组件中实现所需功能的权限，
不仅仅是开始编写变通方法、启动分叉或编写等效的新组件。如果你的程序员很聪明，他们会做他们认为最简单的事情。诀窍是确保这是正确的事情。
除了像链表这样非常简单的东西之外，并没有进行大量的轮子改造。很少有针对特定产品的私有分叉，最常见的是通过砍掉一些东西来减少代码大小。但是通常的方法是修改原始组件以具有更多构建选项。
于 2009-05-06T13:10:06.910 回答