Zitat von
Phoenix:
Zitat von
taaktaak:
Und wenn es dann auch gleich so schön funktioniert, dann sagt das "kleine Teufelchen im Hinterkopf": Warum willst du es denn anders machen?
Um Dir selber einen Gefallen zu tun.
Ein Code wird genau ein einziges mal geschrieben.
Der gleiche Code wird jahrelang immer wieder gelesen und ggf. leicht abgeändert.
Du bist mit aller Wahrscheinlichkeit derjenige, der in 2, 3 Monaten wieder Deinen eigenen Code lesen darf.
Wie oft ist es schon vorgekommen, dass Du Dich gefragt hast warum Du das damals so geschrieben hast? Anders wärs doch eigentlich besser...
Warum änderst Du den Code dann nicht einfach so, dass er besser wird?
Weil Du Angst hast, dass Deine Änderungen ggf. etwas kaputt machen könnten.
Ergebnis: Alter, schlechter Code bleibt schlecht und wird durch neuen, zwangsläufig auch nicht optimalen Code ergänzt.
Das ganze System verrottet mit der Zeit, und der Aufwand der für die Wartung getrieben werden muss, wird immer größer und größer.
Die Angst, dass Änderungen etwas kaputt machen können nimmst Du Dir durch (automatisierte) Tests. Wenn Du was änderst wird Dir ein Test sagen, ob etwas kaputt gegangen ist oder nicht. Voraussetzung für Tests ist aber sauberer Code mit wohldefinierten Zuständigkeiten.
Wenn Du Dich also in die in dem Buch vorgstellten SOLID Prinzipien hältst, dann erhältst Du hinterher besseren und leichter testbaren Code. Und der erlaubt es Dir dann, Änderungen (Verbesserungen!) zu machen, ohne dass Du Angst haben musst, dabei etwas kaputt zu machen.
Da wär ja ein Buch über Unittests gut. Hab da schon bissl Online Dokud angeguckt. Im Delphi Treff ist auch eine Einführung.
Was ich aber dabei noch nicht verstehe ist:
Teste ich dabei prozeduren + Funktionen, gewissermassen jede Prozedur/Funktion einzeln?
Gut, ich könnte auch ne Klasse testen, infem ich sie von DUnit Framework teste.
Aber ist das eher ein Verfahren was zu mehr Disziplin beim Testen zwingt oder worin liegt der Vorteil?
Delphi-Quellcode:
//Aus dem Delphi Treff Tutorial zu DUnit:
type TAddressTest = class(TTestCase)
private
FAddressBook: TAddressbook;
protected
procedure SetUp; override;
procedure TearDown; override;
published
procedure TestOne; //Hierfür muss ich genauso meinenTestroutinen schreiben
procedure TestTwo; //ZB. meine Klassenmethode, die dann halt vor Einsatz getestet wird.
end;
Nun würde ich zu testende Methoden von TestOne, TestTwo... aufrufen lassen.
Ich könnte aber ebenso gut meine Klasse normal entwickeln, ohne DUnit und dann genauso jede Methode testen, nachdem ich Code reingeschrieben habe. In beiden Fällen muss ich selber die nötige Disziplin aufbringen, die Tests auch durchzuführen.
Wenn also der Test mit DUnit besser sein soll, hab ich was grundsätzliches noch nicht verstanden. Wo also kann ich mich da schlau machen? Das Delphi Treff Handbuch ist da zu kurz.
Da es aber hier eigentlich um Buchempfehlungen geht, statt um Fragen zu guten Programmierbüchern, empfehle ich hier das
"Delphi X Kochbuch" von Deberenz/Kowalski, Hanser Verlag.
Das X steht für die Delphi Version. Das Buch gibt Rezeptlösungen im Sinne von Wie kann ich:
-einen Splash Screen programmieren
-eine Bitmap drehen
.....
Mir hat das nach dem Buch
"Delphi 3.0 lernen" ein Ganzes Stück weiter geholfen. "Delphi 3.0 lernen" ist für absolute Newbies geschrieben. Wer dann weiter will, für den ist das Delphi X Kochbuch genau das Richtige. Erst danach ist weiterführende Delphi Literatur zu empfeheln. Wie das Delphi Entwicklerhandbuch. Hab ich für Delphi 4, ist aber mit dem was dort beschrieben wird immer noch aktuell.
"Delphi 4 Developers Guide" von Steve Teixeira & Xavier Pacheco.
Da wird auf das Windows
API eingegangen,
Dll Programmierung behandelt, Hooks erklärt und vieles Andere mehr. Ist allerdings in englischer Sprache geschrieben.