很长的方法总是需要重构吗？

Question

我面临的情况是,我们有很多非常长的方法,1000行或更多.

为了给你提供更多细节,我们有一个传入的高级命令列表,每个命令都生成一个较长(有时很大)的低级命令列表.有一个工厂为每个传入命令创建一个类的实例.每个类都有一个处理方法,其中生成所有较低级别的命令按顺序添加.正如我所说,这些命令序列及其参数经常导致处理方法达到数千行.

有很多重复.许多命令模式在不同命令之间共享,但代码反复重复.这让我觉得重构是一个非常好的主意.

相反,我们的规格与当前代码完全相同.每个传入命令的命令列表很长.当我尝试一些重构时,我开始对规格感到不舒服.我想念规范和代码之间的明显比喻,并浪费时间深入研究新创建的公共类.

那么这里的问题是:一般来说,你认为这么长的方法总是需要重构,或者在类似的情况下它是可以接受的吗？(遗憾的是,重构规范不是一种选择)

---

编辑:我删除了每个"生成"的引用,因为它实际上令人困惑.它不是自动生成的代码.

class InCmd001 {

  OutMsg process ( InMsg& inMsg ) {

     OutMsg outMsg = OutMsg::Create();

     OutCmd001 outCmd001 = OutCmd001::Create();
     outCmd001.SetA( param.getA() );
     outCmd001.SetB( inMsg.getB() );

     outMsg.addCmd( outCmd001 );

     OutCmd016 outCmd016 = OutCmd016::Create();
     outCmd016.SetF( param.getF() );

     outMsg.addCmd( outCmd016 );

     OutCmd007 outCmd007 = OutCmd007::Create();
     outCmd007.SetR( inMsg.getR() );

     outMsg.addCmd( outCmd007 );

     // ......

     return outMsg;
  }
}

这里是一个传入命令类的示例(用伪c ++手动编写)

Answer 1

代码永远不需要重构.代码既可以使用,也可以不运行.如果它工作,代码不需要任何东西.

需要重构来自你的程序员.阅读,编写,维护和扩展代码的人.

如果您无法理解代码,则需要对其进行重构.如果通过清理和重构代码来提高工作效率,则需要对其进行重构.

在一般情况下,我会说这是一个好主意,为了你自己重构1000+线功能.但是你没有这样做,因为代码需要它.您这样做是因为这使您更容易理解代码,测试其正确性并添加新功能.

另一方面,如果代码是由其他工具自动生成的,您将永远不需要阅读或编辑它.那么重构它有什么意义呢？

Answer 2

我完全理解你来自哪里,并且可以确切地了解为什么你按照它的方式构建你的代码,但它需要改变.

您尝试重构时的不确定性可以通过编写单元测试来改善.如果您针对每个规范进行了特定的测试,那么每个规范的代码都可以重构,直到您脸红,并且您可以对它充满信心.

第二种选择是,是否可以从数据结构中自动生成代码？如果你有一套完成驴工作和边缘情况的核心类,你可以根据需要自动生成重复的1000行方法.

但是,每条规则都有例外.
如果这些方法是规范的字面解释(非常少的附加逻辑),并且规格不经常改变,并且规范的"公共"部分(即恰好相同的位)在不同时间发生变化,并且你很快就会被要求从代码中获得10倍的性能提升,然后(并且只有这样)...你拥有的东西可能会更好.

...但总的来说,重构.

Answer 3

是的,总是.1000行至少比任何函数都长10倍,我很想说100x,除了在处理输入解析和验证时,用20行左右的行编写函数是很自然的.

编辑:重新阅读你的问题,我不清楚一点 - 你在谈论机器生成的代码,没有人必须触摸？在这种情况下,我会保留原样.

Answer 4

修改与从头开始编写不同.虽然你永远不应该编写这样的代码,但在重构代码之前,你需要考虑重构的成本,在破坏已经运行的代码方面的相关风险,以及在未来节省的时间方面的净效益.仅在净收益超过相关成本和风险时才重构.

有时包装和重写可能是一种更安全,更具成本效益的解决方案,即使乍一看它看起来很昂贵.

Answer 5

如果人类维护(并因此需要理解)它们,则长方法需要重构.