refactoring - 当您越过哪种类型的编码反模式时，您始终会对其进行重构？

我只是重构了我正在处理的类的不同部分中的一些代码，因为它是一系列嵌套的条件运算符(？:)，它们通过相当简单的switch语句(C#)变得更加清晰。

您何时会触摸与您正在工作的代码不直接相关的代码，以使其更加清晰？

最佳答案

我曾经进行过重构，遇到了类似以下代码的内容:

string strMyString;
try
{
  strMyString = Session["MySessionVar"].ToString();
}
catch
{
  strMyString = "";
}

Resharper指出.ToString()是多余的，因此我将其取出。不幸的是，这最终破坏了代码。每当MySessionVar为null时，都不会导致代码依赖NullReferenceException将其降低到catch块。我知道，这是一些可悲的代码。但是我确实从中学到了一个很好的教训。不要依赖于帮助您进行重构的工具快速浏览旧代码，请自己考虑一下。

我最终将其重构如下:

string strMyString = Session["MySessionVar"] ?? "";

更新:由于这篇文章正在被评论，并且从技术上讲，它不包含该问题的答案，所以我认为我应该真正回答该问题。 (好吧，这使我感到烦恼，直到我实际上梦到它为止。)

我个人在重构之前会问自己几个问题。

1)系统是否受源代码控制？如果是这样，请继续进行重构，因为如果出现问题，您总是可以回滚。

2)是否存在针对我要更改的功能的单元测试？如果是这样，那就太好了!重构。这里的危险是，单元测试的存在并不表示所述单元测试的准确性和范围。好的单元测试应该掌握所有重大变化。

3)我是否完全了解要重构的代码？如果没有源代码控制和测试，而且我不太了解所更改的代码，那将是一个危险信号。在重构之前，我需要对代码更加熟悉。

在＃3的情况下，我可能会花一些时间来实际跟踪当前正在使用我正在重构的方法的所有代码。根据代码的范围，这可能是容易的，也可能是不可能的(即，如果它是公共(public)API)。如果要归结为公共(public)API，那么您确实需要从业务角度了解代码的原始意图。

关于refactoring - 当您越过哪种类型的编码反模式时，您始终会对其进行重构？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/390289/