Ich würde zunächst einmal so vorgehen:
1. Konsistente Benennung von Units, Klassen, Objekten, Feldern, Variablen
Überlege Dir eine einheitliche Namensgebung für alle Teile deines Projektes. Im Idealfall soll man im Code sofort erkennen, ob es sich um ein Feld, einen Parameter oder eine lokale Variable handelt. Schaue Dir z.B. die
VCL an und versuche, die Systematik hinter der Benennung zu finden. Verwende für die Benennung der Konstrukte eine einheitliche Sprache, die DU am besten kannst, und der Leser vermutlich versteht. Verwende auch eine einheitliche Grammatik für Prozeduren: Entweder immer 'KundenSpeichern', 'KundenLaden' oder immer 'SpeichereKunden', 'LadeKunden'.
Denk nicht, das englische Namen professioneller sind. Manchmal ist es zum totlachen, wie sehr sich Entwickler einen abbrechen. Wenn Du Deutsch besser kannst, dann verwende Deutsch. Entwickelst Du für die Welt, dann eben Englisch (nachdem Du es fließend beherrscht).
2. Funktionen und GUI klar trennen.
Die Funktionalität packst Du in separate Units. Dabei fässt Du semantisch zusammenhängende Funktionalitäten zusammen. Wenn Du z.B. diverse Funktionen für einen 'Kunden'-Datensatz hast, dann kommen die in eine
Unit 'uKunden.Pas' (oder so ähnlich)
3. Objektbezogene Funktionalitäten in Klassen zusammenfassen
Nachdem Du deine ganzen Funktionen und Prozeduren klassifiziert hast, kannst Du dir einzelne Klassen daraus basteln.
4. Verwende Patterns
Besorg Dir ein gutes Buch über Musterorientiertes Softwaredesign und verstehe, wie einfach man sich damit das Leben machen kann. Finde in deinem Code Passagen, die man über die bekannten Grundmuster (GoF) abbilden kann und wende sie an.
5. Sei Faul
Schreibe für jede Funktionalität genau eine Routine. Vermeide Codewiederholungen. Sobald ein nicht total triviales Codefragment mehr als einmal in deinem Projekt auftaucht, schreibe eine eigene Routine dafür (Wiederverwendbarkeit).
Natürlich kann man noch die eine oder andere Refactoring-Regel anwenden, für Wiederverwendbarkeit sorgen, Code unabhängig gestalten, etc. etc. etc.
Beim nächsten Projekt hälst Du dich noch an folgende Regeln:
1.
Keep it simple. Lieber einen klaren, als einen schnellen Weg wählen (außer bei echt zeitkritischen Prozessen)
2.
Make it readable. Programiere so, das jemand anderes deinen Code versteht, und Dir auf die Schulter klopfen würde.
3.
Comment your code in the Sprache, die Dir am besten zusagt. Wozu umständlich in Englisch formulieren, wenn Du Deutsch viel besser kannst...
Schreibe deinen Code immer so, das er lesbar, klar strukturiert und leicht verständlich ist. Kommentiere kniffelige Tricks. Unterfordere den Leser nicht mit Kommentaren à la 'Zählvariable um eins erhöhen'.
Guter Code ist wirklich selbstdokumentierend. Verwende z.B. lokale Prozeduren / Funktionen, um kleine Teilaufgaben ('Finde kleinsten Wert') im Code zu dokumentieren.
Statt:
Delphi-Quellcode:
Var
iMin, i : Integer;
Begin
// Hier ist Code
...
iMin := MaxInt;
For i:=0 to lListe.Count - 1 do
If lListe[i]<iMin Then iMin := lListe[i];
// Noch mehr Code
vielleicht sowas hier:
Delphi-Quellcode:
Var
iMin : Integer;
Function _FindeKleinstenWert;
Var
i : Integer;
Begin
Result := MaxInt;
For i:=0 to lListe.Count - 1 do
If lListe[i]<Result Then Result := lListe[i];
End;
Begin
// Hier ist Code
...
iMin := _FindeKleinstenWert;
...
u.s.w.
Es ist noch kein (Programmier)-Meister vom Himmel gefallen denn erst die Übung macht den Meister.
Und last, but not least: Verwende
UML und
OOP erst dann, wenn Du es kannst. Vorher bringt das nix. Im Übrigen denke ich nicht, das man mit
UML automatisch tolle Programme hinbekommt. Man hat sein Chaos nur besser dokumentiert (sprich: grafisch dargestellt). Designfehler bekommt man damit auch nicht weg.