What you have here may be a human factors problem rather than a technical one. In fact it may be primarly a learning issue (coupled with the typical not invented here syndrom).
Having worked in large companies, I realise that it is tough for a new person to understand all the resources (i.e. shared code libraries) available to him, much less how and when to properly use them.
When you have a new hire, is he/she given formal training in your common component library?
Then there is the problem of what people are rewarded for. At review time do managers reward people for using the common components, improving them and submitting improvments back to the library? Or do managers simply care about their own projects.
As for your group that maintains the common library, what form or reconginition do they give to people who take the time to suggest or submit improvements? Do they get written up in the company newsletter? Get a cash bonus? Get their photo on the bulliten board?
Remember, people are highly unlikely to do something for a company for which they receive no recognition or reward.
我们正在尝试转向更多基于服务的系统，这样，如果我们为一个项目创建特定功能，就可以通过 Web 服务从另一个项目使用它。 这样，代码就只有一个实例。
当然，这对于某些类型的组件（例如：我们最近创建了一个 PDF 创建服务）比其他组件效果更好（对于字符串操作实用程序来说可能有点过分）。
We're trying to move toward more service-based systems, so that if we create a particular functionality for one project, it can be used from another project through a web service. This way there's only one instance of the code.
Naturally this works better for some types of components (an example: we recently created a PDF creation service) than others (probably overkill for a string manipulation utility).
The only successful component I have seen around here is redistributed in a compiled version (*.dll). Users report bugs and request features directly with the owning team, and they implement them themselves. There is an api for writing your own plugins for stuff that is the most likely to change, so people can extend the functionality in many cases.
There is always the trade-off to
convince people to use your component
keep a reasonable level of quality at the same time
Not sure what is the best thing to do in your case, but in general try to implement the core logic yourself, keep the component configurable/extendible so people don't need to change the core all the time and offer good support. For some reason some developers always tend to reinvent the wheel however stupid it is, so I wouldn't worry about it too much.
A good way is to institute periodic code reviews. During these if you find a wheel re-invented you can use the opportunity to either educate the developers to use to common component or why they felt the need to re-invent it and ally their reasoning to the original code. This way everyone's requirements are made and the components are improved for everyone.
Treat them the same way you would third-party libraries. I wouldn't even let the other teams see the source - doing so can lead to a lot of time-wasting criticism and back-biting.
How big is the organisation? I've seen this stuff handled very well in a small organisation (a few dozen programmers total) where one or two individuals are known to have ownership of each component, and are responsive to feature requests.
It's easier to march off to someone's office (or mail them), explain what you need, and get one of:
the expected way to do what you want,
agreement to add the required feature (or direct a minion to do so),
permission to implement the required feature in the common component,
Than it is just to launch into writing workarounds, starting a fork, or writing an equivalent new component. If your programmers are smart, they'll do what they think is easiest. The trick is to ensure that this is the right thing.
Aside from really simple stuff like linked lists, there wasn't a whole lot of wheel-reinvention going on. There were, very rarely, private forks for particular products, most commonly to reduce code size by chopping things out. But the usual way to do that was to modify the original component to have more build options.
发布评论
评论（6）
您遇到的问题可能是人为因素问题，而不是技术问题。 事实上，这可能主要是一个学习问题（加上典型的“未发明此处综合症”）。
在大公司工作过，我意识到对于一个新人来说很难理解他可用的所有资源（即共享代码库），更不用说如何以及何时正确使用它们了。
当您雇用新员工时，他/她是否在您的通用组件库中接受了正式培训？
然后是人们因什么而得到奖励的问题。 在审核时，管理者是否会奖励人们使用通用组件、改进它们并将改进提交回库？ 或者管理者只是关心他们自己的项目吗？
至于维护公共库的团队，他们会给花时间建议或提交改进的人提供什么形式或重新认识？ 它们是否被写在公司时事通讯中？ 获得现金奖励？ 把他们的照片放在布告栏上？
请记住，人们不太可能为一家他们没有得到认可或奖励的公司做一些事情。
What you have here may be a human factors problem rather than a technical one. In fact it may be primarly a learning issue (coupled with the typical not invented here syndrom).
Having worked in large companies, I realise that it is tough for a new person to understand all the resources (i.e. shared code libraries) available to him, much less how and when to properly use them.
When you have a new hire, is he/she given formal training in your common component library?
Then there is the problem of what people are rewarded for. At review time do managers reward people for using the common components, improving them and submitting improvments back to the library? Or do managers simply care about their own projects.
As for your group that maintains the common library, what form or reconginition do they give to people who take the time to suggest or submit improvements? Do they get written up in the company newsletter? Get a cash bonus? Get their photo on the bulliten board?
Remember, people are highly unlikely to do something for a company for which they receive no recognition or reward.
我们正在尝试转向更多基于服务的系统，这样，如果我们为一个项目创建特定功能，就可以通过 Web 服务从另一个项目使用它。 这样，代码就只有一个实例。
当然，这对于某些类型的组件（例如：我们最近创建了一个 PDF 创建服务）比其他组件效果更好（对于字符串操作实用程序来说可能有点过分）。
We're trying to move toward more service-based systems, so that if we create a particular functionality for one project, it can be used from another project through a web service. This way there's only one instance of the code.
Naturally this works better for some types of components (an example: we recently created a PDF creation service) than others (probably overkill for a string manipulation utility).
我在这里见过的唯一成功的组件是以编译版本（*.dll）重新分发的。 用户直接向所属团队报告错误并请求功能，然后他们自己实现。 有一个 API 可用于为最有可能更改的内容编写自己的插件，因此人们可以在许多情况下扩展功能。
需要权衡。
不确定在你的情况下最好的做法是什么，但总的来说，尝试自己实现核心逻辑，保持组件可配置/可扩展，因此人们不需要一直更改核心并提供良好的支持。 由于某种原因，一些开发人员总是倾向于重新发明轮子，无论它多么愚蠢，所以我不会太担心。
The only successful component I have seen around here is redistributed in a compiled version (*.dll). Users report bugs and request features directly with the owning team, and they implement them themselves. There is an api for writing your own plugins for stuff that is the most likely to change, so people can extend the functionality in many cases.
There is always the trade-off to
Not sure what is the best thing to do in your case, but in general try to implement the core logic yourself, keep the component configurable/extendible so people don't need to change the core all the time and offer good support. For some reason some developers always tend to reinvent the wheel however stupid it is, so I wouldn't worry about it too much.
一个好方法是定期进行代码审查。 在这些过程中，如果您发现重新发明了一个轮子，您可以利用这个机会教育开发人员使用通用组件，或者为什么他们觉得需要重新发明它，并将他们的推理与原始代码结合起来。 这样每个人的要求都会被提出，组件也会为每个人而得到改进。
A good way is to institute periodic code reviews. During these if you find a wheel re-invented you can use the opportunity to either educate the developers to use to common component or why they felt the need to re-invent it and ally their reasoning to the original code. This way everyone's requirements are made and the components are improved for everyone.
像对待第三方库一样对待它们。 我什至不会让其他团队看到源代码 - 这样做可能会导致大量浪费时间的批评和中伤。
Treat them the same way you would third-party libraries. I wouldn't even let the other teams see the source - doing so can lead to a lot of time-wasting criticism and back-biting.
该组织有多大？ 我见过这些东西在一个小型组织（总共有几十名程序员）中处理得很好，其中已知一两个人拥有每个组件的所有权，并且对功能请求做出响应。
前往某人的办公室（或邮寄给他们），解释您的需求，并获得以下其中之一会更容易：
而不只是开始编写变通办法、启动分支或编写等效的新组件。 如果你的程序员很聪明，他们就会做他们认为最简单的事情。 诀窍是确保这是正确的事情。
除了像链表这样非常简单的东西之外，没有进行大量的轮子改造。 很少有针对特定产品的私有分叉，最常见的是通过删减内容来减少代码大小。 但通常的方法是修改原始组件以获得更多构建选项。
How big is the organisation? I've seen this stuff handled very well in a small organisation (a few dozen programmers total) where one or two individuals are known to have ownership of each component, and are responsive to feature requests.
It's easier to march off to someone's office (or mail them), explain what you need, and get one of:
Than it is just to launch into writing workarounds, starting a fork, or writing an equivalent new component. If your programmers are smart, they'll do what they think is easiest. The trick is to ensure that this is the right thing.
Aside from really simple stuff like linked lists, there wasn't a whole lot of wheel-reinvention going on. There were, very rarely, private forks for particular products, most commonly to reduce code size by chopping things out. But the usual way to do that was to modify the original component to have more build options.