Ich danke Euch allen.
Nun werde ich das Heft in die Hand nehmen.
Hier gibt es ein angefangenes Programm, das den Code analysiert.
zumindest teilweise
Als erstes werde ich mir die Seiten aus dem Wiki übersetzen.
und mir auch Reshaper ansehen.
Albert

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

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.

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:

1. Was hindert uns am meisten beim Einbauen oder verändern einer Funktion?
   
2. Warum hindert diese gefundene Umstand uns?
   
3. 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 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).

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

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.

Ich danke für die ausführliche Antwort

In dem Zusammenhang muss ich einmal das Thema Obfuscation 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 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 die dies mal mehr mal weniger gut leisten. Ich persönlich habe sehr gute Erfahrungen mit dem Eazfuscator.NET gemacht.