这样代码重用？

这是一个工作中遇到的背景比较简单的争论。

有这么一个persistent object，姑且叫它Plan吧。

有这么两个函数：

Plan getPlanByName(String userid, String planName);
Plan[] getPlans(String userid);

getPlanByName内部执行的是：

select * from Plan where userid=#userid# and plan_name=#planName#
and status=1
order by order_num

getPlan的内部执行的是：

select * from Plan where userid=#userid# and status=1

现在，我的pair认为这里面有DRY violation。因为两个select有些重复的东西。pair认为可以这样重构：

Plan getPlanByName(String userid, String planName){
  Plan[] plans = getPlans(userid);
  for(int i=0; i<plans.length; i++) {
    Plan plan = plans[i];
    if(planName.equals(plan.getPlanName())) {
      return plan;
    }
  }
  return null;
}

而我并不认为应该这样做。我的理由是：
1。原来的实现很简单直观。sql本来就是声明式语言。放着简洁的声明式不用而用复杂的命令式，有走回头路的嫌疑。
2。重构之后代码量更多，还要写更多的单元测试。
3。两个select只见的共同之处更像一种偶然的而不是概念上的重复。让getPlanByName依赖于getPlan感觉增大了耦合。
4。真要觉得select里面的东西有重复，不如创建一个view: v_plans这样这两个select就变成：

select * from v_plans where userid=#userid#
select * from v_plans where userid=#userid# and plan_name=#planName#

避免了status=1的重复。虽然还有"select *"之类的重复，但是这种重复就是语法上的，就像我们在java程序里面可能写无数次"static public void"，我们从来不认为这是一个值得改变的重复。
5。效率。
6。系统本来是工作的。即使重构后确实好一点，也不值得花这个工作量。

而pair的主要观点是:
重构后维护上简单，不用维护两个select。

后来和组里其他人沟通，发现持重构想法的不只一个人，相对来说我的观点是比较孤立的。

那么你是怎么看这个问题？

百分之百的支持你的看法。简洁明了，易读易用永远是第一法则。

看来不仅是你的Pair是匠气十足，你们的公司的技术文化也是工匠文化。在这样的企业文化下，捉对编程恐怕不是享受。

这个用Hibernate的criteria似乎能消除一些重复代码
看来重构这个概念深入人心但是也像敏捷一样容易受到误解

这样写的脑袋没烧坏吧??? 还是太有钱了一点也不用考虑性能阿?

 Plan getPlanByName(String userid, String planName){  
 Plan[] plans = getPlans(userid);  
 for(int i=0; i<plans.length; i++) {  
   Plan plan = plans[i];  
   if(planName.equals(plan.getPlanName())) {  
      return plan;  
    }  
  }  
  return null;  
 }  

简单的问题复杂化哟！

过度重构的典型案例。在重构的过程中如何防止过渡重构？目前好像没有什么标准。把简单的事情变的更复杂应该是过度重构的一个标志。

读书不能太死板了

严重同意！
另外我觉得你们两个既然有这么多的分歧为什么还要结对编程呢？ 反而会影响效率
编程的积极性也会下降

select * from v_plans where userid=#userid# 
select * from v_plans where userid=#userid# and plan_name=#planName#

这两个合成一个呢

严重同意啊
在做大数据量查询时，恐怕很费时的。