提高代码质量与可维护性请关注代码克隆

　　读研期间在实验室做的软件维护软件演化方向，同组人有做代码克隆方向，我觉得代码克隆对于在实际使用中更普遍一些，一方面浅显易懂，一方面很多人容易忽略，我就从自己对代码克隆的理解说说。

什么是代码克隆？代码克隆对代码质量和可维护性有什么影响？

　　先说一下代码克隆在实际项目中，不管大项目还是小项目都是有意义的，微软近几年已经从各方面加强对软件工程理论在实际中的应用做研究，下面

http://msdn.microsoft.com/en-us/library/hh205279.aspx 是微软在visualstudio中的代码克隆相关功能。

　　那么什么是代码克隆呢，这个链接已经解释了，“Code clones are separate fragments of code that are very similar.”，克隆是类似复制拷贝的意思，说白了，代码克隆是一种在代码中存在的现象，最简单的说法就是存在两段代码长的很像，very similar，有多像，就是很像，看起来很像，有时读起来也很像，有时读起来发现没那么像。

代码克隆怎么产生的呢？

　　克隆么，最简单复制粘贴，很多人写代码都会有很多的复制粘贴吧，参考既有代码，复制粘贴过来改改，有的时候改改就改出问题了:(，复制粘贴是产生代码克隆主要途径。当然还有了，也许程序猿A为了完成某项功能写了一段代码，程序猿B为了完成同样的子功能也写了一段代码，结果两段代码长的挺像，（有的时候长的不像，长的不像的但是功能一样的代码其实也是一种克隆，也会影响一些可维护性）。

代码克隆对代码质量和可维护性有什么影响呢？

　　上面微软的链接又给了“ Clones make it hard to change your application because you have to find and update more than one fragment”，关键字：hard，change，find，update，more than。什么意思呢，说白了，假如有两段代码长的很像甚至一模一样，有一天你发现其中一段代码出bug了，当你要修改这段代码时，那另一段代码是否要修改呢，你是不是要找到那段代码并且也要做同样的修改呢，如果有第三段甚至第一百段克隆代码呢，如果说可以拿这些工作量来跟项目经理和产品经理谈，且不嫌烦的做重复劳动，或者代码是按照行数来卖钱的，那另当别论了。

　　在学术领域，如果N个代码片段长的很像，那么就把这N个代码片段的集合叫一个克隆类，其中每个代码片段叫做克隆实例，实际上和编程语言中的类和实例（对象）是一样的意思。

　　如果代码中形成了这样的克隆类，那么其中某个克隆实例不管由于需求变更还是bugfix而需要修改时，寻找其他的克隆实例并衡量是否需要修改都是需要做的事情，若需要修改则重复修改，若不需要修改，唉，还要担心是否衡量错了。算我多嘴。

　　我记得学术领域中有这样的结论，90%的bug存在于10%的代码中？或者从２８原则看，80%的bug存在于20%的代码中。还有如果一个类或者方法出了bug，进行修改之后，可能还存在其他bug，就是在软件演化历史中经常修改的代码往往存在更多的bug，有人一定觉得这是废话么？我觉得不是，这是告诉程序猿警醒对代码的修改吧。

怎样消除代码克隆呢？

　　重构。通常来讲将克隆代码抽象重构成公共方法或者抽象到基类等都是常用的方法，当然有时更复杂的代码克隆情况可能就需要更复杂的解决方案，或者别解决了，因为不是所有的代码克隆都一定要被消除的。

代码克隆究竟是否是有害的？

　　这个学术界也在争论，有人说代码克隆不是好东西啊，这货是个祸水，有人说不是所有的代码克隆都是有害的，这个我导师也总挂在嘴边。我觉得呢，软件开发是个包含人的主观能动性的活动，这么复杂的东西不太容易被对与错这样两个极端来限制住，所以呢，我比较赞成不是所有的代码克隆都是有害的这种说法，我觉得现阶段对代码克隆的研究是可以帮助人扩展视野，从更多的角度关注人的活动、代码开发与代码质量的关联，而不是要形成个规则一棒子打死。

好，结论，哦不，我体会后的想法。　　

• 在开发中要警惕代码的复制粘贴，有时复制粘贴只是为了图省事，可能与代码克隆关系不大的，但是要有警惕的心理。
• 写好一段代码或一个类时可以使用代码克隆工具检查下是否存在克隆，也许你所完成的功能别人已经做了，当然如果项目组有很好的知识库就更好了。
• 由于需求变更或者bugfix时修改一段代码的时候最好可以检查下是否有其他的克隆片段，如果存在那么需要检查下是否也需要修改。
• 如果两段或更多的克隆片段在一次提交中被修改了，请衡量下是否需要重构或者如果不容易重构的话，请做标注警醒以后的修改。在学术领域中，无数人做了各种各样的eclipse插件或者其他工具来做代码克隆识别、关联、标注等，然而大部分可能还不足以在实际中使用或者不受重视而已。