Entwickler-Ecke :: Thema anzeigen - Refactoring mit Visual Studio

Christian S. - Do 29.06.17 20:45

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

Ralf Jansen - Fr 30.06.17 09:56

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.

Ralf Jansen - Fr 30.06.17 12:03

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.

doublecross - Di 04.07.17 10:44

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 user profile icon

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.

Th69 - So 09.07.17 12:26

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 [http://vsrefactoringessentials.com/] 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ß).

discipuli - So 09.07.17 19:06

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

Th69 - Mo 10.07.17 09:14

Oh, ich wußte nicht, daß dieser Begriff dir nicht bekannt ist (aber selbst [die englische] Wikipedia kennt diesen: Member variable [https://en.wikipedia.org/wiki/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 [https://de.wikipedia.org/wiki/Inversion_of_Control] (bzw. Dependency Injection [https://de.wikipedia.org/wiki/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).

doublecross - Mo 10.07.17 13:53

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 ;)).

user profile icon

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.

Ralf Jansen - Di 11.07.17 10:04

Zitat:

Wie, woran erkenne ich die?

Woran kann ich schwer beantworten. Womit aber schon. Primär mit Wissen und Erfahrung.
Hier und da kann ein Tool oder Buch helfen aber ohne prinzipielles Wissen über was guten Code ausmacht, was man sich aneignen muß, helfen die wenig bis gar nicht.

Ich hätte einen Rat wenn der noch nicht erfühlt ist. Wenn ihr euren Code verbessern wollt und ihr habt Code von dem ihr glaubt das er funktioniert bringt ihn erst mal in eine testbare Form. Also bringt euch in die Lage wiederholbar zu überprüfen das er funktioniert. Dann habt ihr eine halbwegs sicher Grundlage um Code zu refaktoren/zu verbessern und weiterhin sicher zu sein das er funktioniert. Reaktoring/Redesign in größerem Umfang ohne Tests ist erstmal ein Risiko und keine Verbesserung der Situation.

Für das allgemeine Wissen kann ich die Klassiker von Martin Fowler (Refactoring), Robert C. Martin (Clean Code), Andrew Hunt (Pragmatic Programmer) und Roy Osherove (Art of Unit Testing) empfehlen. Das sind aber Bücher die notwendige Grundlagen schaffen. Heißt unabhängig von eingesetzter Sprache und IDE.

doublecross - Di 11.07.17 17:02

Hallo,

discipuli hat folgendes geschrieben :

noch ne´Frage
was sind die "Man muss also die zuerst die größten Klöpse finden"
Wie, woran erkenne ich die?
Albert

wie

Ralf Jansen sagte, dafür gibt es keinen Automatismus.

Du sagtest ihr könnt euer Projekt kaum noch warten, dann solltet ihr zuallererst herausfinden warum. Und damit meinen ich nicht, eine allgemeine Antwort sondern konkrete Probleme/Implementierungen. Vereinfacht gesagt müsst ihr euch folgende Fragen stellen:

Was hindert uns am meisten beim Einbauen oder verändern einer Funktion?
Warum hindert diese gefundene Umstand uns?
Wie kann man das besser machen? Wie müsste eine Implementierung aussehen, die das gleiche Leistet, uns aber nicht behindert, und die dennoch erweiterbar und wartbar bleibt?

Und dann macht es Besser und entfernt das alte Konstrukt komplett aus eurem Code!
Hierbei solltet ihr aber immer nur ein Problem nach dem anderen lösen, da solche Umstellungen in der Regel viele Fehlerquellen bieten.

Das ganze ist nur nicht ganz so einfach, da man 1. das Problem erkennen muss und nicht bloß ein Symptom 2. auch eine gangbare Lösung finden muss. Wie von user profile icon

Ralf Jansen gesagt, dazu braucht es Erfahrung und auch den Mut und den Willen etwas zu verändern (immerhin muss man sich, wenn man selbst an dem Projekt gearbeitet hat, auch eingestehen, dass man bisher keine ausreichend gute Lösung abgegeben hat. Die Fähigkeit zur Selbstkritik ist also auch gefragt).

discipuli - Mo 17.07.17 12:10

Jetzt habe ich jemmanden daran gesetzt, ein Programm zu entflechten.
Der schreibt mir Sachen, die ich so noch nie in einem Prgrammen gesehen habe.
Vor allendigen es gäbe standaddmäßig 2 exen eine "halbe" und eien "vollständige"
it das ok?
Hier der Text

Von Visual Studio werden Zwischenversionen der EXE angefertigt. Diese befinden sich zum Beispiel im /obj Ordner. Diese Exe Dateien sind zwar ausführbar, nicht aber „fertig“ kompiliert. Ignorieren Sie diese Dateien – sie gehören zu Visual Studio und werden automatisch erstellt. EXE Dateien, die Sie im /bin Ordner finden wurden von „mir“ erstellt. Standardmäßig gibt es eine Debug und eine Release Version. Sie werden später die Release-Version verteilen.

Ist das alles unabänderlich

Gruß Discpuli

Bergmann89 - Mo 17.07.17 13:00

Sein Satz klingt komisch, ist aber durchaus berechtigt. Visual Studio erstellt während des Entwicklungsprozesses mehrere Datein, die es benötigt um den Programmierer einige Aufgaben abzunehmen oder zu erleichtern. Außerdem erstellt es temporäre Datein, die es benötigt um die eigentliche EXE zu erstellen. Diese Datein erstellt es im Ordner /obj. Es kann durchaus sein, das in diesem Ordner die ein oder andere EXE liegt die augenscheinlich das Programm beinhaltet/startet.
Im Gegensatz dazu gibt es den /bin Ordner. Hier liegen alle Datein, die beim Build-Prozess erstellt wurden und für den reibungslosen Betrieb des Programms benötigt werden. Für dich als "User" sind also nur die Datein im /bin Ordner wichtig.
Wie er schon schreibt gibt es eine Release und eine Debug Variante des Projekts. Diese Varianten unterscheiden sich meißt nur darin, das verschiedene Log-Ausgaben oder Performance Optimierungen de-/aktiviert sind.

MfG Bergmann.

doublecross - Mi 19.07.17 11:44

In dem Zusammenhang muss ich einmal das Thema Obfuscation [https://de.wikipedia.org/wiki/Obfuskation] ansprechen, um sicherzugehen das dass dahinterstehende Problem bekannt ist. Sollte dies der Fall sein, kann dieser Beitrag gerne ignoriert werden. Das ganze hat zwar direkt nichts mit der Unstrukturierung des Quelltextes zu tun, aber vielleicht im weiteren Sinne mit der Umstrukturierung eines ganzen Projektes. Ich komme darauf, da dies bei uns einer der nicht unerheblichen Unterschiede zwischen den Debug und Release Kompilaten ist.

Also, generell ist es bei .NET Programmen (aber auch bei anderen Plattformen wie JAVA) so, dass die Quelltexte nicht in eine Klassische EXE übersetzt werden, welche so vom Betriebssystem ausgeführt werden kann, sondern in einem Zwischencode (auch wenn die Resultierende Datei EXE heißt und sich starten lässt). Dies erlaubt es, die finale Übersetzung des Programms erst beim ersten Starten zu erledigen und dabei gezielt auf das Zielsystem zu optimieren.

Der Nachteil dabei ist aber, dass man den Zwischencode auch wieder Problemlos in den Quelltext zurückverwandeln kann. Somit ist jedes .NET Programm erst einmal Quasi Open Source, weil jeden mit wenig Aufwand an die Quelltexte kommt. Hier [https://www.jetbrains.com/decompiler/] gibt es z.B. ein kostenloses Tool, mit dem man dass für die eigenen Programme überprüfen kann.
Da es prinzipbedingt ist, lässt sich das erzeugen des Zwischencodes auch nicht verhindern. Was man aber mach kann ist den Release Zwischencode zu verschleiern. Man lässt also ein zusätzliches Programm drüber laufen, dass alle Variablen, Objekte und Funktionen in völlig unleserlichen Kram umbenennt. Darüber hinaus, werden bei guten Tools auch noch tonnenweise anderer Tricks angewendet um den aus dem Zwischencode gewinnbaren Quelltext unleserlich zu machen. So werden z.B. Strings Verschlüsselt, Schleifen durch Gotos ersetzt, bekannte Codeschnipsel durch schwerer verständliche ersetzt, die das gleiche leisten usw.

Wenn man verhindern möchte, dass der eigene Quelltext in die Hände Dritter gerät, ist dies für .NET Entwickler die einzige Möglichkeit. Es gibt einige Programme [http://www.csharp411.com/net-obfuscators/] die dies mal mehr mal weniger gut leisten. Ich persönlich habe sehr gute Erfahrungen mit dem Eazfuscator.NET [http://www.gapotchenko.com/eazfuscator.net] gemacht.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!