代码有重复不应该想尽办法去除重复吗?

[boydfd]

我负责用 Go 写一个从 Redis 或 MySQL 中取数据，并且通过 http 协议将数据返回给客户端。

现在有三个查询，分别是当前，分时，分天的数据。因为发现重复的代码很多，所以我就想通过接口来让它们达到泛化的目的。

我现在的流程时这样的，三个 http 请求都使用同一个回调函数，并传入一个接口，通过接口实现 Redis 或 MySQL 部分在查询的时候，三种不同的处理，由于返回结果的数据接口是一样的，所以返回不成问题。

后来我的上司看了之后，说我这样写不好，要我分开写，他的理由是： 1:这三个请求是不同的请求，不要统一处理。 2:这么写的话，别人看我的代码会比较麻烦。

请问，他说的对吗？能否针对他提的两个理由进行分析一下

[quericy]

楼主的做法:
Interface_A{
//...
a(parameter_1)
}
Interface_B{
//...
a(parameter_2)
}
Interface_C{
//...
a(parameter_3)
}
a(parameter){
//Common Code
}

楼主老板想要改成:
Interface_A{
//...
//Common Code
}
Interface_B{
//...
//Common Code
}
Interface_C{
//...
//Common Code
}

伪代码,不知道理解是不是对的,从 dry 原则上看楼主的做法并没有错,也更利于当前的维护
但是也许老板是从需求和项目以后的可能性来考虑,
"他只说它们是不一样的东西",是否意味着这以后是三个独立的业务,只是当前阶段还是相同的罢了?

所以楼主还是需要根据具体的业务上下文来判断拆分还是复用更利于以后的维护和扩展.

[boydfd]

@quericy 差不多是这样吧，我和他说以后如果需要独立，到时候改也很简单，然后他还是觉得分开好。

[herozzm]

老板说的对，你还得考虑后期扩展性，比如需求以后有变动就好对照修改，别人接手也好看

[secret32]

我觉得即便以后是三个独立的业务，也应该以后再改成三个函数，现在还是用一个的好。
用三个函数对 Java 来说，只有业务独立后可以支持热部署这一点好处，然而这好处对 Go 应该等于没有。

[boydfd]

@secret32 我的想法和你是一样的！

[kaizixyz]

看得懂比方便改更重要。

[xchange]

可能老板对公司其他程序员的水平比较悲观……

[holy_sin]

不用太纠结，但是问题来了 你觉得那个号
```
if(){
xxx
}

if () {
xxx
}

if ()
{
xxx
}
```

[otakustay]

复制粘贴下我对这种事的看法

1. 复用有很多的目的，但少写代码不应是其中一个。
2. 复用的对象是逻辑，而非代码。
3. 复用所要看的不仅仅是当下，更是未来的发展趋势是否一致。
4. 参与业务的复用，在不理解业务的前提下往往会起到反作用。

http://otakustay.com/talking-reuse/

[nonesuccess]

有重复的话，应该去除。但是这句话不等于“代码”有重复就应该去除。
应不应该去除，取决于这两段代码是不是一个东西，在你上司的眼里也许他们就不是。
说简单点，代码里面到处有 int a = 0;你会想到抽取个公共函数么？

[bicoff9527]

可读性最重要吧

[g00001]

什么东西都不能绝对化，不是非此即彼，
有些时候重用的代码要封装，有些时候要避免过度设计、过度封装，以至于弄巧成拙。
有一些那种什么都封装的代码，的确看着特别恼人，写的人自己觉得很优雅，看的人觉得很笨拙。

[zhaozhiming003]

你老板很久没写代码了吧？

[whenov]

@boydfd ，给你个也许会让事情变得更加复杂的建议：
写个简单的脚本，把你喜欢的代码转换成老板喜欢的代码。
好处是可以如自己所愿，坏处是要多维护一个脚本。

[angelface]

不上代码，谁看的明， 说的清。

[qiumaoyuan]

只说原则：所有重复性的工作都应该教会机器，让机器来做——程序员的主要工作内容之一。

之二是尽量让其他人更加容易地知道你对机器都说了些什么。

没有了。

所以，不让你去除重复，是错的。问题是如何去除重复，而不是要不要消除重复。

“消除重复”和“代码易读”并没有矛盾，用你所使用的编程语言特性——比如面向对象——找到这两件事的平衡点。


我总是觉得，新手没有底线的追求消除重复是很有必要，很有好处的。但是过程中遇到问题要想办法解决，而不是偷懒，选择认为此路不通。