关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
去年关闭。
Improve this question
几年前，媒体上充斥着各种关于
代码重用的想法如何成为提高生产力的简单方法
和代码质量。
从我定期查看的博客和网站来看，似乎
“代码重用”的想法已经过时了。也许'代码
重用的拥护者都加入了 SOA 人群吗？ :-)
有趣的是，当您在 Google 中搜索“代码重用”时，
第二个结果的标题是:
“内部代码重用被认为是危险的”!
对我来说代码重用的想法只是常识，毕竟看看
apache commons 项目的成功!
我想知道的是:
共享业务逻辑？您或您的公司如何重用代码？
讨论？
我完全知道有许多可用的开源库，并且任何使用过 .NET 或 Java 的人都以某种形式重用了代码。这是常识!
我更多地指的是组织内的代码重用，而不是通过共享库等跨社区重用。
我最初问;
从我坐的地方，我看到很少有公司试图在内部重用代码的例子？
如果您有一段可能在中型组织中共享的代码，您将如何通知公司的其他成员该 lib/api/etc 存在并且可能会从中受益？
最佳答案
您所指的文章标题具有误导性，实际上非常好读。代码重用是非常有益的，但凡事都有缺点。基本上，如果我没记错的话，这篇文章的要点是你将代码密封在一个黑盒子里而不是重新访问它，所以当原始开发人员离开时，你会失去知识。虽然我明白这一点，但我并不一定同意——至少不是“天塌下来”的观点。
我们实际上将代码重用分组为不仅仅是可重用的类，我们着眼于整个企业。更像是框架增强或解决横切关注点的东西被放入我们所有应用程序都使用的开发框架中(想想诸如验证前和验证后、日志记录等)。我们也有适用于多个应用程序的业务逻辑，因此这些东西被转移到一个可以在任何地方访问的 BAL 核心。
我认为重要的是如果它们不会被真正重用，就不要提倡重用。它们应该被很好地记录下来，这样新的开发人员也可以有一个资源来帮助他们加快速度。很有可能，如果不共享知识，代码最终将在其他地方重新发明，如果您在文档和知识共享方面不严谨，则会导致重复。
关于components - 我们是否已经放弃了代码重用的想法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/356275/