为什么“复制粘贴”代码是危险的?[关闭]

如果你在复制粘贴代码中发现了一个bug,你需要在你做的每一个地方修复它,并希望你能记住它们(这也适用于更改的需求)。

如果您将逻辑放在一个地方,则在需要时更容易更改(因此,如果您决定应用程序需要更新,则只在一个地方进行更改)。

你老板有没有读过 DRY principle (不要重复)。

你所描述的听起来是 图书馆 ,共享代码并只将其保存在一个地方。

如果我想复制粘贴代码 重构 它很快-确保我以后提取公共代码,以便我可以重用尽可能多的逻辑。不久之后,我的意思是几分钟几小时之后,而不是几天几周。

你会好得多 分享 通过建立一个库而不是 复印 使用复制和粘贴的代码。

与重新编写相比,您仍然可以获得速度优势(查找dry),但只有一个地方可以维护代码。

显而易见的原因是,你为未来承担了一笔“债务”:你需要在代码中做的任何更改(不仅仅是错误修复,任何更改)现在都要花费两倍的代价,因为你必须更新两个地方——而且风险更大,因为你最终会忘记其中的一个。换言之,现在让它工作得更快,将来会让你的工作更慢, 可以 有良好的商业头脑,但通常不是。

但更重要的原因是,“这与那是一样的”这一假设往往是错误的。每当代码依赖于未声明的假设是正确的时,将其复制到另一个位置会导致错误,除非这些假设也在新位置上有效。因此,粘贴的代码通常从一开始就错了,而不是在下一次更改之后。

从设计角度看,复制粘贴的代码无疑是一场灾难,有可能在未来引发许多问题。但你在问为什么要花很多时间 马上 ,答案是:因为它从不只是复制和粘贴。

如果原始代码是为了被重用而编写的,作为一个相当独立的库,考虑到灵活性和客户机的使用——那么很好,但这不是复制粘贴,而是使用代码库。真正的代码复制粘贴通常更像这样:

• “当然,我已经有了能做到这一点的代码!”
• “等等,这五个版本的代码中哪一个是我想用作源代码的?”
• “嗯,所有这些‘util_func_023’函数都做什么?我没有记录下来吗?我现在需要哪一个?”
• “哦,是的,这段代码使用的是代码基y。我想我需要[ 选择一个: 将所有代码基y复制到我的新项目中/花一天时间从代码基y中解救出我想要的函数/花一周时间从代码基y中解救出我想要的函数]。”
• “我什么都抄了,耶!”
• “为什么这不起作用?”
• 这就是您花数小时/天/周时间调试与所需类似的现有代码,而不是编写实际需要的代码的地方。

总之,现有的不能直接使用的代码充其量只能作为编写类似代码的良好参考。当然,它不可能被完全提升,并期望在一个完全不同的系统中工作。一般来说,这是一个安全的假设,任何已经编写和完成的代码,都应该被尽可能少地弄乱-即使它是一个副本,而不是原始的本身。

如果你想把你的项目建立在复制粘贴的基础上,你必须编码 首先 以便于重用的方式, 没有 复制原始代码并乱搞它。这是值得做的,如果这是你的老板期望的,那么你俩都需要确保这是你设计和工作的第一步。

复制和粘贴是一场等待发生的灾难。你的老板应该尽早评估发货的价格,而不是很快将坏代码发送给最终用户的价格。

如果您已经实现了这些特性, 需要 要复制粘贴以重用它们,听起来你好像做错了什么。难道你不能把这些特性放在一个库中,这样你就可以不用复制/粘贴就可以重用它们吗?

干巴巴的原则(不要重复你自己): DRY on wikipedia .

“在一个系统中,每一项知识都必须有一个单一的、明确的、权威的表示。”

other link .

在我看来,你的非技术型老板最大的误解是,你的工作主要是打字。他们认为不用打字可以节省很多时间。

我认为你能给这个人最好的教育就是指出你做的所有工作都不是打字。即使大部分的工作都是在打字的同时,在你的头脑中,在无形中发生的。

当然,不打字会节省一些时间。但是,当你的工作变得更大,不打字的时候,你的工作就会变得更大,消耗掉你节省的时间和更多的时间。

你确定你的老板想听关于干原理,虫子和其他技术的东西吗?

当你的老板或公司低估了完成某个项目所需的时间时,你通常会听到这样的评论。基于错误的估计,签订了一份合同等。在大多数情况下,程序员不参与估计。

为什么会这样?有时项目发起人的预算太小。也许您正在使用软件自动化的业务流程不值得您的团队努力。在这种情况下,经理们通常会对坏消息非常保密。项目一开始就有一厢情愿的想法。然后经理们试图责怪程序员。在您的情况下间接通过复制和粘贴。在极端情况下,这被称为 a death march .

复制和粘贴代码通常会导致 Programming by Coincidence

我想“ 另一个应用程序 “是这里的关键,如果另一个应用程序已经测试并正在使用,它应该 不可更改 要使用公共库,因此不能与之共享代码。

内 相同的应用程序 ,copy and paste是不好的,但是在由不同团队开发的代码基之间,或者在具有不同发布周期的代码基之间,copy and paste可能是最好的选择。

我在一家类似的公司工作。作为一名实习生,我当时不太清楚,所以当我开始一个新项目时,我的老板也建议把代码从其他地方粘贴过来。嗯,正如你可能认为的,整个软件相当混乱,以至于当你试图修复一个错误时,出现了两个新的错误。

即使另一个应用程序已经具备了您需要的功能,但如果不进行重大重写,该功能的代码可能根本不适合您当前的应用程序。这就像拿着福特的汽车,想把它装进丰田。一般来说,有一个经验法则,如果你必须修改超过25%的你复制的代码,最好(更便宜)从头重写它。

将有问题的代码提取到库中听起来很有吸引力,但这可能比听起来更困难,这取决于其他系统是如何构建的。例如,该特性的代码可能很难提取,因为它以不干净的方式(例如通过访问大量全局变量等)与许多其他代码进行接口。

告诉您的老板,每个变量名的一部分都包含了旧项目的名称,现在您必须手动更改它们。如果你的老板不知道(或想知道)为什么复制/粘贴不好,他/她可能会相信:)

在眼前的即时功能的开发速度(特别是当应用程序很小时)和应用程序增长时的长期维护成本之间存在权衡。

对于即时功能来说,复制和粘贴速度更快,但随着应用程序的大小增长,在修复错误、进行系统范围的更改以及维护应用程序不同组件之间的工作流方面,将花费大量成本。

这是企业主需要听到的论点。它类似于维护车队的公认成本,但是,有了软件,软件体系结构的破碎部分通常隐藏在业务方面,并且只能由开发人员看到。

他说得对,如果团队以前实现过类似的功能,那么 许多的 第二次更容易。

但是,您可能应该解释每个应用程序是不同的。仅仅因为你在一个房子里安装了一扇门并不意味着你可以在另一个房子里安装另一扇门 无时间平面 -你会更快,因为经验(门安装),但它仍然需要时间给你的设备,安装门,确保它是垂直的,并拧入框架。

是的,最大的问题是它不仅仅是复制和粘贴-它的复制然后粘贴然后稍微修改。

稍后,当粘贴的变体之一出现问题时,它将被更改。后来,另一个变体被改变了。

然后,您会发现所有变体都必须更改,因为原始副本有错误。现在你真的完蛋了,因为所有的粘贴区域现在都不一样了。

你不知道吗,这种糟糕的编码通常几乎完全没有注释。

对我来说,不同的是当你有多个代码副本做同一件事时,你得到的是一堆代码。当你只有一段代码在做每一件特定的事情时,你就有了一个系统。

系统的行为可以很容易地通过单点修改来改变——改变一堆代码的行为需要一堆代码。

我喜欢系统,而不是一堆代码。

在我的公司里,我们总是使用类和方法,并为它们制作技术文档。我认为如果你能用你自己的SVN搜索应用程序和好的键来查找以前使用的方法类,这是最好的做法:)