Bartlebe schrieb:
Also meine erste Frage ist, welche Themen sollte eurer Meinung nach in einer Ausbildung zum Fachinformatiker Anwendungsentwicklung behandelt werden?
Grundlagen, Grundlagen, und dann die Grundlagen der Grundlagen.
Welche Daten bekomme ich, wie stelle ich sie da, wie gebe ich sie wieder ab?
MVC. MVC und MVC rekursiv. Bis zum Verrecken.
Unfallverhütungsmaßnahmen versteht man besser, wenn man versteht, weswegen man sie erfunden hat. Man muss auf die Schnauze fliegen und es muss weh tun. Programmieren lernen bedeutet Frust aushalten. Programmieren ist Schach spielen: Wenn man weiß, wie man von welchen Figuren geschlagen wird, stellt sich die Frage, wie man seine Figuren nach vorne bewegen kann um das Ziel zu erreichen. Und dabei auch vorauszuplanen, welche Opfer auf dem Weg erforderlich sind. Programmieren ist ein aufwendiges Strategiespiel.
Im Vergleich zum Schach, wo man mal eben die Hand ausstreckt und eine Figur versetzt bedeutet ein einzelner Zug in der Programmierung oftmals wochenlange Arbeit. Entsprechend muss man Züge voraus abschätzen können, bevor man ein paar Wochen/Monate/Jahre programmiert und dann feststellt, dass man einen gegnerischen Springer übersehen hat - siehe Jungfernflug der Ariane-5-Rakete.
Das ist nichts, was man mal eben so lernt. Ich habe nie eine Software verloren, aber wenn man Wochenlang Vollzeit nach Fehlern sucht, dann ist das frustrierend. Aber man lernt daraus.
Dieses Wochenende habe ich viel Zeit damit verbracht, das Typsystem meines selbstgeschriebenen Compilers auszutauchen. Ein Unterprojekt, was ich seit Jahren andenke. Das ist eine Aktion, die nicht an einem Stück geschehen kann. Ich programmiere nun also auch "Opferroutinen", die nur dafür da sind, den Code lauffähig und testbar zu halten, obwohl das neue Typsystem noch nicht lauffähig ist, weil es an anderen Stellen noch gar nicht verwendet wird. Der Code wird teilweise also später wieder weggeworfen. Mit diesem Bauernopfer schaffe ich mir Platz, um wichtigere Figuren günstiger zu positionieren.
Bei großen Projekten keine oder nur eine überschaubare Zahl von Fehlern zu gestalten, den Compiler zu nutzen, Fehler zu vermeiden, und aufwendigen Code zu schreiben, der nur für eine kurze Übergangszeit Qualität sichert, sind Dinge, die man nicht an kleinen Projekten lernen kann.
Um Qualität zu sichern, muss man lernen, wie man Qualität verhindert. Versteht man, was man nicht machen darf, kann man sich recht gut vorstellen, was man machen kann, ohne dass es Mist wird.
Darauf kann man gut Theorie aufbauen.
Der FIAE bietet allerdings mit Übungsprojekten nicht die Möglichkeit, Frust zu verstehen. Die Abschlussarbeit nach IHK hat einen Zeitaufwand von 70 Stunden für Planung, Dokumentation, Implementation und Qualitätssicherung.
Den Wechsel des Typsystems schätze ich auf 80-120 Stunden ein, von denen ich jetzt etwa 40 Stunden hinter mir habe, ohne Planung, Dokumentation brauche ich hier für nicht und den Großteil der QS übernehmen größtenteils hunderte bereits vorher geschriebene Tests.
Wenn ich jetzt einen grundlegenden Fehler mache, ist die Software kaputt. Kann ich die Fehler nicht beheben, was ja auch viel Zeit kostet, das überhaupt herauszufinden, weil man erst denkt dass man das schnell hinbekommt und sich so Fehler um Fehler einbaut. Schlussendlich muss man das System zurücksetzen und all die Zeit ist verschwendet, ohne dass man einen Fortschritt geleistet hat.
Arbeitet man mit mehreren zusammen, haben andere vielleicht neue Features auf die Fehler aufgebaut und es stellt sich die Frage, wie man die Fehler herausoperiert bekommt ohne die Features komplett zu zerstören.
Die Grundlage sollte also sein, zu verstehen, was Fehler sind, was Fehler bedeuten und wie man sie vermeidet. Und dafür muss man die Grundlagen verstehen und Patterns begründen können. Spaß macht vermutlich erst die Anwendung des Wissens, der Wissenserwerb ist eher frustrierend.
Die Nutzung von Spaßverstärkern, wie Robotern etc. ergeben also nur dann einen Sinn, wenn sie dazu genutzt wird, Fehler zu provozieren, die die Auszubildenden machen und dann verstehen müssen.
