Verwenden Sie Metriken, um eine Entscheidung zu treffen, welche Teile des Codes (Klassen, Module, Bibliotheken) als nächstes konsolidiert oder refaktoriert werden sollen?Wie entscheiden Sie, welche Teile des Codes als nächstes konsolidiert/refaktorisiert werden sollen?
Ich verwende keine Metriken, die automatisch berechnet werden können.
Ich benutze code smells und ähnliche Heuristiken, um schlechten Code zu erkennen, und dann werde ich es beheben, sobald ich es bemerkt habe. Ich habe keine Checkliste, um Probleme zu erkennen - meistens ist es ein Bauchgefühl, dass "dieser Code chaotisch aussieht" und dann zu argumentieren, warum es chaotisch ist und eine Lösung findet. Einfache Refactorings wie das beschreibende Benennen einer Variablen oder das Extrahieren einer Methode benötigen nur wenige Sekunden. Intensivere Refactorings, wie das Extrahieren einer Klasse, können bis zu ein oder zwei Stunden dauern (in diesem Fall kann ich einen TODO-Kommentar hinterlassen und ihn später umgestalten).
Eine wichtige Heuristik, die ich verwende, ist Single Responsibility Principle. Es macht die Klassen schön zusammenhängend. In einigen Fällen verwende ich die Größe der Klasse in Codezeilen als Heuristik, um genauer zu prüfen, ob eine Klasse mehrere Verantwortlichkeiten hat. In meinem current project habe ich festgestellt, dass beim Schreiben von Java die meisten Klassen weniger als 100 Zeilen lang sind, und oft, wenn die Größe 200 Zeilen erreicht, macht die Klasse viele nicht verwandte Dinge und es ist möglich, sie aufzuteilen um fokussiertere Klassen zu bekommen.
Wir verwenden Cyclomatic_complexity, um den Code zu identifizieren, der als nächstes refaktorisiert werden muss.
Ich benutze Source Monitor und routinemäßig Methoden umgestalten, wenn die Komplexität Metrik über 8.0 geht.
Jedes Mal, wenn ich neue Funktionen hinzufügen muss, suche ich nach bereits vorhandenem Code, der etwas Ähnliches tut. Sobald ich einen solchen Code finde, denke ich daran, ihn zu refaktorisieren, um sowohl die ursprüngliche als auch die neue Aufgabe zu lösen. Sicherlich entscheide ich mich nicht jedes Mal neu zu gestalten - meistens benutze ich den Code so wie er ist.
Ich Refactor im Allgemeinen nur "on-Demand", d. H. Wenn ich ein konkretes, sofortiges Problem mit dem Code sehe.
Oft, wenn ich ein neues Feature implementieren muß oder einen Fehler zu beheben, finde ich, dass die aktuelle Struktur des Codes macht dies schwierig, wie zum Beispiel:
Dann werde ich refactor.
Manchmal sehe ich Code, der problematisch erscheint und den ich gerne ändern würde, aber ich widerstehe dem Drang, wenn der Bereich gerade nicht bearbeitet wird.
Ich sehe Refactoring als ein Gleichgewicht zwischen der Zukunftssicherheit des Codes und Dinge zu tun, die keinen unmittelbaren Wert erzeugen. Daher würde ich normalerweise nicht umgestalten, wenn ich kein konkretes Bedürfnis sehe.
Ich würde gerne über Erfahrungen von Menschen hören, die als eine Routine routiniert. Wie hältst du dich davon ab, so viel zu polieren, dass du Zeit für wichtige Funktionen verlierst?
Manchmal ist es so einfach wie - dieser Code ist viel zu kompliziert und es macht mir jedes Mal Angst, wenn ich es modifiziere. – cgp