Programmieren ist Handwerk. Man muss es lernen und immer und immer machen. Dann wird man gut. Und es macht Spaß! Man baut erst ein solides Fundament, dann baut man darauf ein Zimmer nach dem anderen. Wenn am Schluss alles wie geplant funktioniert, freut man sich wie ein Schnitzel ;-)
Ich habe schon von Häuslebauern gehört, dass sie ein wenig unzufrieden waren mit ihrem Haus. Wenn sie wissen, wie dies und jenes besser gewesen wäre, sind sie leider schon fertig. Beim Programmieren ist es ähnlich, aber man kann prima z.B. das Bad löschen und neu erstellen. Das ist ein gewaltiger Unterschied. Doch damit genug mit den Metaphern.
Ich selbst habe aktiv mit etwa 10 verschiedenen Sprachen Programme erstellt. Von Basic und Assembler über PL1 zu .NET. Natürlich ist es nicht so ähnlich wie Fahrrad fahren – kennt man eines, kann man mit allen fahren. Nein, es gibt Unterschiede. In der einen Sprache programmiert man dicht am Prozessor, verwendet Register und kümmert sich um Speicherzellen. In anderen Sprachen baut man einzelne Funktionen und ruft dann auf, was gerade benötigt wird. Ganz toll war dafür das gute Turbo Pascal mit seiner praktischen Oberfläche (GUI) geeignet. Heute werden sehr oft Sprachen mit umfangreichen sogenannten Frameworks verwendet. Man arbeitet nicht mehr prozedural, sondern objektorientiert. So oder so, Verzweigungen und Schleifen z.B. wird es immer geben.
Bleiben wir kurz bei einer sehr verbreiteten objektorientierten Sprache: Java. Braucht man beispielsweise einen bestimmten Teil einer Zeichenkette, benutzt man eine Stringklasse. Davon gibt es dutzende. Man wählt davon eine aus, je nach Erfahrung oder Vorgabe. Und gleichzeitig vertraut man darauf, dass diese spezielle Klasse auch weiterhin brav vom Hersteller / Entwickler gepflegt wird. Überhaupt muss man dem jeweiligen Framework vertrauen. Es ist vergleichbar mit einer Blackbox – man übergibt etwas und bekommt etwas zurück. Was dabei wirklich passiert, braucht (und will) man nicht wissen.
Was ich mit der Zeit gelernt habe ist folgendes: Man kann mit jeder Sprache gute oder schlechte Programme schreiben. Ich nenne mal zwei Beispiele. Kein Mensch würde heute eine komplexere Anwendung mit einer Scriptsprache schreiben. Und die andere Seite wäre, dass man eine einfache Sache nicht mit Hilfe eines komplexen Frameworks erstellen sollte. Leider passiert beides. Nicht immer ist es leicht, die richtige Entscheidung zu treffen. Bleiben wir bei einer einfachen App fürs Handy, welche Daten in einer Datenbank ablegt. Wer hierfür alles selbst programmiert mag stolz sein, wird jedoch immer Angst z.B. vor einem Android-Update haben.
Nochmal zu guten und schlechten Programmen. Das Programmiererleben läuft in drei Phasen ab. Zuerst programmiert man einfach los, probiert und testet und irgendwann ist man fertig. Man “denkt mit den Fingern”. Hätte man zuvor einen Plan gemacht (wie auch immer), sich über den Ablauf und die Algorithmen Gedanken gemacht, wäre man eher fertig gewesen, das Programm wäre wartbarer und ein Nachfolger hätte weniger graue Haare bekommen. Aber irgendwann weiß man wie der Hase läuft. Man hat die erste Phase abgeschlossen.
In der zweiten Phase schaut man über den Tellerrand und beginnt endlich bei der Objektorientierung. Man lernt wilde Dinge wie Vererbung, Polymorphie und das alles. Man schreibt selbst Klassen und durchforstet das verwendete Framework. Und bald hat man ein Programm geschrieben, welches rund und auf allen möglichen Plattformen läuft. An vielen Schulen und Unis wird sofort mit dieser Phase begonnen. Leider tappt man dabei auch in alle Fallen, welche man dank Phase eins bereits gemieden hätte. Manchmal kommt noch der akademische Bonus hinzu und niemand erkennt den Plan des Künstlers. Ist dann auch egal, jeder ist froh, dass es läuft. Mein ewiges Vorbild, Anders Hejlsberg, hat mal gesagt, es ist immer wieder schön, wenn man “the magic 15 lines” in dem Programm erkennt. Also, des Pudels Kern.
Klar, wie jetzt Phase drei aussieht. Man plant eine Sache sorgfältig, verwendet die Sprache seines Vertrauens und hinterlässt ein Programm, welches übersichtlich und wartungsfreundlich bleibt. Denn nichts ist beständiger als die Veränderung. Und ganz wichtig, man programmiert nicht vor sich hin, sondern steht in Kontakt mit dem Anwender. Diese Menschen wissen komischerweise (fast) immer besser, wie eine Anwendung zu funktionieren hat. Schaut mal unter dem Stichwort “Agile Softwareentwicklung” nach.
So, nun doch noch mal zum Bild. Nach viel Übung und Erfahrung weiß man auch, was dem Anwender gefällt. Man baut nicht einfach nur ein funktionierendes Haus. Man achtet auch auf gutaussehende Türklinken. Streicht die Fensterrahmen in der passenden Farbe. Ordnet die Türen so an, dass man ohne Kopfzerbrechen in die gewünschten Räume gelangt. Don’t make me think.
Meine zwei Cent,
Hannes
Neueste Kommentare