是“可重用业务组件”一个神话？
阅读讨论后如何使用 Scrum 创建通用/可重用代码？ 我思考了我在可重用组件方面的经验。
我创建了几个“技术组件”，并在其他项目中成功地重用了它们。
我还创建了几个最初是为了可重用性而设计的“业务组件”。但它们从未作为一个库重复使用，因为针对不同客户的解决方案是不同的。 当然，想法和代码片段是从业务库中重用的，但不是库本身。
像 SAP/R3 这样的大型应用程序被许多客户使用。在我看来，这是一个整体，而不是一个独立的组件。
所以我问自己：“可重用业务组件”是一个神话吗？如果是的话，为什么创建一个如此困难？
After Reading the discussion How to create generic/reusable code with Scrum?
I thought about my experiences with reusable components.
I created several "technical components" that where succsesfully reused in other projects.
I also created several "business components" that were originally designed for reusability. But they where never reused as one library since solutions for different customers were to different.
Of course ideas and codefragments were reused from the businesslibrary but not the library itself.
A big application like SAP/R3 is used by many customers. In my view this is a monolith and not an independant component.
So I asked myself: Is a "Reusable Busines Component" a Myth? If yes why is it so difficult to create one?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说这不是一个神话——但在我的经验中确实很少见。
它还取决于您对组件的称呼以及您所关注的粒度级别。我工作的每个用户和业务部门都使用 Microsoft Office 和 Exchange - 因此它们具有高度可重用性。
任何人只要认为自己能从中受益，就会重复使用某样东西。最大的技巧是让他们看到这一点。你还面临着人性的挑战——不相信他们不理解的事情，等等。
我当然见过一些例子，其中真正可重用的业务组件被认为是需要/理想的：但实际上构建它是一个大问题：谁将拥有它？谁来付钱？
作为“政府整体”行动的一部分，我们拥有一个技术组件，使我们能够与集中提供的身份和访问管理服务集成。这允许公众拥有一个帐户（用户名和密码等），他们可以使用该帐户登录任何政府提供的在线服务（他们使用中央 IAM 服务）。
因为我们的系统（与集中提供的位相结合）提供了与业务相关的功能，我认为这是您神话般的可重用组件的一个示例。该解决方案允许我们将组织内用户的管理委托给该组织内的管理员，从而跨多个业务部门提供业务价值（更少的管理开销）。
I's say it's not a myth - but certainly rare in my experience.
It also depends what you call a component, and what level of grainularity you're looking at. Every user and business unit where I work uses Microsoft Office and Exchange - so they are highly reusable.
Anyone will re-use something if they think they'll gain from it. the big trick is getting them to see that. You're also up against human nature - not trusting things they don't understand, and so on.
I've certainly seen examples where a truly re-usable business component is identified as being needed / desirable: but then actually getting it built is a big problem: Who's going to own it? Who's going to pay for it?
As part of an "all of government" drive, we have a technical component that allows us to integrate with a centrally provided Identity and Access Management service. This allows members of the public to have one account (username and password, etc) that they can use to log into any government provided online service (where they use the central IAM service).
Because our system (combined with the centrally provided bit) offer business related functionality I think this is an example of your mythical re-useable component. The solution allows us to delegate management of users within an organisation to admins within that organisation - thus providing business value (less management overhead) across multiple business units.
如果你将三种知识分类为：
软件工程可以解决第一个问题轻松地分为两类：现在解决容易理解的问题，并为明天解决不太理解的问题留出空间。但是，第三类是在 *ss 中会咬住你的东西。
http://opinionator.blogs.nytimes.com/ 2010/06/20/the-anosognosics-dilemma-1/
http://en.wikipedia .org/wiki/Unknown_unknown
If you categorize three kinds of knowledge as:
Software engineering can solve the first two categories easily - Solving well understood problems now, and leaving room for solving less understood problems tomorrow. But, the third category is the stuff that will bite in you in the *ss.
http://opinionator.blogs.nytimes.com/2010/06/20/the-anosognosics-dilemma-1/
http://en.wikipedia.org/wiki/Unknown_unknown