当前位置 : 主页 > 编程语言 > 其它开发 >

当2个项目中出现了只有一个方法的相同代码时,要不要单独建一个项目来消除

来源:互联网 收集:自由互联 发布时间:2022-05-25
最近碰到一个这样的问题,有两个Solution,它们之间在数据层上有一定的联系,简单说就是B项目为A项目提供录入数据的功能,功能上它们两个各有分工,代码暂时也没有耦合,但都出现

最近碰到一个这样的问题,有两个Solution,它们之间在数据层上有一定的联系,简单说就是B项目为A项目提供录入数据的功能,功能上它们两个各有分工,代码暂时也没有耦合,但都出现了一个验证某数据的要求,这个算法是相同的。我的第一反应是肯定要独立出一个Project,单独有一个类,里面有这个验证方法。然后2个Solution分别引入此Project。但我讲出这个想法,团队最后予以否定,说是如果有更多相同的类似验证数据的代码可以重用时再这样做,现在不是最佳时机(可以理解为可重用的太少了,等再多一点再做,或者是如果现在做会拖慢进度之类的)。

这反应出我一个特点,就是对代码质量的要求很苛刻。在生活中也可以体现出来,头上有个灯坏了,一闪一闪的,有些人可以永远忍受,我就不行,即使它闪的不是很厉害,我也受不了,我很奇怪为什么别人都能受得了。

绝对不允许有重复代码是敏捷开发中重要的原则,团队中也有人学了敏捷开发,可为何不站出来支持我呢?在讨论中出现了另外一个问题,假如2个项目中重用此代码,应该用ClassLibrary还是用WebService,下面我一并列出我的观点:

1. 首先一定要重用可以重用的代码。因为重复代码是维护的大敌,当不重用时,如果算法有某些修改,那么我们不得不同时改2个地方,即使算法没有修改,但是实现这个算法的代码自身有缺陷,那么也要同时改2个地方。(事后也证明,实现此算法的代码确实有缺陷,它没有预防可以避免的异常。)

2. 把这个相同的代码摘出来,放到一个单独的Project里,绝不会拖慢进度。有点经验的都应该明白,这个工作只不过3分钟的事儿。

3. 任何一个需求(特别是数据验证的任务),即使现在确实是只有一个,但都不应该看成一成不变的,应该看成有可能不断增加的。当不单独提出来时,每增加一个就要同时在2个地方加代码,既然有很大的把握可以预知未来一定会增加需求,为何不现在就积极准备呢?何况这2个Solution是有内在联系的,它们共同引用一个库是非常非常合理的,并没有增加它们之间的耦合度。

4. 如果重用应该用ClassLibrary。理由是WebService是比较Big的方案。首先,我们知道WebService最佳的应用是跨平台、穿越防火墙,但现在这2个项目是运行在同一局域网中的,WebService的优势完全用不上。第二,WebService在布署上比ClassLibrary复杂,主要是因为它的配置复杂,首先要有个WebSite来承载这个服务,它的地址和端口号需要配置进用到它的应用中去(假设按照代码类的方式访问),一旦改变了,就要改配置(针对现在的情况,要改2个地方的配置)。第三,WebService的性能不好,用在这里没有用牺牲一点性能换到任何一点好处,哦,唯一的好处是算法变了,可以只改一个地方,可是你们也说了,算法99%是不会变的。再看如果算法增加了的情况,比如新增了一个验证需求的时候,我们可以看到,用ClassLibrary或WebService工作量是一样的,都要重新布署3个地方(一个WebService,和两个用它的项目),即WebService也没有比ClassLibrary有任何的优势。

5. 还是像原来一样,我觉得现在的团队对“变化”的态度太保守了,我不明白为何这样显而易见的问题也要开会讨论,最后还得出一个“维持现状”的结论。我对现在团队越来越失望了。

也许有些人觉得我小题大作了,可我觉得高楼大厦都是由一砖一瓦盖起来的,我们必须重视一砖一瓦,而不是成天炫耀,我们用了什么什么模式,什么什么框架,这些号称“柱子”的东西。你们说对吗?

------------------------------

看了评论,发现漏说了一点,即WebService与重复代码的关系。我的理解是这样的(假设都用代理类来访问):

1. 当两个项目都访问同一WebService必然存在重复代码,即代理类本身,虽然它可以自动生成,不用我们管,但它确实是重复代码 :( 。

2. 另外访问WebService的2个项目都有重复的对WebService地址的配置信息,如果地址变了,就不得不改2个地方。

我之所以说WebService是个Big的方案,就包含有以上原因。

上一篇:Swifter C#之inline还是不inline,这是个问题
下一篇:没有了
网友评论