Delphi lernen, wie vorgehen

[Medium]

An und für sich klingt das nach einer löblichen Vergehensweise, nur hat sie, wie du merkst, auch ein großes Problem: So ein Menschgehirn ist stark abhängig von der Anwendung neuem Wissens, um sich dieses auch wirklich zu verinnerlichen. Jeder etwas erfahrener Programmierer würde dir, zumindest im Affekt, zu deiner Lernidee applaudieren, funktionieren wird das in der Praxis aber leider doch eher selten.

Ich habe mit Delphi auch "quasi" angefangen. Heisst: Ich hatte mit QBASIC als Kind schon einiges gemacht, wirklich verstehen was ich tat war aber nicht drin. Es funktionierte "irgendwie", und das fühlte sich prima an. Dann ganz kurz ein Gastspiel von Turbo Pascal, dann Delphi. Die ersten Jahre waren wirklich einfaches Zusammenklicken von Komponenten, und geflissentliches Ignorieren aller guten Paradigmen der Entwicklung - oftmals auch einfach mangels Wissen um diese, und privat nicht vorhandenem Internet. (Kann sich das heute noch wer vorstellen? Ich sicherlich nicht.)
Erst nach Ende meiner Schulzeit fing bei mir so wirklich das Programmieren nach "erprobten" Vorgehensweisen an, die Sorte, wo man sich noch vor dem Schreiben etlicher Zeilen Code ernsthafte Gedanken um die Dinge gemacht hat, die man erreichen will, und welche Türen man sich noch offen halten mag. Zu diesem Zeitpunkt war ich allerdings schon gut mit der Delphi IDE vertraut, und auch weitestgehend mit der Sprache Pascal. Erst ab dann hat sich alles hauptsächlich um die Konzepte gedreht.
Ich will nicht sagen, dass es falsch wäre diese "Meta"-Disziplinen anfangs ausser Acht zu lassen - bei vielem genügt es aber gerade am Anfang, sie einfach nur schon ein mal gehört zu haben. Die Menge an Programmen, die ich gebaut habe, ohne - nach heutiger Sicht - zu wissen, was ich tat, ist erschreckend . Aber es waren eben diese, die dazu führten, dass ich beim "ernst werden" nicht mehr viel über Kleinigkeiten der Sprache oder die Menüstruktur von Delphi nachdenken musste.

Was ich sagen will: Es ist einfach unerlässlich sich kleine Ziele zu suchen, die man minuziös versucht umzusetzen. Das kann in Einzelfällen auch Wochen dauern, aber eben dieser Biss zahlt sich nachher dadurch aus, dass man mit den ganz zugrunde liegenden Dingen nachher per Du ist, und sich um Konzepte und Strategien kümmern kann, ohne sich in Semantik zu verlieren. Keine Frage, das werden Programme sein, die man nach ein paar Jahren lieber peinlich berührt verschweigen will, aber die sind so wichtig! Der erste Taschenrechner, das erste "Spiel" aus 10000 TImage-Komponenten, der erste Sound den man mit 20 Jahre alten und lang abgekündigten API Funktionen abspielt, die ersten kaputt geschriebenen Dateien, weil Streams gegenüber "file of ..." so unnötig kompliziert erscheinen, der erste Thread, mit dem man fröhlich auf die GUI zugreift und Bekanntschaft mit den unerklärlichsten Zugriffsverletzungen macht... alles Dinge, für die man in Foren so gerne gerüffelt wird, die aber doch einfach Erfahrungen sind, die wie ich finde fest zum Lernprozess gehören. Einfach mal sich trauen ein Programm zu bauen. Irgendwas.

Bei meinen ersten QBASIC Gehversuchen war ich überglücklich, dass 10 Zeilen "**********" im DOS erschienen. Viel später kam ein "DOS-Emulator", der einfach nur so tat, als würde gerade das BIOS das RAM durchtesten (ja, ich war davon überzeugt, dass JEDER PC 4096kB davon hatte ), und nachher nach Kommandozeile aussah, intern aber auch nur alles ans DOS weiterreichte. Dann irgendwann der 256-Farben Mode - WOOHOO! (Co)Sinus-Funktion gefunden -> Lissajous Firugen! (Ich wusste bis nach meinem Studium nicht, dass sie so hießen. Sie waren einfach hübsch und farbig.) Als Krönung irgendwann ein über Monate gebauter, grafisch völlig übler, Space Invaders Klon, der so grottig programmiert war wie nur möglich. Aber es war ein spielbares Spiel! (Zumindest auf einem 386DX40, alles drüber wurde unspielbar schnell.) Aus heutiger Sicht alles diletantisch und völlig naiv gemacht, aber es waren kleine Ziele mit Erfolgen, die letztlich dazu geführt haben, dass das Handwerk an und für sich zu eben diesem werden konnte: Einem "Handwerk". Wirklich "entwickeln" kam erst etliche Jahre später.

Gerade Delphi macht einem die kleinschrittigen Erfolge relativ einfach. Nutze sie! Schreibe kleine unwichtige Programme voller Fehler, und völlig an jedem Ideal vorbei! Zerpflücke Google bei Problemen, sie werden halbstündlich dabei auftreten. Lasse dir in Foren hunderte Zeilen überheblich klingender "guter Ratschläge" entgegenschmettern - die Kunst ist es, die paar guten nüchternen Infos daraus zu extrahieren, den Rest doof zu finden, und dennoch ans Ziel zu kommen. So wie du klingst, wirst du aber auf weit mehr freundliche und hilfsbereite Leute treffen als die "ich will mal eben"- und "ich brauch für Schule und zwar morgen früh"-Faulpelze, die man hier und auch woanders so prominent wahrnimmt (weil sie einem zuweilen echt das Blut zum kochen bringen vermögen).

Probrammieren ist einfach wie so vieles. Man muss voll Krarracho gegen die Mauern rennen um zu erkennen, dass es sie gibt. Dann kann man sich nach und nach an deren Überwindung begeben, egal ob alleine mit Dokus und Suchen, oder durch Fragen bei anderen. Aber man muss los laufen, nur Theorie bis zum Master-Grade kann keiner so wirklich. Und selbst wenn: Es ginge viel zu viel Praxiserfahrung und erlernter Pragmatismus dabei auf der Strecke.

Zur Ausgangsfrage "Delphi lernen, wie vorgehen": Button auf das Formular, Doppelklick drauf, zwischen "begin" und "end" ein ShowMessage(Was'n hier los'n!?); schreiben, F9 drücken, Fehlermeldung kassieren, googlen, fragen, Doku lesen: Bumms -> Du wirst ab jetzt wissen, was Strings und Datentypen generell sind, wie und warum sie sich unterscheiden, und dass ShowMessage() eine Funktion ist, die einen Parameter eines bestimmten Typs braucht. Die Vorgehensweise lässt sich praktisch beliebig durchziehen, sie nennt sich "einfach mal machen"