Gibt es ein sicheres Refactoring-Tool für .net (oder mindestens C#)?

Question

Ich habe vor kurzem Michael C. Feathers Buch Working effectively with legacy code gelesen und stieß auf den Punkt, wo er einen Weg zur Überprüfung der Sicherheit von automatischen Refactoring-Tools erwähnt.

Meine Frage ist: Gibt es irgendwelche sicheren Refactoring-Tools für die .net-Plattform?; das bedeutet Werkzeuge, die nur echte Refactorings und z.B. Erlauben Sie nicht die inline variable Refactoring auf der temp Variable im folgenden Beispiel, oder zeigen Sie zumindest eine Warnung, dass ich Logik ändern.

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; 
    } 
} 

ich getestet habe dieses Beispiel auf die Refactoring-Tools Resharper und Coderush + Refactor pro mit den neuesten Versionen und beide bestanden den Test nicht und erlaubt das Refactoring:

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; 
    } 
} 

Answer 1

Um mit automatisierten Refactorings wirklich sicher zu sein, ist sehr schwierig.

Als wir Refactorings zum ersten Mal in Visual C# eingeführt haben, haben wir uns die folgende Frage gestellt: Müssen unsere Refactorings die ganze Zeit die richtigen Dinge korrigieren, oder sollten wir ihnen erlauben, in bestimmten Fällen Fehler zu machen?

Um die ganze Zeit recht zu haben, würde viel Programmieraufwand nötig sein, was bedeutet, dass wir nur ein paar Refactorings in der Box bekommen würden. Es würde auch die Refactorings verlangsamen, da sie viel Zeit in die Validierung investieren würden.

Wenn man ihnen erlaubt, Fehler zu machen, wären sie für Teams ohne große automatisierte Testabdeckung nutzlos. TDD-Teams haben gute Tests, aber das ist nur ein Teil der Visual Studio-Benutzerbasis. Wir wollten keine Features machen, die wir den Leuten mitteilen mussten!

TDD-Teams würden schnell Fehler machen, aber sie würden genauso schnell lernen, unseren Refactoring-Tools nicht zu vertrauen. Sie würden zögern, sie zu benutzen, und suchen die meiste Zeit nach anderen Lösungen (Finden und Ersetzen statt Umbenennen).

Auch als C# -Team waren wir in einer guten Position, um High-Fidelity-Refactorings durchzuführen. Wir hatten einen einzigartigen Vorteil, mit den C# -Sprachdesignern und dem Compiler-Team auf dem Flur. Wir wussten, dass wir unsere Stärken ausspielen sollten.

Also entschieden wir uns, weniger hochwertige Refactorings zu machen, statt viele Refactorings, die nicht so zuverlässig waren. Heute gibt es 6.

Im Rückblick, ich wünschte, wir nur getan hatte, Umbenennen, Methode extrahieren und Einführung Lokale Variable. Die letzten beiden sind in der Implementierung fast identisch. Die 3 Parameter-Refactorings (es gab früher eine 7., Local Variable zu Parameter promoten, aber es war in VS2010 geschnitten) waren eine Menge Arbeit, um richtig zu machen, und waren es wahrscheinlich nicht wert.

Meine Empfehlung ist tun TDD, gibt Ihnen eine große Sammlung von Tests, so dass Sie sicher refaktorieren können, ob Sie ein Werkzeug verwenden oder es von Hand tun.

Answer 2

Refactoring ist von Natur aus riskant. Sich nur auf ein Tool zu verlassen, um Ihren Code sicher zu machen, ist unklug imo.

Wir verwenden Resharper aber nicht ohne das Sicherheitsnetz von umfangreichen Unit-Tests. Ich kenne kein besseres C# -Tool in diesem Bereich.

Answer 3

„Safe“ ist eher subjektiv ....

Während diese beiden Werkzeuge aus nicht „sicher“ auf der Grundlage dieser Test in Ihrem Kopf in Betracht gezogen werden beide dieser Werkzeuge sind sehr nützlich. Kein Werkzeug ist perfekt. Wenn es eine Situation gibt, in der sie etwas tun, das du nicht magst, dann meide es entweder, es zu tun oder erschaffe eine Arbeit.

Answer 4

Ich stimme nicht zu, dass Ihr "Test" Fehler zeigt.

Sie haben die Logik geändert, nicht das Werkzeug. Sie haben den Code so geändert, dass eine Methode wiederholt statt einmal aufgerufen wird.

Die Werkzeuge haben nur getan, was Sie ihnen gesagt haben.

Answer 5

Ich denke, Safe Refactor kann ein Werkzeug für Ihren Fall sein. Obwohl es für Java ist, können seine Konzepte für andere OO-Sprachen gelten.

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