【发布时间】：2010-01-06 01:01:02
【问题描述】：
我继承了一个现有的代码库，其中的“功能”如下：
- 巨大的单片类 （字面意思）100 个成员变量 和页面合二为一的方法 （呃。屏幕）
- 具有大量参数的公共和私有方法。
我正在尝试清理和重构代码，让它更好一点 比我如何找到它。所以我的问题
- 值得（或者您是否）用 10 个左右的参数重构方法，以便它们更具可读性？
- 是否有关于方法应该多长时间的最佳实践？您通常将它们保留多长时间？
- 单片类不好吗？
【问题讨论】：
【发布时间】：2010-01-06 01:01:02
【问题描述】：
值得（或者你）用 10 个左右的参数重构方法，以便它们更具可读性吗？
是的，这是值得的。通常，重构不“合理”的方法比重构已经很好、很短且参数列表很小的方法更重要。
通常，如果你有很多参数，那是因为一个方法做的太多了——很可能，它应该是它自己的一个类，而不是一个方法。
话虽如此，在需要许多参数的情况下，最好将参数封装到一个类中（即：SpecificAlgorithmOptions），并传递该类的一个实例。这样，您可以提供干净的默认值，并且非常明显哪些方法是必要的和可选的（基于构造选项类所需的内容）。
是否有关于方法应该多长时间的最佳实践？您通常将它们保留多长时间？
方法应该尽可能短。它应该有一个目的，并尽可能用于一项任务。如果可以将其拆分为单独的方法，其中每个方法都是真实的、定性的“任务”，那么在重构时就这样做。
单片类不好吗？
是的。
【讨论】：
-
根据经验，如果你不能用一个句子来描述一个类或方法的作用而不使用“and”这个词，那么这个类或方法应该被拆分。跨度>
-
是的。它应该有一个特定的功能/任务。这通常意味着您可以说“X 类处理 ....”，只用一个词，没有连词。
-
为什么在编辑框中使用“•”而不是使用引号功能？只是好奇。
-
@wcoenen：我刚刚复制并粘贴了 OP 的项目。我将其更改为使用 > (blockquote)，仅供您使用；)
如果代码可以正常工作并且不需要触摸它，我不会重构。如果我无论如何都必须触及它们（为了扩展它们以实现功能或修复错误），我只会重构非常有问题的案例。我赞成务实的方式：只有（95%）触摸，你改变什么。
对你的具体问题的一些初步想法（虽然详细的很难不知道代码）：
- 开始对实例变量进行分组，然后这些组将成为“提取类”的目标
- 对这些变量进行分组后，您希望可以对一些方法进行分组，这些方法在执行“提取类”时也会被移动
- 通常有许多方法不使用任何字段。使它们成为静态的（它们很可能是辅助方法，可以提取到辅助类中。
- 如果不相关的实例字段混合在许多方法中，请加载“提取方法”
- 尽可能使用自动重构工具，因为您很可能没有适当的测试，而且自动化更安全。
关于您的其他具体问题。
是否值得（或者您是否）重构具有 10 个左右参数的方法，以便它们更具可读性？
确实如此。 10 个参数对我们人类来说太多了，无法掌握。很可能该方法做得太多。
是否有关于方法应该多长时间的最佳实践？您通常会保留它们多长时间？
这取决于...取决于偏好。我在thread 上说了一些事情（尽管问题是 PHP）。我仍然会将这些数字/指标应用于任何语言。
单片类不好吗？
这取决于你所说的单片机是什么意思。如果你的意思是很多实例变量、无穷无尽的方法、很多 if/else 复杂性，是的。
还可以看看真正的宝石（对我来说，每个开发人员都必须拥有）：working effectively with legacy code
【讨论】：
假设代码正常运行，我建议您先考虑以下问题：
- 代码是否有据可查？
- 你看懂代码了吗？
- 多久添加一次新功能？
- 报告和修复错误的频率如何？
- 修改和修复代码有多难？
- 代码的预期寿命是多少？
- 您使用了多少个编译器版本（如果有的话）？
- 它运行的操作系统是否会在其生命周期内发生变化？
如果系统将在 5 年内更换，记录良好，将进行少量更改，并且错误很容易修复 - 不管类的大小和参数的数量如何，都不要管它。如果您决定重构，请按照最大收益和最小更改的顺序列出您的重构建议，并逐步进行攻击。
【讨论】：