MS macht mächtig Werbung mit dem Visuale Studio 2017 wegen Refactoring.
Gibt es Erfahrung, dass damit Zeit gespart wird gegenüber manueller Reorganisation?
CodeMaid soll da besonders gut sein
Discipuli

Moderiert von Christian S.: Tippfehler im Titel korrigiert
Moderiert von Christian S.: Topic aus C# - Die Sprache verschoben am Do 29.06.2017 um 20:37

Hallo,

ja, Refactoring spart durchaus einiges an Zeit. Wer schon mal eine Methode umbenannt hat und dann alle Aufrufe davon ändern musste, wird es zu schätzen wissen, wenn so etwas automatisch passiert. Aber auch lokale Änderungen wie die Einführung eines Initializers anstatt separater Zuweisungen ist sehr praktisch.

Ich würde aber einfach nahelegen, dass Du es ausprobierst, die Community-Edition enthält, wenn ich mich nicht irre, alle Refactorings und ist kostenlos zu haben. Dann kannst Du schauen, ob das Deiner persönlicher Art Code zu schreiben hilft, oder nicht.

CodeMaid habe ich nie ausprobiert, ich kenne noch den ReSharper von JetBrains. Das ist ein sehr mächtiges Werkzeug, dass mir persönlich aber ein bisschen zu geschwätzig mit seinen Änderungsvorschlägen ist und bei großen Solutions auch die IDE deutlich träger macht. Deshalb setze ich es aktuell nicht mehr ein.

Grüße
Christian

ReSharper (für C#) und Visual Assist X (für C++) waren vor Visual Studio 2015 eigentlich unabdingbare Erweiterungen. Inzwischen hat sich das ein bisschen relativiert, ich habe beide nicht mehr installiert. Auch Visual Studio 2017 kann inzwischen eine Menge Dinge, die vorher schmerzlich fehlten.

CodeMaid ist (nur) ein Quellcode-Formatierer, dieser macht keine Refactorings.

Hallo Christian,
Mit welchem Tool oder wie spare ich beim Refactoring Zeit gegenüber alles von Hand?

Th69 schreibe über CodeMaid Quellcode-Formatierer,
Was kann ich darunter verstehen. Der Begriff ist mir noch nicht begegnet.
Discipuli

CodeMaid scheint nur den Code zu formatieren. Also Einrückungen korrigieren, redundante Leerzeichen entfernen, sortierung von Member in Klassen etc.
Unter Refactoring versteht man eher Dinge wie Code als neue Methoden oder Klassen extrahieren oder Interfaces aus Klassen ableiten usw. Also etwas das tatsächliche strukturelle Änderungen vornimmt und nicht nur die vorhandenen Struktur schöner darstellt.

Die meisten Refactoring Tools erledigen neben den eigentlichen Refactoringaufgaben auch die reinen Formatierungsaufgaben (so auch Visual Studio). CodeMaid scheint letzteres aber ausschließlich zu tun. Deren Webseite benutzt auch das Wort Refactoring nicht sondern spricht von Code Cleanup.

Hallo Ralf,
Welche Refactoring Tools sind empfehlenswert?
Die aus Visual-Studio 2017.
Dazu habe ich schon ein Buch gesucht aber keines gefunden, das dieses Thema beschreibt.
Discipuli

Zitat:

Welche Refactoring Tools sind empfehlenswert?

Das hälte ich für eine ausgesprochene Geschmackssache. Es hängt von deinem Stil als Programmierer ab.
Die üblichen Verdächtigen bei mächtigen Refaktoring Tools sind insbesondere Resharper und CodeRush.
Es gibt aber viele kleiner Projekte die sich eher spezialisieren auf bestimmte Sachen (so zum Beispiel das genannte CodeMaid auf Formatierung) und daher einer nicht mit Einstellungen erschlagen für den persönlichen Programmierstil aber passender bzw. ausreichend sind.

Ich persönliche bin eher beim Benutzen von Refactorings zurüchhaltend und komme eigentlich mit den von Visual Studio aus.
Ich bin aber auch der Typ der dabei oft das Gefühl hat Kontrolle zu verlieren. Darum benutze ich oft explizit Refactorings nicht (zum Beispiel beim umbenennen öffentlicher Klassenmember) um zu sehen wo der Compiler dann meckert und ich kann dann über diese Stelle nochmal sinnieren.

Je nach Projektarchitektur muß man sich auch bewußt sein das bestimmte Refactorings (z.B wieder umbenennen) nicht zwingend funktionieren. Z.b. Dort wo stark auf Reflection gesetzt wird oder Dinge über über Attribute in Abhängigkeit gesetzt werden. Sobald man in dem Trott ist sich auf Refactorings zu verlassen hat man ein potentielles Problem.

@discipuli Fragen wir doch mal anders herum, was genau willst du denn refactoren?
Ich meine die häufigst genutzte Funktion die ich da nutze ist der im VS 2015 eingebaute rechts klick auf eine Funktion gefolgt von der Wahl des Menüpunktes "Umbenennen", das finde ich aber schon äußerst praktisch, insbesondere wenn die umbenannte Funktion/Variable/... häufig verwendet wurde. Was die Fomatierung betrifft reicht mit in der Regel auch Strg+K Strg+D. Ich habe zwar auch CodeRush im Einsatz, allerdings nur, weil es das bei einer Lizenz die mein Arbeitgeber kaufte oben drauf gab. Das ist gelegentlich mal ganz nett, allerdings aber ich auch einige Funktionen deaktiviert, da es sonst schon anfängt zu nerven und man ständig irgendwelche Schalter unter der Maus hat, die man gar nicht drücken wollte. Somit kann ich die Ansicht von Christian S. bestätigen, es kann auch zu viel sein.

Ich möchte die eingebauten Refactoring Tools nicht missen und finde, das sie die Arbeit enorm erleichtern, wenn du aber nicht ein Bestehendes Projekt komplett umstrukturieren willst, dann wirst du wahrscheinlich auch nicht viel mehr benötigen. Einen Grund auf Refactoring Prinzipiell zu verzichten und alles per Hand zu machen würde mir nicht einfallen, außer vielleicht lange Weile.

Ich bin wieder da.
wir müssen 2 cs mit 5000 bzw 2000 Zeilen auseinander nehmen.
ich würde einige hundert € für Resharper ausgeben.
Ich benötige dazu aber unbedingt ein deutsches Handbuch.
Kennt jemand so ein Buch?
Discipuli

Buch gesucht in dem Refactorung mit den Boardmitteln von VS 2017 beschrieben wird.
Darin sollte mehr beschrieben sein als Namen ändern.
Discipuli

- Nachträglich durch die Entwickler-Ecke gelöscht -

Auseinandernehmen heißt: die Datenbank aus dem mains.cs herausholen und die nur einmal öffnen. Das Ganze besser lesbar machen.

Ich habe zwei Bücher über C#. Darin steht kein Wort über Änderungen von Code"Refactoring". Es müsste ein Buch über Visual Studio geben. Und das sollte sich an der Oberfläche orientieren.

MfG
Discipuli

Moderiert von Th69: "Refactoring" des Textes

Das wird dann aber ein bißchen mehr als nur Code-Refactoring, sondern eher Architekturänderungen (d.h. Aufbau einer 3-Schichten Architektur: UI, Logic, Data Access).
Identifiziere ersteinmal die Methoden, welche den Datenbankzugriff machen und lagere diese in eine eigene Klasse aus.
Das mußt du dann von Hand machen, selbst VS-Erweiterungen wie Refactoring Essentials bieten (bisher) keine Codeauslagerung in andere Klassen an (da dann ja ersteinmal der neue Code nicht lauffähig ist, da man ja noch mehr Code-Änderungen wie Erzeugen einer Membervariablen und Initialisieren des neuen Klassenobjekts, etc. vornehmen muß).

Das ist eine klare Aussage,
Da das offensichtlich nicht so einfach ist.
suche ich eine Anleitung mit Beispielen.
Unsere Programme laufen einwandfrei, nur eine Erweiterung ist kaum noch möglich.
Membervariablen habe ich noch nie gehört.
Was sollen die machen, Code auf eine Varailble schreiben.
Dazu einen Lösungsweg anbieten, das müsste sich lohnen.
Ich behaupte mal, dass Millionen von Programmen in diesem Sinne "unmöglich" konturiert sind.
Also was sind Membervariablen?
Wie legt man die an?
Machst Du mir ein Beispiel Code kann ich dir ohne Ende geben.
Discipuli

- Nachträglich durch die Entwickler-Ecke gelöscht -

Guten Morgen
und das nennt sich nun Membervariable?
Discipuli

Oh, ich wußte nicht, daß dieser Begriff dir nicht bekannt ist (aber selbst [die englische] Wikipedia kennt diesen: Member variable, so daß du diesen einfach selber herausfinden hättest können ;- ).

Und damit meine ich einfach, daß wenn du eine neue Klasse erzeugst und darauf in der ursprünglichen Klasse zugreifen willst, du ja eine Referenz dafür benötigst, also muß dafür eine Membervariable angelegt werden (wo die jetzt initialisiert wird, also direkt in der Klasse oder aber als Konstruktorparameter übergeben wird, ist dabei noch eine weitere Entscheidung, die der Entwickler treffen muß).
Und daher kann es nicht so einfach ein automatisches Code-Refactoring dafür geben, obwohl so etwas schon toll wäre, d.h. wenn es verschiedene Optionen dafür gäbe (aus denen der Entwickler dann eine auswählen könnte - ähnlich wie "Extract Interface" mit Auswahl der Methoden).

Eine weitere Möglichkeit gerade bei Mehrschichtenarchitekturen ist auch die Verwendung eines Inversion of Control (bzw. Dependency Injection) Containers (schon wieder zwei neue Worte für dich?)...

PS: Wenn du nähere Infos über die 3-(bzw. Mehr-)Schichtenarchitektur benötigst, dann erzeuge dafür bitte ein eigenes Thema (denn das geht über das Thema Code-Refactoring heraus).

Um mal was zu klären
Ich bin kein Programmmierer.
Ich komme von außen um zur Ordnung aufzurufen.
Deshalb muss ich das nicht können aber die Zusammenhänge verstehen.
Ich danke dir für deine Antworten
Albert

Hallo discipuli,

ich schätze dann kann ich mir ein ungefähres Bild von der Situation bei euch machen. Ich habe schon einige kleine und Mittlere Firmen gesehen, die an ähnlichen Punkten standen. Tatsächlich war mein erster Job nach dem Studium die Übernahme eines Projektes, bei dem der einzige Entwickler hingeschmissen hatte, da er es nicht mehr gewartet bekam. Ich verbrachte die erste Zeit, nach der Einarbeitungsphase dann auch damit einige fundamentale Umstrukturierungen zu machen (und nein, dass hier ist keine Bewerbung ).

Th69 hat recht, in so einem Fall ist ein Refactoring Werkzeug, nicht das was ihr benötigt, auch wenn dieses nachher beim Feinschliff wieder hilfreich sein kann. Was ihr benötigt ist ein erfahrenerer Softwareenwickler/Architekt, der euer Projekt "sanft" umstrukturiert. Mit sanft meine ich, dass er bei seiner Arbeit jederzeit den Kosten/Nutzenfaktor beachtet. Klar kann man so ein Projekt komplett umschmeißen und auf eine Zustand "nach Lehrbuch" umarbeiten. In der Regel kann es dann aber in dieser Zeit nicht mehr weiter entwickeln und auf Kundenwünsche reagieren. So ein Prozess ist auch nicht in ein paar Wochen beendet. Man muss also die zuerst die größten Klöpse finden, für diese ein gutes Ersatzkonzept entwickeln welches nicht den völligen Umbau des umgebenden Codes bedeutet auch wenn diese Lösungen noch nicht perfekt sind. Jede Verbesserung lohnt sich.
Wichtig ist dabei, dass alle Entwickler mitgenommen werden, denn es hilft gar nicht, wenn Alter Code auf vernünftige Beine gestellt wird, während gleichzeitig neuer schlechter Code entsteht.
Wenn man dann die großen Probleme aus dem Weg geräumt hat, müssen die nächst kleineren angegangen werden, so das die Anwendung sich, über die Jahre, gesund wachsen kann. In den meisten Fällen klappt dieses Vorgehen, recht gut, in den anderen ist komplett neu schreiben die bessere Alternative.

Was ich damit sagen will ist, das eine einfaches "zur Ordnung aufrufen" oft nicht hilft, da die Beteiligten Entwickler oft nicht nur Betriebsblind sind, sondern auch teilweise gar nciht über das wissen verfügen wie man es besser macht. Wenn dieses wissen aber im Haus vorhanden ist, dann ist es auch wichtig das Heft einem Entwickler in die Hand zu geben, der sich allein für die Umstrukturierung verantwortlich zeigt. Dieser sollte nicht mit zusätzlichen Aufgaben behelligt werden und es muss fähig sein, seine Kollegen mitzureißen und auf die "neuen Wege" einzuschwören. Das ganze funktioniert wie gesagt nur, wenn alle mitmachen.