Whiz-zarD

Du kannst es so oft schreiben, wie du willst und trotzdem wird es nicht richtiger. Mag sein, dass es Bestandteil der Ausbildung ist (was ich auch durchaus für angemessen halt), es sollte aber kein Kernbestandteil sein und genau das meine ich, dass die Prioritäten falsch gesetzt werden. Die Softwareentwicklung ist schon ein sehr komplexes Thema und ich finde FIAEler sollten dann nicht noch zusätzlich ein halber Kaufmann werden, denn dafür gibt es schon die Informatikkaufmänner. Viel mehr sollte man sich hier auf den technischen Aspekt konzentrieren und genau das passiert auch in der Wirtschaft, wie ich z.B. schon mit SCRUM angesprochen habe. Mag sein, dass es viele kleine Firmen gibt, wo ein Entwickler dies benötigt aber nur aufgrund solcher Firmen den kaufmännischen Teil als ein Kernbestand der Ausbildung zu machen, halte ich schlichtweg für falsch. Ja, Wow ... Und für diese Erkenntnis braucht man drei Seiten? Es ist bekannt, dass eine Automatisierung schneller ist, als eine manuelle Abarbeitung und somit kostengünstiger. Das kann ich auch in einem Satz formulieren und brauche keine drei Seiten. Und wenn man den kaufmännischen Aspekt weglassen würde, wären bei der 100% Abschlussarbeit dafür 3 Seiten platz gewesen. Für mich sind Datenstrukturen ein Teil der Grundlagen und diese werden konsequent ignoriert. Stattdessen versucht man wohl in den drei Jahren auch den letzen Deppen beizubringen, dass es keine if-Schleifen gibt. Den Azubis wird doch keine Grundlagen beigebracht. Vielfach habe ich schon gesehen, dass z.B. Geldbeträge als eine Fließkommazahl dargestellt werden. Das ist eine Todsünde! In der 100% Abschlussarbeit wird zwar richtigerweise decimal als Datentyp genommen aber ob dies dem Azubi klar war, lässt sich aus der Dokumentation nicht ableiten. Auch werden oft Arraylisten verwendet, obwohl fleißig neue Elemente rangehängt werden. Dass so etwas inperformant ist und dafür eine verkettete Listen genommen werden sollte, weiß keiner. Die Grundlagen sind also mehr, als nur die Syntax. Zu den Grundlagen gehört auch der Verständnis der bekannten Datenstrukturen und so ein Verständnis ist Programmiersprachenunabhängig. Eine verkettete Liste funktioniert unter C genauso wie unter C# oder Java. Mit dem Unterschied, dass man sie in C erst mal selbst implementieren muss, während man in C# die List<T> und in Java die LinkedList<T> verwenden kann. DDD ist nicht auf Objektorientierung beschränkt. Genauso gut lässt sich DDD auf prozeduraler oder funktionaler Programmierung anwenden. Und genau das meine ich ja mit "Defizite" und "Ein Blick über den Tellerrand". Nicht jede Firma verwendet DDD, TDD oder klassische Unit-Tests aber eine Berufsschule sollte sich deswegen nicht verschließen, sondern sollte den Azubis so etwas zeigen und auch üben. In meiner Ausbildung als Mechatroniker hatten wir so einen ähnlichen Fall. Ich hatte meiner Klasse zwei Mitschüler, die in ihrer Firma nicht mit SPS-Programmierung, Pneumatik oder Hydraulik in Kontakt kamen. Den Part hat dann die Schule übernommen und genau so sollte es auch bei der Softwareentwicklung sein. Einfach zu sagen: "Gibt es nicht, weil nicht alle Firmen dies einsetzen!" ist falsch. DDD und TDD sind Konzepte, die sich in den letzten Jahren sehr bewährt haben. Warum sollte man den Azubis dies nicht beibringen wollen? Der Weisheit letzter Schluss ist das mit Sicherheit noch lange nicht. Sicherlich sind auch irgendwann diese Konzepte überholt und gegen andere ausgetauscht aber wir leben im Jetzt und Jetzt haben sie eine große Bedeutung. Vor 15 Jahren hatten Pflichten- und Lastenhefte noch eine große Bedeutung. Heute schon lange nicht mehr und dennoch tut die IHK so, als wäre dies DAS Prinzip, was auf Ewigkeit bestand hält. Ich habe ja nichts dagegen, dass den Azubis die Objektorientierung beigebracht wird aber man zäumt das Pferd oft von Hinten auf. Ich höre oder lese oft folgendes: "So, jetzt lernen wir Objektorientierung! Startet dafür jetzt alle Visual Studio und öffnet ein neues WinForms-Projekt" ... Das ist schon ein Zeichen für mich, dass man nichts über Objektorientierung lernt sondern nur mit der IDE rumspielt, wenn man schon so hoch in der Abstraktion anfängt. Dass im Hintergrund eine Endlosschleife läuft, die dafür sorgt, dass die grafische Oberfläche immer neu gezeichnet wird und die Events auslöst, wird nicht mal erwähnt. Gern genommen wird auch die allseits beliebte Entwicklung eines Taschenrechners. Aus meiner Sicht für ein Anfänger viel zu kompliziert, wenn man auch die Rechenregel "Punkt- vor Strichrechnung" und Klammersetzung einhalten möchte, denn da sind Konzepte wie z.B. die Polnische Notation oder Binäre Bäume sehr hilfreich. Auch wird dann hier das Konzept der Vererbung benötigt. Für mich sind also schon die angeblich grundlegenden Konzepte falsch gewählt. "Grundlagen" heißt offenbar, dass man die Hälfte verschweigt und den Rest dann nur noch überfliegt. Man muss bedenken, dass man hier Softwareentwickler ausbilden möchte und nicht Tante Emma mal im groben zeigen möchte, wie man programmiert. Daher sollte man den Azubis auch ein Grundverständnis vermitteln, was eigentlich wirklich passiert und wenn man das alles mal berücksichtigt, dann merkt man, dass da überhaupt kein Platz für einen kaufmännischen Teil ist und wenn man endlich diese Erkenntnis erlangt hat, dann ist man wohl endlich auf dem richtigen Weg. Ja, ich beziehe mich nur auf den FIAEler, da die Softwareentwicklung nun mal mein Hauptberuf ist. Zu den FISIs muss ich aber auch sagen, dass ich es für falsch halte, dass die FIAEler und die FISIs sehr häufig die selben Kurse in der Berufsschule haben. Beide sollten zwar Grundlagen in der Programmierung, der Shellskripte, den Datenbanken und der Netzwerktechnik haben aber dann sollten sich schon die Wege trennen. Ein FISI wird nicht großartig irgendeine Software mit Java und einer grafischen Oberfläche, die Daten in Echtzeit auswertet, schreiben und das habe ich bis jetzt noch in keiner Firma gesehen, dass dies erwartet wird. Genauso wird ein FIAEler kaum ein Windows- oder Linux Server mit Active Directory, Firewall, Proxy, DNS, DMZ und sonstigem Kram aufsetzen. Es ist zwar Nett, wenn ein FISI mehr über Softwareentwicklung und ein FIAEler mehr über die Server-Administration weiß aber das ist kein KO-Kriterium, wenn man es nicht weiß.

Dein Text klingt aber nicht so wirklich danach, als sei alles super. Sorry aber das, was ich von dir in diesem Forum gesehen habe, war keine objektorientierte Programmierung. Nur weil man eine objektorientierte Sprache verwendet, heißt es noch lange nicht, dass man auch Objektorientierung anwendet und Struktogramme braucht man im Alltag auch gar nicht. Struktogramme sind auch nicht einfacher zu lesen, als Code. Von daher kann man es auch gleich weglassen. Nicht nur das. Auch die Ausbildung gehört für mich komplett überarbeitet. Das ist echt schon abenteuerlich, was ich hier so über die Abschlussarbeiten- und Prüfungen lese. Die Azubis lernen veraltete und überholte Methoden, nur um die Prüfung bestehen zu können. Vieles, was sie in der Berufsschule lernen, können sie auch gleich nach der Abschlussprüfung wieder vergessen, weil es entweder in der Praxis gar nicht mehr angewendet wird oder so selten, sodass man sowieso erst mal einen Blick auf Google oder Wikipedia werfen muss. Meiner Meinung nach, setzt man auch die Prioritäten komplett falsch. Anstatt den Azubis drei Jahre lang Pseudo-Code und UML-Diagramme einzutrichtern, sollte man - vor allem den Anwendungsentwicklern - mehr sauberen Code beibringen aber offenbar ist selbst das in der Abschlussprüfung zu viel verlangt. Die offiziellen Lösungen der Programmieraufgaben in der Abschlussarbeit ist so ein schlechtgeschriebener Code, dass man davon Pickel bekommt, wenn man nur ihn ansieht. Von gravierenden Fehlern ganz zu schweigen. Was das Abschlussprojekt angeht, bin ich auch kein Freund vom Pflichten- und Lastenheft, was aber offenbar vielfach von der IHK gefordert wird. Das sind auch Fragmente aus einer alten Zeit. Ich habe inzwischen schon viele Projekte gesehen, wo ein Pflichten- und Lastenheft geschrieben wurde (ich habe auch schon sowas das eine oder andere Mal geschrieben) und ständig sind solche Projekte in die Hose gegangen, weil sich die Anforderungen ändern können oder gewisse Dinge sowohl vom Kunden als auch vom Entwickler nicht vollständig durchleuchtet worden waren. Beliebt sind auch Fehlinterpretationen. Sowohl Kunde als auch Entwickler schreiben den selben Wortlaut und dennoch reden sie einander vorbei. Viel wichtiger ist es, mit den Kunden ständig im Kontakt zu bleiben, damit man schnell auf Änderungen reagieren kann. Auch sollte man den Kunden immer mit dem Status informieren und ihm auch den derzeitigen Zwischenstand ungeschönt präsentieren und ihn nicht vor vollendeten Tatsachen stellen, wie es mit dem Pflichten- und Lastenheft der Fall wäre. Wenn man feste Termine mit den Kunden arrangiert, dann braucht man auch kein Lasten- und Pflichtenheft. Änderungswünsche können dann formlos festgehalten und im nächsten Meeting präsentiert werden. Ob und wann sich eine Entwicklung amortisiert hat, ist auch gar nicht die Aufgabe eines Entwicklers. Der Entwickler soll nur analysieren, wie aufwendig eine Implementierung ist. Mehr nicht. Auch lässt sich das als Entwickler oft gar nicht so einfach herausfinden, wie es um die Amortisierung steht. Dies ist nur bei In-House-Lösungen möglich. Wenn man eine Software für einen externen Kunden einführt, muss der Kunde diese Analyse vornehmen, weil der Entwickler kein Einblick in die Interna des Kundens hat. Auch eine Ist-Analyse ist hier gar nicht möglich, wenn der Kunde davon nicht redet. Wer in einem echten SCRUM-Team arbeitet, wird von solchen Analyse-Kram sogar ferngehalten. Nicht weil man den Entwickler dumm halten möchte, sondern weil jeder seine Kernkompetenzen besitzt und die Kernkompetenz eines Entwicklers ist die Softwareentwicklung und nicht das Ausloten der Wirtschaftlichkeit. Als Beispiel nehme ich mal diese Abschlussarbeit, die mit 100% bewertet wurde. Die Abschnitte "Projektkosten" und "Amortisationsdauer" lesen sich wie ein Standardtext, den man in jeder Abschlussarbeit reinknallen könnte. Diese Texte haben überhaupt keine Aussagekraft. Viel wichtiger wären doch technische Aspekte. In einem Nebensatz wird erwähnt, dass die Daten historisiert abgelegt werden sollen. Da werde ich als Entwickler doch sehr hellhörig, weil die Historisierung gar nicht trivial ist. Schon gar nicht in einer relationalen Datenbank. Da hätte ich schon ein Kapitel erwartet, dass sich mit diesem Thema auseinandersetzt. Was passiert z.B. wenn eine Spalte in einer Tabelle hinzukommt? Ich will ja nicht, dass die Azubis z.B. die Data Vault-Modellierung bis ins Detail verstehen und auch anwenden können aber wenn man schon so ein Thema anreißt, dann erwarte ich auch, dass man sich damit beschäftigt. Sei es auch nur, dass man die Risiken aufzählt. Meiner Meinung nach müsste das gesamte System reformiert werden. Wer nach drei Jahren immer noch nicht verstanden hat, dass es keine if-Schleifen gibt, wird das nie verstehen. Ich finde, eine Berufsschule sollte dafür sein, um das in Firmen angelernte Wissen zu vertiefen und zu erweitern. z.B. mal ein Blick auf Datenstrukturen werfen, um ein Gespür zu bekommen, welche wann geeigneter ist. Der Unterschied zwischen einer verketteten Liste und einer Arrayliste ist wohl offenbar nur sehr wenigen bekannt oder dass in Java und C# Arrays als assoziative Arrays missbraucht werden, indem man den gesuchten Index als Konstante ablegt. Anstatt sinnlose Amortisierungsrechnungen aufzustellen, sollte man vielleicht mit den Azubis DDD üben (z.B. die Schule als Kunde) oder mit Hilfe von Coding Dojos sauberen Code oder TDD in Verbindung mit Continuous Testing üben. Auch wäre ein Blick auf funktionale Programmiersprachen nicht verkehrt, weil diese Sprachen immer mehr in kommen sind. Nicht weil sie trendige Hipster verwenden, sondern weil einfach gewisse Probleme, die man aus der Objektorientierung kennt, dort nicht existieren und daher für viele Aufgaben besser geeignet sind, als objektorientierte Sprachen. TL;DR: Gerade die IT-Welt ist so extrem wandelbar. Da ist es einfach nicht klug, einen Ausbildungsrahmenplan bis in alle Ewigkeit in Stein zumeißeln. Auch die Berufsschule und die IHK müssen hier wandelbar sein und Trends erkennen. Kein Azubi hat etwas davon, drei Jahre irgendeinen Quatsch zu lernen, was Prüfungsrelevant ist aber später keine Anwendung mehr findet. Eine Berufsschule sollte dafür da sein, ein Azubi auf den Berufsalltag vorzubereiten nicht nur für die Prüfung. Sie ist dafür da, Defizite, die in den Ausbildungsstätten vorkommen können, aufzuarbeiten und den Azubis ein Blick über den Tellerrand zu ermöglichen.

Und wenn das nicht reicht, dann schreibt man halt einfach ein eigenes Kommandozeilen-Tool, was genau die Ergebnisse zurückliefert, die man braucht. dir und tree sind ja auch nichts anderes.

Warum nicht gleich im Designer festlegen? Dennoch ist das eine Frickelei und sollte auch so nicht umgesetzt werden. In ein WinForms-Projekt sollte keine Logik hinterlegt werden. Eigentlich sollte grundsätzlich in kein ausführbares Projekt Logik hinterlegt werden, weil es die Wiederverwendbarkeit erschwert.

Das ist nicht nur sinnvoller, sondern es sollte auch so gemacht werden: Walkthrough: Creating a Windows Service Application in the Component Designer

Das denke ich auch. Das Bundes-/Landesdatenschutzgesetz regelt die Erhebung und Verarbeitung von personenbezogenen Daten und nicht die Einrichtung der IT-Infrastruktur.

Auf Wikipedia stehen dafür gleich mehrere Ansätze. Sofern es keine Säulen im Labyrinth gibt und die Länge des Weges egal ist, gibt es einen einfachen Algorithmus: Immer nach Rechts gehen.

Das hat man von Bäckern mit Mehlallergie oder von Friseuren mit einer Ammoniak-Allergie, in den 90ern, auch behauptet. Und wo ist denn jetzt nun dein Problem? Was möchtest du von der Community? Sollen sie dir helfen oder nicht? Wenn sie dir helfen soll, dann muss man sich auch mal mit der Community beschäftigen und auch mal die Fragen beantworten aber irgendwie redest du nur um den heißen Brei herum anstatt mit konkreten Antworten zu kommen. z.B. warum du dich für die IT entschieden hast? Du machst eine Umschulung also hast du was davor gemacht aber wieso jetzt die IT? Hattest du schon vorher mit der Softwareentwicklung Kontakt? Wo hast du denn deine Schwierigkeiten? Wenn die Community dir aber nicht helfen soll, wieso hast du diesen Thread überhaupt eröffnet? Möchtest du nur Durchhalteparolen hören? Ob du jetzt die einzige bist, die Schwierigkeiten bei der Prüfung hatte oder nicht, ist auch vollkommen irrelevant, denn es geht um dich und nicht um die anderen! Anstatt also immer wieder Ausreden parat zu haben, um nicht die Fragen beantworten zu müssen, wäre es hilfreicher, wenn du mal konkrete Beispiele nennst, wo du Schwierigkeiten hast. Nur so kann man Defizite aus der Welt schaffen. Was bringt es dir, nächstes Jahr ein Plan zu machen? Was versprichst du dir dadurch? Was soll der Plan überhaupt aufzeigen?

Das wollte ich auch gerade fragen. Man macht ja nicht ohne Grund eine Umschulung zum Anwendungsentwickler.

Wenn man nicht direkt mit der Hardware kommuniziert: Gar nicht. Das ist wohl wieder dieses typische "Hauptsache irgendwas auswendig lernen, was irgendwas mit IT zu tun hat." Kann mir aber einer sagen, was LF4, etc. bedeutet?

C# hat in erster Linie nichts mit .Net zu tun. C# ist eine ECMA- und ISO-Standardisierte Sprache. .NET ist eine Entwicklungsplattform, die aus mehreren Komponenten besteht. z.B. WinForms, WPF, ASP.NET, ADO.NET, LINQ, Entity Framework, Common Language Runtime (CLR) etc. Die neue Compiler-Plattform Roslyn, von Microsoft, kompiliert den C# Code in CIL Code, der wiederrum von der CLR ausgeführt werden kann. Die CLR ist quasi so was ähnliches, wie die Java Virtual Machine. Als Alternative für .NET gibt es Mono und findet man überwiegend in der Linux-Welt, da die .NET-Welt ursprünglich nur auf Windows angesiedelt war. Inzwischen ist das .NET-Framework auch Open Source und mit .NET Core wird eine Plattformunabhängige Version entwickelt, die sowohl auf Windows, als auch auf Linux arbeitet. Der Grund, warum C# fast immer mit .NET in Verbindung gebracht wird, ist halt daher geschuldet, dass die C#-Entwicklung hauptsächlich in der Windows-Welt stattfindet und eben das .NET-Framework als Unterbau verwendet wird. Es kann aber jeder sein eigenen Unterbau bauen, wie es ja mit Mono gemacht wurde. C# kann man auch nicht mit C oder C++ vergleichen, da die Unterschiede sehr stark sind. Höchstens die Syntax kann man ein wenig miteinander vergleichen, da Microsoft sich an C/C++ orientiert hat. Objective-C ist eine Sprache von Apple, die sich aber sehr stark an der Sprache Smalltalk orientiert und sich ebenfalls von C# sehr unterscheidet. Objective-C wird hauptsächlich in der iOS-App-Entwicklung verwendet. Swift ist ebenfalls eine Programmiersprache von Apple und ist eine Alternative zu Objective-C. Die Bedeutung von Multithreading ist auch in allen Sprachen gleich. Objektorientierte Sprachen haben aber aufgrund ihrer Eigenschaft, viele Schwierigkeiten, Multithreading leicht umzusetzen. (Seiteneffekte, Deadlocks, etc.) Darum gewinnen funktionale Sprachen immer mehr an Bedeutung, da dort diese Schwierigkeiten gar nicht existieren, da jeder Wert immutable - d.h. unveränderbar - ist. Da gibt es keine Seiteneffekte. Nur, weil viele Sprachen ein C in einem Namen haben, heißt es noch lange nicht, dass es Untermengen von C sind. Es sind lediglich Sprachen, die Konzepte von C übernommen haben aber eigene Konzepte drumherumgebaut haben, die sich sehr stark voneinander unterscheiden.

Wobei man aber sagen muss, dass bei den heutigen Mehrkern-Prozessoren wirklich mehrere Dinge gleichzeitig abgearbeitet werden können. Multi-Threading muss auch nicht immer was mit Geschwindigkeit zu tun haben. Wenn du in C# einen Timer startest, dann läuft der Timer im einem separaten Thread, da ansonsten die gesamte Anwendung durch den Timer blockiert wäre, da der Timer eine Endlosschleife ist. Ein anderes Beispiel ist eine Statusanzeige. Hier läuft die Logik in einem separaten Thread als die Statusanzeige und die Logik füttert die Anzeige mit Statusinformationen, die dann angezeigt werden. Unter Android läuft sogar per Standard die komplette Benutzeroberfläche in einem separaten Thread, damit die Logik die Oberfläche nicht blockiert. Du kannst ja gerne mal ein Test machen: Erstelle eine neue WinForms-Anwendung, packe dort einen Button rauf und im Click-Event schreibst du private void button1_Click(object sender, EventArgs e) { while(true) { } } Nach dem klicken auf den Button kannst du dann das Fenster nicht mehr verschieben und auch nicht mehr mit dem Schließen-Button schließen, weil der Fokus nun auf der Endlosschleife liegt und die Oberfläche reagiert nicht mehr. Jetzt verschieben wir die Endlosschleife in einen separaten Thread: private void button1_Click(object sender, EventArgs e) { new Thread(Execute).Start(); } private void Execute() { while(true) {} } Und siehe da: Selbst nach dem Klick auf den Button, kann man die Oberfläche verschieben und mit dem Schließen-Button schließen. Die Endlosschleife läuft nun in einem anderen Thread und blockiert nicht mehr die Oberfläche.

Da die Datei nun gelöscht wurde, weiß ich nicht, was drinnensteht aber ich weiß, dass es ein Word-Dokument war. Falls du den Firmen auch ein Word-Dokument schicken solltest, dann schauen sich die Firmen die Bewerbung erst gar nicht an, sondern landet gleich direkt in die Ablage P.

Leider Nein. Das ist auch ein großes Problem bei uns. Die sog. Testpyramide steht bei uns auf dem Kopf. Sehe ich ähnlich. Kommentare können dennoch manchmal hilfreich sein aber sie sollten knapp sein. Es muss aber dennoch kommuniziert werden, dass Feature XYZ neu hinzugekommen ist. Das Beispiel mit der CSV-Bibliothek kommt nicht von irgendwo. Das Problem haben wir tatsächlich. Bei uns im Code schlummern mehrere Klassen, die generisch CSV-Dateien generiert und das alles nur, weil Entwickler A nicht mit Entwickler B spricht und Entwickler A nicht wusste, dass Entwickler B sowas schon mal gebaut hat (davon abgesehen, dass man per NuGet sowieso schon zig Bibilotheken holen könnte...)

Und genau das führt immer zum Chaos. Ich kenne es selber aus der Firma, wo ich arbeite. Es ist eine Qual nach Funktionalitäten zu suchen, weil es keine technische Dokumentation gibt. Also wird dann z.B. zum fünften Mal eine Bibliothek geschrieben, die eine CSV-Datei erzeugt. Ein kleiner Kommentar, der irgendwo angibt, dass Klasse X CSV-Dateien erstellt, hätte da nichts gebracht, weil man nicht weiß, wo sich Klasse X befindet. In unserem kleinen Team haben wir angefangen, eine technische Dokumentation zu schreiben und es klappt. Jeder weiß, wo er nach Informationen suchen kann, wenn er eine Funktionalität benötigt. Dokumentationen kann man sich auch aus den Kommentaren generieren lassen, wenn die Kommentare brauchbar sind. Dafür gibt es ja z.B. Sand Castle oder Doxygen.

Die Frage ist ja, wer sind die Teilnehmer? Der Kurs richtet sich ja an blutige Anfänger. Sie wissen es nicht besser und dann kommt einer, der Wirtschaftsingenieurswesen studiert hat und erzählt einem was vom Pferd. Ich glaube auch nicht, dass der Kurs sich noch großartig angepasst wird. Der Typ scheint enormes Vertrauen in sich zu haben, denn mit Selbstlob geizt er nicht. Im Neudeutsch würde ich sagen, dass er ganz schön auf die Kacke haut. Ich habe nichts gegen Vereinfachung. Ich erwarte ja nicht, dass er auf die Gefahren von Fließkommawerten eingeht und warum man diese nicht für Geldbeträge nutzen sollte (zumindest nicht double und float; dafür gibt es in C# decimal) aber allein schon in diesen einem Video merkt man, dass er oft keine Ahnung hat, wovon er da eigentlich redet. Dann wird seine Sprechweise unsicher. Er macht Pausen und versucht das Thema schnell mit einem Halbsatz zu beenden. Kommentare sind immer so eine Sache. Ich garantiere dir, dass auch mit Kommentare das Tamagochi-Projekt zum Chaos geworden wäre. Es liegt nicht immer an den fehlenden Kommentaren, sondern an der Dokumentation. Kommentare helfen nicht, wenn man nicht weiß, wo man suchen muss. Mit Kommentaren bin ich auch immer sehr sparsam. Ich mache sie nur dort, wo ich es für nötig halte. Triviale Getter- und Setter bekommen keine Kommentare. Auch die Kommentare für Methoden sollten meiner Meinung sehr sparsam sein. Maximal zwei bis drei Sätze. Kommentare für Methoden sollten auch nie den Algorithmus erklären, denn irgendwann kommt der Zeitpunkt, wo man den Algorithmus anpassen muss und dann vergisst man mit Sicherheit den Kommentar anzupassen und schon laufen Kommentar und Implementierung auseinander. Viel wichtiger als Kommentare ist die Kommunikation und die Dokumentation.

Eine Ergänzung: Außerdem fehlt Generics komplett. Ich habe mir mal das Video "Einführung in Datentypen und was du in diesem Kapitel lernst" angeschaut. Der erzählt viel Stuss. Man merkt, dass er nur Halbwissen verfügt. z.B. weiß er nicht, dass Variablen nur in einem Sichtbarkeitsbereich haben und er meint, dass Variablen so lange im Speicher bleiben, bis wir sie löschen. Das ist falsch. Variablen mit einem primitiven (integrierten) Wertetyp verlieren ihre Gültigkeit, wenn der Programmfluss ihre Sichtbarkeit verliert. Variablen mit Klasseninstanzen räumt der Garbage Collector weg, wenn der Programmfluss ihre Sichtbarkeit verliert. Auch behauptet er, ein Integer-Wert könnte man nicht mit einem double-Wert addieren. Das ist falsch. Natürlich geht das. Das Resultat ist dann ein double-Wert. Der Unterschied zwischen double und float ist für ihn auch nur die Speichergröße. Auf die Genauigkeit geht er gar nicht ein. Nee, der Kurs ist selbst für 20 € noch zu teuer. Der Originalpreis von 95 € ist Wucher.

Ich persönlich würde vom udemy-kurs die Finger von lassen. Ich habe noch nie einen Einleitungstext mit so vielen Zeichensetzungs- und Grammatikfehlern gesehen. Auch ist er Autor wohl von sich selbst sehr überzeugt, obwohl er nicht mal ein softwareeentwickler ist, sondern sich das wohl alles selbst beigebracht hat. Außerdem macht er falsche Versprechungen, da er behauptet, dass man nach seinem Kurs Spiele in Unity entwickelt könnte aber er geht gar nicht auf Unity ein. Nee, das klingt für mich doch ein wenig unseriös.

Der berühmte Taschenrechner... Nein, ich halte die Entwicklung eines Taschenrechners nicht sinnvoll für einen Anfänger, denn so trivial ist sowas gar nicht. Meist handeln solche Beispiele nur von pseudo-taschenrechnern, die nur kettenaufgaben lösen können. Also nichts, was man im Alltag gebrauchen könnte. Das hinterlässt ein unzufriedenes Gefühl. Wenn dann noch eine grafische Oberfläche ins Spiel kommt, wird es dann ganz schlimm. Dann wird die Oberfläche mit der Berechnungslogik vermischt und dann bringt man es den Anfänger absichtlich falsch bei. Um einen richtigen Taschenrechner bauen zu können, braucht man schon ein bisschen mehr Wissen und das hat ein Anfänger noch nicht.

Das kommt mir sehr wenig vor. In einer Windows-Domäne kann man die Signatur direkt im AD hinterlegen und Outlook holt sie automatisch. Ich finde ganze Tutorials, die einem erklären, wie man es umsetzt. Das sind weniger als 10 Schritte und die sind sogar recht simpel. Dafür braucht man vielleicht ein Tag und dann läuft es.

Natürlich gibt es auch hier Diskussionsspielraum, ansonsten dürften viele Betriebe gar nicht ausbilden. Als Beispiel nenne ich meine Mechatroniker-Ausbildung. Einige Schulkollegen aus meiner damaligen Berufsschulklasse hatten in Firmen eine Mechatroniker-Ausbildung gemacht, die gar nicht die Möglichkeiten hatten, den Ausbildungsrahmenplan vollumfänglich einzuhalten. So ist im Ausbilungsrahmenplan z.B. von "Installieren und Testen von Hard- und Softwarekomponenten" die Rede aber sowas gibt es in Firmen nicht, die z.B. Kettensägen mit Verbrennungsmotoren bauen. Solche Firmen haben dann Wartungsverträge mit IT-Firmen. Die Azubis dürfen dann nicht mal in die Nähe der Server.

Das ist jetzt eine persönliche Vorliebe von mir, aber ich würde empfehlen, mit der Sprache C# anzufangen. Die Community Editon von Visual Studio ist ja kostenlos erhältlich und bietet alles, was man eigentlich so braucht. Java wäre auch möglich aber ich halte die Entwicklungsumgebungen nicht ganz für anfängertauglich. Ich hab das Buch zwar nicht gelesen, aber das Inhaltsverzeichnis und die Leseprobe lesen sich ganz vielversprechend und daher würde ich folgendes Buch empfehlen: Schrödinger programmiert C# Mit 750 Seiten ist es schon ein großer Brocken aber dadrinnen befinden sich sehr viele farbige Bilder und recht wenig Text auf den Seiten. Das lockert vielleicht das Lesen ein wenig auf. Einige werden wohl die Sprache Python empfehlen, weil sie sehr anfängerfreundlich sein soll aber ich muss gestehen, dass ich mit dieser Sprache bis jetzt kaum etwas gemacht habe und auch keine Literatur dafür empfehlen kann. Bücher, wie Clean Code würde ich auch noch keinen Anfänger in die Hand drücken wollen. Das würde ich erst machen, wenn die Person auch schon gewisse Erfahrungen gesammelt hat, auf die man aufbauen kann.

Eben. Ich sehe da auch keine Probleme. Schlechter Code kommt doch nur dadurch zustande, weil man es nicht besser weiß. Probleme bestehen doch nur, wenn der Azubi beratungsresistent ist. Ich kenne es selber. In der Firma, wo ich arbeite, schule ich inzwischen Senior Entwickler, obwohl ich erst vor knapp 5 Jahren dort als Junior Entwickler angefangen habe. Wir haben dort auch ein paar Spezies, die weiterhin Spaghetticode schreiben, weil sie der Meinung sind, sie seien die besten Entwickler der Welt und lassen sich eh nichts von einem etwas sagen, der ca. 20 Jahre jünger ist, als sie selbst. Die meisten Entwickler nehmen aber die Tipps, die ich denen gebe, zu Herzen. Sicherlich, viele von denen waren auch erst skeptisch, weil sie den Begriff "SOLID" zum ersten Mal gehört haben (obwohl sie schon seit über 20 Jahren als Entwickler tätig sind) und fassten es als neumodischen Schnick-Schnack auf und waren der Meinung, dass unsere Anwendung eh viel zu kompliziert sei und die Prinzipien hier nicht greifen können aber als ich denen ein paar Beispiele gezeigt hatte, wie man unsere Anwendung hätte besser strukturieren können, war denen auch klar, dass sie ihren Programmierstil radikal ändern müssen und da klappt es auch. Sicherlich, sie fallen manchmal in alte Muster zurück aber das liegt auch daran, dass sie mit den Prinzipien noch nicht so ganz vertraut sind aber das wird einem blutigen Anfänger auch so ergehen.

Für dich gibt es also nur zwei Arten von Azubis: Jemand, der keine Ahnung hat, aber lernwillig ist Jemand, der Vorkenntnisse hat aber beratungsresistent ist Gutes Schubladendenken...  Ich sehe das also anders. Als Azubi muss man nicht alles kennen oder können, aber er sollte schon vor der Ausbildung wissen, auf was er sich dort einlässt. Ich habe es selbst bei meiner Assistentenausbildung gemerkt, dass viele mit falschen Vorstellungen die Ausbildung anfangen. Da sitzen echt ein Haufen Leute, die meinen, dass sie nach der Ausbildung Facebook, Apple oder Microsoft hacken können. Ein Kommilitone dachte, Objektorientierung sei sowas, was man sonst in Hollywood-Filmen sieht: Programmierung mit grafischen "Objekten", die man per Drag'n'Drop durch die Gegend schiebt. Ja, er dachte, sowas wie die Programmiersprache Scratch sei professionelle Softwareentwicklung. Er hatte bis Dato nicht mal eine Zeile Code geschrieben oder gesehen. Die meisten meiner damaligen Kommilitonen haben schon nach dem zweiten Semester das Handtuch geworfen. Wir waren ca. 80 Schüler und ganze 6 (ich war einer davon) haben später auch den Abschluss gemacht. Diejenigen, die den Abschluss gemacht hatten, hatten auch schon Vorkenntnisse. Der Rest hatte sich im Vorwege keine Gedanken drum gemacht, was es heißt, Software zu entwickeln. Sie wollten halt "irgendwas mit Computern" machen. Ich finde es schon wichtig, dass der Azubi weiß, was er will und dass Softwareentwicklung nicht heißt, dass man nur ein paar Klicks macht und schon wäre man der nächste Steve Jobs oder Bill Gates oder hätte das nächste Call of Duty entwickelt. Ich programmiere schon, seit ich 7 oder 8 Jahre alt war. Damals angefangen auf einem C64 und mir hat es auch nicht geschadet. Im Gegenteil. Vorkenntnisse können helfen, die Dinge besser zu verstehen. Mein Code sah vor der Ausbildung auch nicht besonders toll aus. Ich habe aber jeden Tipp und Hinweis von den Dozenten dankend angenommen und auch versucht, ihn sofort umzusetzen, während die anderen Kommilitonen mit den Tipps nichts anfangen konnten, weil sie noch mit ihren "if-Schleifen" beschäftigt waren und nach dem zweiten Semester immer noch Spaghetticode schrieben. Denen hat man auch schon geraten, die Ausbildung abzubrechen, weil sie mit dem Stoff nicht hinterherkommen würden. Darum unterstütze ich auch solche Projekte, wie z.B. Jugend Hackt. Dort haben Jugendliche die Möglichkeit, Tipps, Anregungen und Erfahrungen von Softwareentwicklern, Dozenten und auch von anderen Jugendlichen zu erhalten und da kommen teilweise sehr witzige Projekte bei raus. Sicherlich, der produzierte Code ist nicht erste Sahne und die Projekte sind auch nicht bis ins letzte Detail durchdacht aber das erwarte ich eigentlich auch an einem Wochenende nicht. Vielmehr haben die Projekte den Charakter eines Prototypen aber who cares? Die Jugendlichen hatten Spaß und konnten dabei auch was lernen.

Viele Firmen unterziehen sich derzeit einen Wandel, da sie gemerkt haben, dass sie mit ihren alten Firmenkulturen nicht mehr weiterkommen. Gehe mal auf Konferenzen oder oder besuche mal User groups (z.B. auf meetup) und unterhalte dich mal dort mit den Entwicklern. Entweder hast du Entwickler, die auf ein ganzes Arsenal an Technologien setzen oder Entwickler, die noch einen Monolithen mit Legacy Code schreiben aber davon weg wollen. Die klassischen Desktop-Anwendungen geraten auch immer mehr in den Hintergrund. Selbst bei der klassischen Webentwicklung mit PHP bröckelt es gerade, da sog. Single-Page-Applikationen immer mehr in den Vordergrund rutschen. Darum wird verstärkt nach Entwicklern gesucht, die eben halt schon einen gewissen Wissensstand haben. Man darf auch nicht vergessen, dass frische Studiumabsolventen sich ebenfalls auf die Junior Entwickler-Stellen bewerben und darum halte ich die Chancen für nicht allzu hoch, dass ein FISI ein Job als Junior Entwickler findet. In den Stellenangeboten steht zwar häufig "Sie haben ein Studium der Informatik oder eines vergleichbaren Studiengangs bzw. eine IT-Ausbildung absolviert." aber ein Studiumabsolvent mit Kenntnissen in der Entwicklung wird wohl eher genommen, als jemand bei dem man quasi von Null anfangen müsste. Wie gesagt, ich habe schon einige Firmen gesehen, wo man beim Vorstellungsgespräch dem Chef der Entwicklungsabteilung gegenübersitzt und dann erst mal technische Fragen beantworten muss und ich hatte mich damals auch nur als Junior-Entwickler beworben. Er kann sich ja ruhig darauf bewerben und ich wünsche ihm auch viel Glück aber große Chancen sehe ich halt nicht. Es wird zwar immer gejammert, dass die Firmen keine Leute finden aber offenbar können die Firmen es sich leisten zu warten, bis sich mal der richtige bewirbt.