我们是否放弃了代码重用的想法?

时间:2008-12-10 14:37:26

标签: components soa code-reuse

几年前,媒体上充斥着各种各样的文章 代码重用的想法如何是提高生产力的简单方法 和代码质量。

从我定期检查的博客和网站看起来好像 “代码重用”的想法已经过时了。也许是'代码 重用'倡导者所有人都加入了SOA人群? : - )

有趣的是,当您在Google中搜索“代码重用”时 第二个结果标题为:

“内部代码重用被视为危险”!

对我来说,代码重用的想法只是常识,毕竟看看 apache commons项目的成功!

我想知道的是:

  • 您或您的公司是否尝试重复使用代码?
  • 如果是,那么如何以及在什么级别,即低级api,组件或 共享业务逻辑?您或您的公司如何重用代码?
  • 有用吗?

讨论


我完全清楚有许多可用的开源库,任何使用过.NET或Java的人都会以某种形式重用代码。这是常识!

我更多地指代组织内的代码重用,而不是通过共享库等社区。

我最初问过;

  • 您或您的公司是否尝试重复使用代码?
  • 如果是,那么如何以及在什么级别,即低级api,组件或共享业务逻辑?您或您的公司如何重用代码?

从我所在的位置,我看到很少有公司试图在内部重用代码?

如果您有一段可能在中型组织中共享的代码,您会如何告知公司的其他成员这个lib / api / etc是否存在并且可能有益?

16 个答案:

答案 0 :(得分:9)

您所指的文章标题具有误导性,实际上是一本非常好的阅读材料。代码重用非常有用,但一切都有缺点。基本上,如果我没记错的话,文章的要点是你将代码密封在一个黑盒子里而不是重新访问它,所以原来的开发人员会让你失去知识。虽然我明白了这一点,但我不一定同意这一点 - 至少不是“天空正在下降”。

我们实际上将代码重用分组到不仅仅是可重用的类中,我们查看整个企业。更像是框架增强或地址交叉问题的事情被放入我们所有应用程序都使用的开发框架中(想想验证前后的内容,日志记录等)。我们还有适用于多个应用程序的业务逻辑,因此这些东西会被移动到可在任何地方访问的BAL核心。

我认为重要的是不推广重用的东西,如果它们不会真正被重用的话。它们应该有详细记录,以便新开发人员可以拥有一个资源来帮助他们加快速度。如果不共享知识,代码最终可能会在其他地方重新发明,如果您在文档和知识共享方面不严谨,将会导致重复。

答案 1 :(得分:5)

我们重用代码 - 实际上,我们的开发人员专门编写可以在其他项目中重用的代码。这已经得到了很好的回报 - 我们能够快速启动新项目,并且我们反复强化我们的核心库。

但是人们不能只编写代码并期望它被重用; 代码重用需要团队成员之间的沟通和其他用户,以便人们知道可用的代码以及如何使用它。

要使代码重用有效工作,需要满足以下条件:

  • 代码或库本身
  • 跨多个项目或工作的代码需求
  • 代码功能/功能的通信
  • 有关如何使用代码的说明
  • 承诺随着时间的推移维护和改进代码

答案 2 :(得分:3)

代码重用至关重要。我发现它也迫使我尽可能地概括,也使代码更适应不同的情况。理想情况下,您编写的几乎每个较低级别的库都应该能够适应不同应用程序的一组新要求。

答案 3 :(得分:2)

我认为代码重用大部分都是通过开源项目完成的。任何可以重复使用或扩展的东西都是通过库完成的。 Java拥有大量可用于执行大量操作的开源库。与C ++相比,使用MFC或Win32 API从头开始实现所有内容的早期版本。

答案 4 :(得分:1)

我认为缺乏“媒体关注”是因为每个人都在这样做,所以不再值得写。我没有听到像以前那样提高对面向对象编程和单元测试的认识的人。每个人都已经意识到这些概念(无论是否使用它们)。

答案 5 :(得分:1)

我的个人观点,基于我公司的做法:

  
      
  • 您或您的公司是否尝试重复使用代码?
  •   

显然,如果我们有另一段代码已经满足我们的需求,我们将重用它。我们不会尽力在圆孔中使用方形钉。

  
      
  • 如果是,那么如何以及在什么级别,即低级api,组件或共享业务逻辑?您或您的公司如何重用代码?
  •   

各个层面。它写入我们的编码标准,开发人员应该始终假设他们的代码将被重用 - 即使实际上这是非常不可能的。 见下文

如果您的OO模型很好,您的API可能反映了您的业务领域,因此可重用的类可能等同于可重用的业务逻辑而无需额外的努力。

对于实际重用,一个关键点是知道哪些代码已经可用。我们通过在中心位置记录所有内容来解决这个问题。我们只需要一点点纪律,以确保文档是最新的,并以有意义的方式进行搜索。

  
      
  • 有用吗?
  •   

是的,但不是因为潜在或实际的重复使用!实际上,除了一些核心库和UI组件之外,没有大量的重用。

在我个人看来,真正的价值在于使代码可重用。除此之外,除了希望更干净的API之外,代码将(a)充分记录,以供其他开发人员使用而无需拖拽源代码,以及(b)它也将是可替换。这些要点对正在进行的软件维护有很大好处。

答案 6 :(得分:1)

媒体对某个问题的关注程度与其重要性无关,无论我们是在讨论软件开发还是政治问题!重要的是避免通过重新发明(或重新维护!)轮子来浪费开发工作,但现在众所周知,编辑可能不会对另一篇关于该主题的文章感到兴奋。

不要将当前文章和博客文章的数量视为重要性(或紧迫性)的衡量标准,而是查看已经成为经典或进入行话的概念和嗡嗡声短语(另一种形式的重用!)例如,谷歌使用DRY首字母缩略词来讨论可以在软件和开发过程中消除的多种冗余形式。

对于重用成本与实现收益的成本,还有成熟判断的作用。一些作者提倡等待重用,直到第二次或第三次使用实际出现,而不是在第一次编写时花费精力来概括代码。

答案 7 :(得分:1)

我们重复使用代码。

在小规模上,我们尽量避免代码重复。我们有一个包含大量常用代码的完整库。

通常,代码是为一个应用程序开发的。如果它足够通用,它将被提升到库中。这很有效。

答案 8 :(得分:1)

代码重用的想法不再是一个新颖的想法......因此显然缺乏兴趣。但它仍然是一个好主意。整个.NET框架和Java API都是代码重用的好例子。

我们已经习惯于为我们的项目开发OO代码库并在其他项目中重用它们。它是一个想法的自然生命周期的一部分。它有一段时间激烈争论,然后每个人都接受,没有理由进一步讨论。

答案 9 :(得分:1)

当然我们会重复使用代码。

所有语言都有无穷无尽的软件包,库和共享对象,整个开发人员社区都在支持和更新它们。

答案 10 :(得分:0)

代码重用是一个非常重要的问题 - 代码不会被重用,项目需要更长时间,新团队成员难以进入。
但是,编写可重用代码需要更长时间
就个人而言,我尝试以可重用的方式编写所有代码,这需要更长的时间,但这导致我的大部分代码已经成为组织中的官方基础架构,并且基于这些基础架构的新项目所花费的时间要少得多。登记/>
重用代码的危险在于,如果重用的代码不是作为基础结构编写的 - 以尽可能少的假设和尽可能多的文档和单元测试的一般和封装方式,代码最终会做出意想不到的事情。
此外,如果找到并修复了错误或添加了功能,这些更改很少返回到源代码,导致重用代码的不同版本,没有人知道或理解。

解决方案是:
1.设计和编写代码时不仅要考虑一个项目,还要考虑未来的需求,并尝试使设计足够灵活,以最少的代码更改来覆盖它们。
2.将代码封装在原样使用的库中,而不是在使用项目中修改 3.允许用户使用 解决方案查看和修改库的代码(不在使用项目的解决方案中)。
4.设计基于现有基础设施的未来项目,根据需要对基础设施进行更改 5.负责维护所有项目的基础设施,从而保持基础设施的资金。

答案 11 :(得分:0)

虽然我认为代码重用很有价值,但我可以看到这种情绪根深蒂固的地方。我参与了许多项目,在这些项目中,我们需要特别小心地创建可重用的代码,然后再重复使用。当然,重用比重复代码要好得多,但我已经看到了很多非常易于使用的对象模型,目的是在多个项目中使用整个企业中的对象(这种方式可以在不同的SOA中使用相同的服务)应用程序)但从未见过实际使用过多次的对象。也许我只是没有充分利用重用原则的组织。

答案 12 :(得分:0)

也许更好的问题是这些天我们什么时候不重用代码?我们要么处于建设状态,要么使用别人观察“最佳实践”或预先发现“设计模式”,要么仅仅依靠遗留代码,库或复制。

似乎代码A被重复用于制作代码B的程度通常取决于代码A中对代码B的想法被抽象为设计模式/成语/书籍/稍纵即逝的想法/实际代码/库。困难的部分是将所有这些好主意应用到您的实际代码中。

非技术类型对重用事物过于热心。他们不明白为什么一切都不能复制粘贴。他们不明白为什么greemelfarm需要一个特殊的适配器来将旧系统所用的相同信息传递给新系统,不幸的是,由于其他原因,我们无法改变。

我认为技术人员从第1天就开始重复使用,就像音乐家从第1天开始重用一样。它是一种持续的有机进化和合成,将继续存在。

答案 13 :(得分:0)

我所研究的两个软件项目都是长期开发的。一个是大约10年,另一个已经存在超过30年,一路上重写了几个版本的Fortran。两者都广泛地重用代码,但两者都很少依赖外部工具或代码库。 DRY是新项目的一个重要口号,它采用C ++,在实践中更容易实现。

答案 14 :(得分:0)

  

您或您的公司是否尝试重复使用代码?如果是这样的话怎么样   级别,即低级API,组件或共享业务逻辑?怎么做   您或您的公司重用代码?

我曾经在代码库中使用超级代码重用,但由于重用的代码不稳定,因此难以维护。它倾向于设计更改和弃用的方式级联到使用它的一切。在此之前,我在一个没有代码重用的代码库中工作,老年人实际上鼓励复制和粘贴作为一种方法来重用甚至特定于应用程序的代码,所以我看到了两个极端,我不得不说一个不是当走向极端时,它必然比另一个好得多。

我曾经是一名优秀的自下而上的程序员。你让我建立一些特定的东西,最后我建立了通用的工具。然后使用这些工具,我构建了更复杂的通用工具,然后开始构建DIP抽象来表达低级工具的设计要求,然后我构建更复杂的工具并重复,并且在某些时候我开始编写实际执行的代码你要我做什么。虽然听起来适得其反,但我的速度非常快,可能会以令人惊讶的方式运送复杂的产品。

问题是几个月,几年的维护!在我构建了这些通用库的层和层并重新使用它们之后,每个人都希望提供比你要求我做的更大的目的。每一层都想解决世界的饥饿需求。所以每个人都非常雄心勃勃:数学图书馆想要惊人并解决世界的饥饿需求。然后建立在数学库之上的东西就像一个几何图书馆,它想要惊人并解决世界的饥饿需求。当你尝试发布产品时,你知道一些错误,但是你的思想正在考虑你的超级通用几何库在你应该做动画时如何用于渲染和建模因为您正在处理的动画代码需要一些新的几何函数。

平衡每个人的需求

我在设计这些超级通用库时发现,我必须痴迷于每个团队成员的需求,我必须了解光线跟踪是如何工作的,流体动力学如何工作,网格引擎如何工作,反向运动学如何工作,角色动画如何工作等等。我必须学习如何做好每个人在团队中的工作,因为我在设计这些超级广义图书馆时平衡了他们所有的特殊需求。在走钢丝平衡设计行为的背后,所有代码重用都是妥协的(试图让Bob更好地处理使用其中一个库的光线追踪,但不会伤害John太多正在使用它的物理学人员但是没有使图书馆的设计太复杂,使他们都很高兴。)

我试图用策略类来参数化边界框,以便它们可以像一个人想要的那样存储为中心和半尺寸,或者像其他人想要的那样存储最小/最大范围,并且实现是在试图疯狂地跟上每个人的需求时,我会非常快乐。

委员会设计

由于每一层都试图满足如此广泛的需求(比我们实际需要的要宽得多),他们发现需要改变设计的理由很多,有时候是委员会要求的设计(通常有点粗略)。然后,这些设计更改将向上级联并影响使用它的所有更高级别的代码,并且此类代码的维护开始成为真正的PITA。

我认为你可以在一个志同道合的团队中分享更多代码。我们根本没有志同道合。这些都不是真正的名字,但我在这里有Bill,他是一个高级GUI程序员和脚本编写者,他创建了很好的用户端设计但是有很多黑客的可疑代码,但是对于那种类型的代码来说它往往是好的。我让鲍勃来到这里,他是一个老计时器,自打卡时代以来一直在编程,他喜欢用里程碑编写10,000行函数,但仍然没有得到面向对象编程的观点。我在这里得到了乔,他就像一个数学向导但编写了其他人无法理解的代码,总是提出数学上对齐的建议,但从计算的角度来看并不一定非常有效。然后我让Mike在这里,他们希望我们将软件移植到iPhone上,认为我们都应该遵循Apple的惯例和工程标准。

试图满足每个人的需求,同时提出一个体面的设计,可能是回想起来,不可能。在每个试图分享彼此代码的人中,我认为我们变得适得其反。每个人都有能力在一个地区,但试图提出每个人都满意的设计和标准,只会导致各种不稳定,并减慢每个人的速度。

<强>权衡

所以这些天我发现平衡是为了避免代码重用最低级别的东西。我使用了自上而下的中级方法,也许(某些东西远离你要求我做的事情),并在那里建立一些独立的库,我仍然可以做一些简短的库时间量,但图书馆并不打算生产试图解决世界饥饿需求的小型库。通常这些库的目的比较低级的库要窄一些(例如:物理库而不是广义几何交叉库)。

YMMV,但如果我多年来以最困难的方式学到了什么,可能会有平衡行为和我们可能想要故意避免的一点代码在某个粒度级别的团队设置中重用,放弃了最低级别代码的一般性,有利于解耦,具有可塑性代码,我们可以更好地塑造以满足更具体而非一般化的需求,等等 - 甚至可能只是放弃每个人都有更多自由以自己的方式做事。但当然所有这一切都是为了仍然生成一个非常可重用的通用库,但不同之处在于库可能不会分解成最年轻的通用库,因为我发现超过某个阈值并试图制作太多从长远来看,从长远来看,广义的图书馆开始真正成为一种极其适得其反的努力 - 不是在短期内,而是从长远来看和广泛的计划。

  

如果你有一段代码可能会被分享   中等规模的组织你将如何通知其他人   这个lib / api / etc存在且可能属于的公司成员   受益?

这些天我实际上更不情愿,并且如果同事做了一些多余的工作,发现它更难以原谅,因为我想确保代码做一些非常有用且非平凡的事情,并且在我尝试之前也经过了充分的测试和设计与人分享并积累一大堆依赖。如果我与团队的其他成员分享,那么设计应该有很少的理由要求从那时起进行任何更改。

否则它可能比实际节省更多的悲伤。

我曾经如此不容忍冗余(在代码或努力中),因为它似乎转化为在内存使用方面非常错误和爆炸性的产品。但是我把冗余放大了太多关键问题,真正的问题是质量差,编写代码匆忙,缺乏可靠的测试。经过充分测试,可靠,高效的代码不会受到这个问题的影响,即使有些人在这里和那里复制一些数学函数,也不会有这么大的程度。

在我们使用非常可靠的第三方库时,要注意并记住我当时没有注意到的一些常识性事项是我们不介意的。您可能会使用第三方库或两个与您的团队正在进行的工作有多余工作的库。但是我们在这些情况下并不介意,因为第三方图书馆很棒且经过充分测试。我建议将相同的思维方式应用于您自己的内部代码。我们的目标应该是创造一些令人敬畏的,经过充分测试的东西,而不是像我在很久以前错误地做的那样在这里和那里做一点点冗余。

所以这些天我把我的不宽容转移到缺乏测试上。我发现,对其他人缺乏单元和集成测试感到不安,而不是对多余的工作感到不安。 :-D

答案 15 :(得分:-1)

Maven解决了代码重用问题。我完全认真。

寻找你感兴趣的贴纸↓↓↓
豫ICP备18024241号-1