Kar*_*arl 12 soa code-reuse components
几年前,媒体上充斥着关于代码重用思想如何提高生产力和代码质量的各种文章.
从我定期检查的博客和网站看来,似乎"代码重用"的想法已经过时了.也许"代码重用"倡导者已经加入了SOA人群？:-)
有趣的是,当您在Google中搜索"代码重用"时,第二个结果标题为:
"内部代码重用被认为是危险的"!
对我来说代码重用的想法只是常识,毕竟看看apache commons项目的成功!
我想知道的是:
讨论？
我完全清楚有许多可用的开源库,任何使用过.NET或Java的人都会以某种形式重用代码.这是常识!
我更多地指的是组织内的代码重用,而不是通过共享库等社区中的代码重用.
我最初问过;
从我所在的位置,我看到很少有公司试图在内部重用代码？
如果你有一段可能在中等规模的组织中共享的代码,你会如何告知公司的其他成员这个lib/api/etc是否存在并且可能有益？
您所指的文章的标题具有误导性,实际上是一个非常好的阅读.代码重用非常有用,但一切都有缺点.基本上,如果我没记错的话,文章的要点是你将代码密封在一个黑盒子里而不是重新访问它,所以原来的开发人员会让你失去知识.虽然我明白了这一点,但我不一定同意这一点 - 至少不是"天空正在下降".
我们实际上将代码重用分组到不仅仅是可重用的类中,我们查看整个企业.更像是框架增强或地址交叉问题的事情被放入我们所有应用程序都使用的开发框架中(想想验证前后的内容,日志记录等).我们还有适用于多个应用程序的业务逻辑,因此这些东西会被移动到可在任何地方访问的BAL核心.
我认为重要的是,如果它们不能真正被重用,就不能促进重用.它们应该有详细记录,以便新开发人员可以拥有一个资源来帮助他们加快速度.如果不共享知识,代码最终会在其他地方重新发明,如果您在文档和知识共享方面不严谨,将导致重复.
我们重用代码 - 实际上,我们的开发人员专门编写可以在其他项目中重用的代码.这已经得到了很好的回报 - 我们能够快速启动新项目,并且我们反复强化我们的核心库.
但是,人们不能只编写代码并期望它被重用; 代码重用需要团队成员和其他用户之间的通信,以便人们知道可用的代码以及如何使用它.
代码重用有效工作需要以下内容: