代码之家  ›  专栏  ›  技术社区  ›  RoXX

有没有任何安全的.NET重构工具(或至少C)?

  •  5
  • RoXX  · 技术社区  · 14 年前

    我最近读了迈克尔·C·费瑟的书 Working effectively with legacy code 他提到了一种测试自动重构工具安全性的方法。

    我的问题是: 有没有安全的.NET平台重构工具? ;这意味着工具只允许真正的重构,例如不允许 inline variable 在上重构 temp 以下示例中的变量,或者至少显示一个警告,表明我正在更改逻辑。

    class Program
    {
        private static int _x;
    
        static void Main()
        {
            int temp = Test();
            for (int i = 0; i < 10; ++i)
            {
                Console.WriteLine(temp);
            }
            Console.ReadKey();
        }
    
    
        private static int Test()
        {
            return ++_x;
        }
    }
    

    我已经在重构工具上测试了这个示例 Resharper Coderush + Refactor pro 对于最新版本,两者都未通过测试,并且允许重构:

    class Program
    {
        private static int _x;
    
        static void Main()
        {
            for (int i = 0; i < 10; ++i)
            {
                Console.WriteLine(Test());
            }
            Console.ReadKey();
        }
    
        private static int Test()
        {
            return ++_x;
        }
    }
    
    5 回复  |  直到 13 年前
        1
  •  5
  •   Jay Bazuzi Buck Hodges    14 年前

    要真正安全地进行自动重构非常困难。

    当我们第一次在Visual C中引入重构时,我们问自己这样一个问题:我们的重构是否需要始终使事情完全正确,还是应该允许它们在某些情况下出错?

    要一直保持正确,需要很多程序员的努力,这意味着我们只需要在盒子里进行一些重构。这也会使重构变慢,因为它们在验证中花费了大量时间。

    允许他们犯错误会使他们对没有很好的自动化测试覆盖率的任何团队都毫无用处。TDD团队有很好的测试,但这只是Visual Studio用户基础的一部分。我们不想制作那些必须告诉人们不要使用的功能!

    TDD团队会很快发现错误,但他们也会很快学会不信任我们的重构工具。他们会犹豫是否使用它们,并且经常寻求其他解决方案(查找和替换而不是重命名)。

    此外,作为C小组,我们处于进行高保真重构的有利位置。我们有一个独特的优势,C语言设计师和编译器团队就在大厅里。我们知道我们应该发挥我们的优势。

    因此,我们决定减少高质量的重构,而不是进行许多不那么可靠的重构。今天有6个。

    回顾过去,我希望我们只做了重命名、提取方法和引入局部变量。最后两个几乎是相同的,从实现的角度来看。3个参数重构(曾经有第7个参数,将局部变量提升为参数,但在VS2010中被截断)是一项繁重的工作,很可能不值得这样做。

    我的建议是 做TDD,为您提供大量的测试集合,以便您可以安全地重构,无论您是使用工具还是手工操作。

    当我们第一次在Visual C中介绍重构时,我们问自己这样一个问题:我们的重构是否需要始终使事情完全正确,还是应该允许它们在某些情况下出错?

    要一直保持正确,需要很多程序员的努力,这意味着我们只需要在盒子里进行一些重构。这也会使重构变慢,因为它们在验证上花费了大量时间。

    允许他们犯错误会使他们对没有很好的自动化测试覆盖率的任何团队都毫无用处。TDD团队有很好的测试,但这只是Visual Studio用户基础的一部分。我们不想制作那些必须告诉人们不要使用的功能!

    TDD团队会很快发现错误,但他们也会很快学会不信任我们的重构工具。他们会犹豫是否使用它们,并且经常寻求其他解决方案(查找和替换而不是重命名)。

    此外,作为C小组,我们处于进行高保真重构的有利位置。我们有一个独特的优势,C语言设计师和编译器团队就在大厅里。我们知道我们应该发挥我们的优势。

    因此,我们决定减少高质量的重构,而不是进行许多不那么可靠的重构。今天有6个。

    Visual Studio Refactorings

    回顾过去,我希望我们只做了重命名、提取方法和引入局部变量。最后两个几乎是相同的,从实现的角度来看。3个参数重构(以前是第7个,将局部变量提升为参数,但在VS2010中被削减)是一项艰巨的工作,可能不值得。

    我的建议是 做TDD ,为您提供大量的测试集合,以便您可以安全地重构,无论您是使用工具还是手工操作。

        2
  •  10
  •   Steve Townsend    14 年前

    重构固有的风险。在我看来,仅仅依靠一个工具来保证代码的安全是不明智的。

    我们使用Resharper,但不能没有综合单元测试的安全网。我不知道在这个空间有更好的C工具。

        3
  •  5
  •   Chris Marisic    14 年前

    我不同意你的“测试”显示失败。

    你改变了逻辑,而不是工具。您更改了代码,这样将重复调用方法而不是一次。

    这些工具只是按照你告诉他们的做。

        4
  •  2
  •   Kevin LaBranche    14 年前

    “安全”是相当主观的…

    虽然这两种工具在您的头脑中并不被认为是“安全的”,但这两种工具都非常有用。没有工具是完美的。如果他们做了一些你不喜欢的事情,要么避免做,要么创造一个工作环境。

        5
  •  0
  •   Fabricio Buzeto abhi    13 年前

    我认为安全重构可以成为您的案例的一个工具。 即使是Java,它的概念也可以应用于其他的OO语言。

    http://www.dsc.ufcg.edu.br/~spg/saferefactor/