Whiz-zarD

Ich arbeite überwiegend mit Entwicklern, die so auf die 50 zugehen und da muss ich feststellen, dass viele doch ihren Antrieb verloren haben (wenn sie ihn jemals besessen haben) und sich auch gar nicht mehr weiterbilden wollen und lieber nur noch das machen wollen, was sie kennen. Da sind dann Spezialisten bei, die meinen, sie seien Schlauer als Microsoft und Oracle und bauen Datenbank-Features nach und verteufeln das yield return in C#, weil der Compiler zusätzlichen IL-Code drumherum baut und Microservices sind ja per Se schlecht, weil ist so aber produzieren fleißig Spaghetticode und von agilen Prozessen braucht man erst gar nicht reden, weil das ja nur Chaos bedeutet. Da bleibt man ja lieber beim Wasserfallmodell und fällt jedes Mal wieder auf die Fresse. Es sind gerade unsere Werksstudenten, die die Nerdigkeit in das Unternehmen bringen. Klar, entsprechen sie nicht mehr dem Klischee eines typischen Nerds. Einer baut in Fitnessstudio seine Muskeln auf und ein anderer läuft Marathons aber das ist nun mal der Wandel der Zeit und ich würde sagen, dass die heutigen Nerds doch aktiver sind, was ihre Freizeitgestaltung angeht und der typische Klischee-Nerd (im dunklen Keller hocken und D&D zocken) verdrängt wird.

Ich arbeite überwiegend mit Entwicklern, die so auf die 50 zugehen und da muss ich feststellen, dass viele doch ihren Antrieb verloren haben (wenn sie ihn jemals besessen haben) und sich auch gar nicht mehr weiterbilden wollen und lieber nur noch das machen wollen, was sie kennen. Da sind dann Spezialisten bei, die meinen, sie seien Schlauer als Microsoft und Oracle und bauen Datenbank-Features nach und verteufeln das yield return in C#, weil der Compiler zusätzlichen IL-Code drumherum baut und Microservices sind ja per Se schlecht, weil ist so aber produzieren fleißig Spaghetticode und von agilen Prozessen braucht man erst gar nicht reden, weil das ja nur Chaos bedeutet. Da bleibt man ja lieber beim Wasserfallmodell und fällt jedes Mal wieder auf die Fresse. Es sind gerade unsere Werksstudenten, die die Nerdigkeit in das Unternehmen bringen. Klar, entsprechen sie nicht mehr dem Klischee eines typischen Nerds. Einer baut in Fitnessstudio seine Muskeln auf und ein anderer läuft Marathons aber das ist nun mal der Wandel der Zeit und ich würde sagen, dass die heutigen Nerds doch aktiver sind, was ihre Freizeitgestaltung angeht und der typische Klischee-Nerd (im dunklen Keller hocken und D&D zocken) verdrängt wird.

Aus diesem Grund finde ich es nicht gerade sinnvoll, dass Anfänger gleich mit einer grafischen Oberfläche anfangen, denn das Wissen ist einfach nicht vorhanden, wie Events eigentlich funktionieren.
Eine grafische Oberfläche läuft in einer Endlosschleife. In der Schleife werden jedes Mal die Eingabe entgegengenommen, verarbeitet und die Oberfläche neu gezeichnet. Ein Mausklick löst also im Grunde nicht das Event aus, sondern die Schleife befindet sich wieder an dem Punkt, wo sie die Eingabe überprüft wird und merkt, dass die Maustaste gedrückt wird. Schaut dann nach, ob ein Event implementiert wurde und wenn ja, dann wird die Implementierung aufgerufen. 
So ist es nun auch beim FileSystemWatcher. Es läuft eine Endlosschleife, die sich ein Stream mit Dateiänderungen anschaut und bei jedem Durchlauf wird geschaut, ob die letzte Dateiänderung mit deinen Filterkriterien, etc. übereinstimmt und dann schaut, ob das jeweilige Event implementiert wurde.
Den FileSystemWatcher kannst du auch in einer Form verwenden. Beispiel:
public Form1() { InitializeComponent(); FileSystemWatcher watcher = new FileSystemWatcher(@"D:\Test"); watcher.Changed += (sender, e) => textBox1.Text = $"Changed: {e.Name}"; watcher.Created += (sender, e) => textBox1.Text = $"Created: {e.Name}"; watcher.Deleted += (sender, e) => textBox1.Text = $"Deleted: {e.Name}"; watcher.Renamed += (sender, e) => textBox1.Text = $"Renamed: {e.OldName} => {e.Name}"; watcher.SynchronizingObject = this; watcher.EnableRaisingEvents = true; } Hierbei muss man aber wissen, dass die Endlosschleife in einem anderen Thread läuft als die Endlosschleife der grafischen Oberfläche und Änderungen an der UI darf nur der Thread der UI machen. Der FileSystemWatcher besitzt deswegen die Eigenschaft SynchronizingObject. Hier kann man das Objekt reinreichen, wer den FileSystemWatcher erzeugt hat und somit wird der Code über den UI-Thread ausgeführt.
Der FileSystemWatcher steht sogar in der Toolbox zur Verfügung und kann per Drag'n'Drop in die Form geschoben werden. Dabei wird der FilesystemWatcher folgendermaßen initialisiert:
// // fileSystemWatcher1 // this.fileSystemWatcher1.EnableRaisingEvents = true; this.fileSystemWatcher1.SynchronizingObject = this; this.fileSystemWatcher1.Changed += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Changed); this.fileSystemWatcher1.Created += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Created); this.fileSystemWatcher1.Deleted += new System.IO.FileSystemEventHandler(this.fileSystemWatcher1_Deleted); this.fileSystemWatcher1.Renamed += new System.IO.RenamedEventHandler(this.fileSystemWatcher1_Renamed); Das, was ich im oberen Code gemacht habe, kann man sich auch generieren lassen.

Einen Timer brauchst du nicht. Der FileSystemWatcher besitzt Events, die implementiert werden können, um auf Änderungen in einem Ordner zu reagieren. Mal ein simples Beispiel einer Konsolenanwendung:
class Program { private FileSystemWatcher watcher; public Program() { this.watcher = new FileSystemWatcher(@"D:\Test"); this.watcher.Changed += (sender, e) => Console.WriteLine($"Changed: {e.Name}"); this.watcher.Created += (sender, e) => Console.WriteLine($"Created: {e.Name}"); this.watcher.Deleted += (sender, e) => Console.WriteLine($"Deleted: {e.Name}"); this.watcher.Renamed += (sender, e) => Console.WriteLine($"Renamed: {e.OldName} => {e.Name}"); this.watcher.EnableRaisingEvents = true; } static void Main(string[] args) { Program program = new Program(); Console.ReadKey(); } } Nun werden alle Änderungen im Ornder D:\Test angezeigt

Ich glaube, es wird echt mal Zeit, dass ich mein Artikel "Wie man einen Taschenrechner programmiert" veröffentliche.
Du meinst wohl die (umgekehrte) polnische Notation. Genannt auch Postfix- und Präfix-Schreibweise.
Eine Umwandlung von der bekannten Infix-Schreibweise in die Post-/Präfix-Schreibweise, lässt sich durch den Shunting-Yard-Algorithmus lösen. Das würde hier aber viel zu weit gehen.

Genau

Es geht um das DRY-Prinzip (Don't Repeat yourself). Wenn du nicht nur die Addition implementieren willst, sondern auch noch weitere Rechenoperationen, dann brauchen sie ebenfalls left und right. Damit man beide Variablen nicht für jede Operation kopieren muss, habe ich sie in eine abstrakte Klasse ausgelagert und jede Operation erbt von dieser Klasse. So braucht man die beiden Variablen nur ein mal definieren.
Abstrakte Klassen sind nicht instanziierbar. Du kannst also kein
new BinaryCalculation() aufrufen. Das führt sofort zu ein Kompilierfehler. Abstrakte Klassen dienen für eine Basisimplementierung einer Funktionalität. Klassen, die dann von der abstrakten Klasse erben, implementieren dann die konkrete Fachlogik. Die Subtraction-Klasse wird dann einfach so aussehen:
Public Class Subtraction Inherits BinaryCalculation Public Sub New(left As Double, right As Double) MyBase.New(left, right) End Sub Public Overrides Function Calculate() As Double Return Me.left - Me.right End Function End Class left und right braucht man ja nicht noch mal definieren, weil sie eben schon in BinaryCalculation definiert worden sind.
 

Genau, die Methode macht einfach zu viel. Außerdem ist es sie schwieriger zu testen, da die Funktion nun eine sog. zyklomatische Komplexität von 5 hat. Das bedeutet, dass deine Funktion fünf Pfade hat, die durchlaufen werden können. Wenn du jetzt Unittests schreiben würdest, müsstest du mindestens 5 Tests schreiben, nur um diese eine Funktion zu testen. Du merkst auch vielleicht selber, dass du mit Return 0 ein Hilfskonstrukt bauen musstest, damit die Funktion funktionieren kann. Also zusätzliche Komplexität, die beim Lesen nur stört. Desweiteren verstößt diese Art von Porgrammierung gegen das sog. OpenClosed-Prinzip, da wir bei weiterer Funktionalität die Funktion modifizieren müssen.  Angenommen, wir wollen auch noch Modulo-Operator implementieren. Dafür müssen wir dann die Funktion modifizieren. In meiner Variante muss nur eine neue Klasse angelegt werden. Das verhindert, dass der Entwickler, bei der Modifikation, Fehler einbaut, sodass andere Operationen plötzlich nicht mehr funktionieren. Da wir den Code nämlich nicht modifizieren, funktioniert alles so wie gehabt.
Darüberhinaus ist der Funktionsaufruf nun auch noch schwerer zu lesen. Du verstehst vielleicht noch, was die 1 bedeutet aber jemand anderes weiß es nicht und ist entweder auf deine Dokumentation oder auf den Code angewiesen, um nachzuschauen. Sicherlich, die 1 könnte man auch noch gegen ein Enum austauschen, um es sprechender zu machen aber nicht desto trotz hast du die o.g. Probleme. Du musst nämlich eines bedenken: Ein Entwickler liest 80% seiner Tageszeit Code und in den restlichen 20% schreibt er Code und da sollte der Code so verständlich und einfach wie möglich sein.
Das ist zwar schon alles auf einen höheren Niveau, was ich hier erzähle aber ich weiß noch, wie ich angefangen habe, zu entwickeln und für mich wären diese Informationen damals echt Goldwert gewesen. Wenn du es am Anfang nicht verstehst, ist es auch in Ordnung. Softwareentwicklung ist nun mal eine Gratwanderung und in jeder Situation muss man neu abschätzen, welcher Weg am sinnvollsten ist. Es kommt sogar sehr häufig vor, dass man sich verzettelt und sein Plan über den Haufen schmeißen muss, weil eine Situation kommt, an die man nicht gedacht hat.
 
btw. die ganzen Prinzipien, die ich genannt habe, sind unter dem Begriff SOLID-Prinzipien zusammengefasst. SOLID steht für:
Single-Responsibility-Prinzip Open-Closed-Prinzip Liskovsches Substitutionsprinzip Interface-Segregation-Prinzip Dependency-Inversion-Prinzip

Ich vermute mal, dass jeder Tag zwischen den beiden Daten ausgewiesen werden soll. Also:
ID Datum Von Bis 1 01.01.2000 01.01.2000 10.01.2000 1 02.01.2000 01.01.2000 10.01.2000 1 03.01.2000 01.01.2000 10.01.2000 1 04.01.2000 01.01.2000 10.01.2000 1 05.01.2000 01.01.2000 10.01.2000 1 06.01.2000 01.01.2000 10.01.2000 1 07.01.2000 01.01.2000 10.01.2000 1 08.01.2000 01.01.2000 10.01.2000 1 09.01.2000 01.01.2000 10.01.2000 1 10.01.2000 01.01.2000 10.01.2000 Sowas ist mit reinem SQL nicht möglich, da SQL auf der Menge arbeitet, die in der Datenbank stehen. Du willst hier aber neue Zeilen dazudichten. Sowas würde höchstens mit einer Stored Procedure gehen. Ich kenne mich aber mit MS SQL nicht wirklich gut aus und weiß auch nicht, was man dort für Stored Procedure bauen könnte. Mit Oracles PL/SQL wäre es möglich.

Deine Prozedur ShowErgebnis() ist schon mal nicht richtig. Es muss eine Funktion sein, die eben zahl1 und zahl2 addiert und das Ergebnis zurückgibt.
Dann kannst du in der Prozedur Button3_Click() einfach das Ergebnis einer TextBox zuweisen.
Public Class Addiere Public Property Zahl1 As Integer Public Property Zahl2 As Integer Function Berechne() As Integer Return Zahl1 + Zahl2 End Function End Class Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click Dim add As New Addiere add.Zahl1 = 5 add.Zahl2 = 3 TextBox1.Text = add.Berechne() End Sub Deine Addieren-Klasse sollte nicht dafür zuständig sein, das Ergebnis in die Textbox zu schreiben. Sie sollte nur das Ergebnis zurückliefern und die Anzeige in der Textbox sollte die Klasse übernehmen, die es auch braucht. Ansonsten ist deine Addieren-Klasse abhängig von der TextBox und die Klassen sollten so unabhängig wie möglich sein.

Performance ist nicht das Problem. Über Performance würde ich mich erst Gedanken machen, wenn es wirklich ein Problem mit dieser gibt. Performanceoptimierung heißt in den meisten Fällen, dass der Code unübersichtlicher wird.
Wie man den Code nun übersichtlicher macht, ist ein recht großes Thema und lässt sich auch nicht mit einfachen Worten erklären. Wenn du 10 Entwickler an die Aufgabe lässt, wirst du 11 Lösungen bekommen.
In der Objektorientierung hat sich aber das sog. SOLID-Prinzip bewährt. Das S steht für "Single-Responsibility-Principle", das besagt, dass eine Methode oder eine Klasse nur für eine Sache zuständig sein soll. Wenn man jetzt deine button1_Click()-Methode anschaut, dann sie quasi für alles zuständig ist. Also sie würfelt, analysiert und macht die Ausgabe. Ich weiß es, weil ich die Aufgabe kenne und auch deine Gedanken dahinter verstanden habe aber kann ein anderer erkennen, dass der folgende Code ein Würfel sein soll?
Random Zufall = new Random(); [...] int Zahl = Zufall.Next(1, 7); Nicht so wirklich, oder? Er sieht nur, dass du dort Zufallszahlen zwischen 1 und 6 generierst aber das es ein Würfel sein soll, lässt sich in diesem Kontext nicht herauslesen. Also würde ich im ersten Schritt genau daraus einen Würfel bauen. Also wir erstellen eine Klasse, die einen Würfel repräsentiert. Diese Klasse hat dann eine Roll()-Methode, die dann uns eine Zufallszahl zurückgibt. Das Endergebnis würde dann so aussehen:
int number = dice.Roll(); So lässt sich dann auch im Kontext lesen, dass wir es mit einem Würfel zu tun haben, der gewürfelt wird.
Analog das selbe gilt auch fürs Analysieren. Da würde ich auch eine Klasse bauen, die genau das übernimmt. Da könnte es dann z.B. eine Analyse()-Methode geben, die als Parameter die Nummer entgegennimmt und sie entsprechend eingruppiert. Eine GetCount()-Methode könnte dann die Anzahl zurückliefern:
int number = dice.Roll(); analyser.Analyse(number); [...] label3.Text = "Es wurde " + analyser.GetCountOfNumber(1) + " mal die Eins gewürfelt"; Natürlich könnte man noch viel mehr erzählen. z.B. über MVC (Model-View-Controller), etc aber ich denke, das würde zu weit führen. Ich denke, dass selbst mein Text schon zu weit geht.
Zum Thema String vs. StringBuilder vs. Stringinterpolation:
Ich denke mal, der TE kann mit dem Wort "immutable" nichts anfangen. Ich bin mir nicht mal sicher, ob der TE überhaupt eine Ausbildung macht oder nur ein Schüler auf einer allgemeinbildende Schule ist. Daher sollte man ihn vielleicht auch mal erklären, was immutable heißt. Zumal es performancetechnisch wohl keinen allzu großen Unterschied macht, ob er die Strings verkettet und somit einen neuen erzeugt oder einen StringBuilder verwendet. Wenn er einen eigenen StringBuilder verwendet, dann muss jedes Mal die Clear()-Methode aufgerufen werden, was den Code zumüllen würde. Darüber hinaus müsste er jedes String-Fragment mit der Append()-Methode zusammenführen, was schlecht lesbar ist.
Daher würde ich hier auf den StringBuilder verzichten und die Stringinterpolation verwenden. Diese verwendet intern auch nur die string.Format()-Methode und in dieser Methode wird ein gecachter StringBuilder verwendet, der eben die Clear()-Methode aufruft.
Ob man jetzt also
"Es wurde " + Eins + " mal die Eins gewürfelt"; oder
$"Es wurde { Eins } mal die Eins gewürfelt"; ist aus meiner Sicht erst mal irrelevant. Da es sich hier um eine Mikrooptimierung des Code handelt. Dann läuft der Code halt 10 Nanosekunden langsamer. Na und? Wir reden hier nicht von einem Hochverfügbarkeitssystem, was die Zahlen in Echtzeit anzeigen soll.
Ja, man kann die Problematik ansprechen aber geht es nicht erst mal darum, den Code lesbarer zu machen? Im Idealfall liest sich der Code wie ein Buch und da sollte die Reise hingehen und nicht welche Mikrooptimierung man nun unbedingt einbauen muss.

Mh alles scheiße irgendwie

Wer sagt, dass ich auf Gehalt verzichte?
Schon wieder Gehalt...
Nenn mich altmodisch aber ich bin kein Freund von Home Office. Erst mal aus persönlicher Sicht, da ich mich zu Hause nicht so recht auf die Arbeit konzentrieren kann und dann sind auch die Kommunikationswege umständlicher. z.B. ist Pair-Programming oder Code Reviews schlechter realisierbar. Bei uns kommen auch spontane Meetings recht häufig vor, wo wir uns dann vor einem Whiteboard versammeln und uns eine Lösung überlegen. Die Digitalisierung macht nun mal nicht alles besser.
Ich hab Arbeitskollegen, die arbeiten drei mal die Woche von zu Hause. Das ist alles kein Ding. Ich fahre aber lieber ins Büro aber es ist gut zu wissen, dass ich auch mal von zu Hause arbeiten kann, wenn es nicht anders geht und das ohne Verzicht auf Gehalt...

Ein binärer Baum ist nur eine Sonderstruktur eines Baumes. Ein binärer Baum hat nur zwei Knoten pro Wurzel. Ein Baum hingegen kann viele haben. Somit ist ein binärer Baum für eine XML-Struktur nicht geeignet und ob man das jetzt DOM (Document Object Model) oder Baum nennt, ist erst mal irrelevant, da ein DOM auch nichts weiter als ein Baum ist.
https://de.wikipedia.org/wiki/Document_Object_Model

Ich bin da etwas anderer Meinung. Ja, eine Ausbildung ist dazu da, jemanden auszubilden. Das steht außer Frage aber ich denke schon, dass das Reinschnuppern in die Tätigkeiten eines Entwicklers nicht falsch ist, um ein besseres Bild vom Beruf zu bekommen. Ich kenne inzwischen sehr viele Leute, die zwar "voll bock" auf Programmieren hatten aber nach kurzer Zeit doch gemerkt haben, dass es nichts für sie ist, weil sie komplett falsche Vorstellungen hatten. Ja, dafür ist zwar auch die Probezeit gedacht aber ich finde, es ist dann schon vergeudete lebensmühe, Bewerbungen zu schreiben, Vorstellungsgespräche zu führen, dann einen Ausbildungsplatz annehmen und erst dann zu merken, dass der Beruf für einen nichts ist. Dann doch lieber einen, der schon mal ein bisschen Erfahrungen gesammelt hat und weiß, worauf er sich einlässt. 
Ob man jetzt stur seinen wirren Code schreibt, nur weil man anfänglich schon programmiert hat, hängt von jeder Person selber ab, ob er die Ratschläge aus der Ausbildung annimmt oder nicht. Ich kenne welche, die hatten vor ihrer Ausbildung keine Berührungspunkte zur Softwareentwicklung und schreiben selbst Jahre nach ihrer Ausbildung immer noch Spaghetticode. Diese Personen haben die selbe Assistentenausbildung absolviert, wie ich und die Ausbildung ist schon nicht schlecht. Die Schule genießt vor allem in Norddeutschland einen sehr guten Ruf. Ich für meinen Teil programmiere schon seit ich 8 Jahre alt bin und habe die Ratschläge in der Ausbildung dankend angenommen und leite hier in der Firma eine Clean Code-Initiative. Man kann also nicht pauschal sagen, nur weil man schon vorher Dinge entwickelt hat, sei man für die Ausbildung als FIAEler ungeeignet.

Wenn du die Anteile 0, 25, 50, 75 und 100 mit in der Dropdownmenü haben willst, dann musst du diese in die DataTable packen und nicht direkt ins Dropdownmenü.
Ich bin zwar jetzt nun auch kein WebForms-Experte aber um den konkreten Wert anzuzeigen, anstatt "System.Data.DataRowView" reicht es evtl. schon die Eigenschaft DataTextField und DataValueField (damit der konkrete Wert ausgewählt wird) zu setzen. Also:
ddl.DataTextField = "anteil"; ddl.DataValueField = "anteil"; Ansonsten weiß er nicht, was er anzeigen soll und führt einfach auf dem Objekt die ToString()-Methode aus, was eben genau zu deinem Effekt führt.

Ich bin da etwas anderer Meinung. Ja, eine Ausbildung ist dazu da, jemanden auszubilden. Das steht außer Frage aber ich denke schon, dass das Reinschnuppern in die Tätigkeiten eines Entwicklers nicht falsch ist, um ein besseres Bild vom Beruf zu bekommen. Ich kenne inzwischen sehr viele Leute, die zwar "voll bock" auf Programmieren hatten aber nach kurzer Zeit doch gemerkt haben, dass es nichts für sie ist, weil sie komplett falsche Vorstellungen hatten. Ja, dafür ist zwar auch die Probezeit gedacht aber ich finde, es ist dann schon vergeudete lebensmühe, Bewerbungen zu schreiben, Vorstellungsgespräche zu führen, dann einen Ausbildungsplatz annehmen und erst dann zu merken, dass der Beruf für einen nichts ist. Dann doch lieber einen, der schon mal ein bisschen Erfahrungen gesammelt hat und weiß, worauf er sich einlässt. 
Ob man jetzt stur seinen wirren Code schreibt, nur weil man anfänglich schon programmiert hat, hängt von jeder Person selber ab, ob er die Ratschläge aus der Ausbildung annimmt oder nicht. Ich kenne welche, die hatten vor ihrer Ausbildung keine Berührungspunkte zur Softwareentwicklung und schreiben selbst Jahre nach ihrer Ausbildung immer noch Spaghetticode. Diese Personen haben die selbe Assistentenausbildung absolviert, wie ich und die Ausbildung ist schon nicht schlecht. Die Schule genießt vor allem in Norddeutschland einen sehr guten Ruf. Ich für meinen Teil programmiere schon seit ich 8 Jahre alt bin und habe die Ratschläge in der Ausbildung dankend angenommen und leite hier in der Firma eine Clean Code-Initiative. Man kann also nicht pauschal sagen, nur weil man schon vorher Dinge entwickelt hat, sei man für die Ausbildung als FIAEler ungeeignet.

Ich bin da etwas anderer Meinung. Ja, eine Ausbildung ist dazu da, jemanden auszubilden. Das steht außer Frage aber ich denke schon, dass das Reinschnuppern in die Tätigkeiten eines Entwicklers nicht falsch ist, um ein besseres Bild vom Beruf zu bekommen. Ich kenne inzwischen sehr viele Leute, die zwar "voll bock" auf Programmieren hatten aber nach kurzer Zeit doch gemerkt haben, dass es nichts für sie ist, weil sie komplett falsche Vorstellungen hatten. Ja, dafür ist zwar auch die Probezeit gedacht aber ich finde, es ist dann schon vergeudete lebensmühe, Bewerbungen zu schreiben, Vorstellungsgespräche zu führen, dann einen Ausbildungsplatz annehmen und erst dann zu merken, dass der Beruf für einen nichts ist. Dann doch lieber einen, der schon mal ein bisschen Erfahrungen gesammelt hat und weiß, worauf er sich einlässt. 
Ob man jetzt stur seinen wirren Code schreibt, nur weil man anfänglich schon programmiert hat, hängt von jeder Person selber ab, ob er die Ratschläge aus der Ausbildung annimmt oder nicht. Ich kenne welche, die hatten vor ihrer Ausbildung keine Berührungspunkte zur Softwareentwicklung und schreiben selbst Jahre nach ihrer Ausbildung immer noch Spaghetticode. Diese Personen haben die selbe Assistentenausbildung absolviert, wie ich und die Ausbildung ist schon nicht schlecht. Die Schule genießt vor allem in Norddeutschland einen sehr guten Ruf. Ich für meinen Teil programmiere schon seit ich 8 Jahre alt bin und habe die Ratschläge in der Ausbildung dankend angenommen und leite hier in der Firma eine Clean Code-Initiative. Man kann also nicht pauschal sagen, nur weil man schon vorher Dinge entwickelt hat, sei man für die Ausbildung als FIAEler ungeeignet.

Das ändert dennoch nichts an der Tatsache, dass du es hier mit einem DropDownMenü zu tun hast. Ob da rum nun ein DataGrid ist oder nicht, ist doch völlig wurscht. Fakt ist, du willst den Anteil anzeigen, der in der Datenbank gespeichert ist und zusätzlich die verfügbaren Optionen. 

Was für ein Quatsch...
Wie soll man da auch großartig helfen können? Wir kennen diese Person nicht persönlich und auch nicht seine Neigungen. Auch für Freunde und Familie wird es schwer, die Frage zu beantworten. Das muss er wohl oder übel selbst mit sich ausmachen, was für ihn besser geeignet wäre.
Das einzige, was ich empfehlen könnte, wäre ein Praktikum zu absolvieren. z.B. als Softwareentwickler, um mal zu sehen, ob das Thema überhaupt einen schmeckt. In meiner Ausbildung hatte ich auch viele Kommilitonen, die sich anfänglich für die Softwareentwicklung interessiert haben aber später doch die Ausbildung abbrachen, weil es doch schwieriger war, als sie dachten.

Was für ein Quatsch...
Wie soll man da auch großartig helfen können? Wir kennen diese Person nicht persönlich und auch nicht seine Neigungen. Auch für Freunde und Familie wird es schwer, die Frage zu beantworten. Das muss er wohl oder übel selbst mit sich ausmachen, was für ihn besser geeignet wäre.
Das einzige, was ich empfehlen könnte, wäre ein Praktikum zu absolvieren. z.B. als Softwareentwickler, um mal zu sehen, ob das Thema überhaupt einen schmeckt. In meiner Ausbildung hatte ich auch viele Kommilitonen, die sich anfänglich für die Softwareentwicklung interessiert haben aber später doch die Ausbildung abbrachen, weil es doch schwieriger war, als sie dachten.

Was für ein Quatsch...
Wie soll man da auch großartig helfen können? Wir kennen diese Person nicht persönlich und auch nicht seine Neigungen. Auch für Freunde und Familie wird es schwer, die Frage zu beantworten. Das muss er wohl oder übel selbst mit sich ausmachen, was für ihn besser geeignet wäre.
Das einzige, was ich empfehlen könnte, wäre ein Praktikum zu absolvieren. z.B. als Softwareentwickler, um mal zu sehen, ob das Thema überhaupt einen schmeckt. In meiner Ausbildung hatte ich auch viele Kommilitonen, die sich anfänglich für die Softwareentwicklung interessiert haben aber später doch die Ausbildung abbrachen, weil es doch schwieriger war, als sie dachten.

Dann könnte man sich auch überlegen, die Spiellogik in eigene Klassen auszulagern, anstatt sie in eine Form zu schreiben, damit das Spiel von der grafischen Oberfläche unabhängig wird.

Im Berufsleben kommt es eher später darauf an, welche Referenzen man vorzuweisen hat. Wenn ein FISI später hauptsächlich Entwicklertätigkeiten übernahm, hat man auch Chancen, als Entwickler irgendwo eingestellt zu werden. Es bringt also nichts, wenn du den AEler hinten ranhängst und dann doch nur Server administrierst. Man sollte aber auch nicht denken, nur weil man FIAEler ist, dass man sich plötzlich auf alle Entwicklerstellenangebote bewerben kann, denn auch hier kommt es auf die Referenzen an. Jemand, der z.B.  hauptsächlich mit C# oder Java entwickelt, wird wohl kaum ein Job als COBOL-Entwickler finden. Das betrifft allerdings nicht nur die Sprachen, sondern auch die Technologien, die man im Laufe seiner Berufszeit verwendet hat. Jemand der z.B. zwar mit C# entwickelt aber noch nie was mit WPF zu tun hatte, wird es schwierig haben, einen Job zu finden, wo WPF gefragt ist. 
Das ist nicht richtig. Es bringt dir keiner bei, wie man richtig programmiert. Richtiges Programmieren lernt man nicht aus Büchern, sondern nur durch Übung, Übung und noch mehr Übung. Bücher und Co. geben einem nur Hinweise, was man besser machen könnte aber die berühmte Silberkugel wird und kann dir keiner präsentieren. Oder meint jemand, der das Buch "Clean Code" von Robert C. Martin durchgelesen hat, plötzlich ein super Entwickler zu sein, der zu 100% die SOLID-Prinzipien einhalten kann? Tutorials geben oft nur Lösungen für einfache Beispiele und selbst da gibt es mal gute und mal schlechte Lösungen. 

Partielle Klassen verwende ich so gut wie gar nicht, weil sie nur in sehr wenigen Situationen wirklich Sinn machen. Partielle Klassen wurden in C# auch nur wegen WinForms eingeführt, damit man den automatisch generierten Code vom selbstgeschriebenen Code kapseln kann. Früher war der generierte Code mit dem selbstgeschrieben Code in einer Datei, was sehr unübersichtlich wurde, weil der generierte Code für die WinForms-Applikation sehr lang werden konnte.
Ich kenne dein Code jetzt nicht aber in der Regel entwickelt man Interfaces, die dann die Klassen implementieren und die Klassen werden dann per Inversion of Control bzw. Dependency Injection zusammengefügt. Also die Abhängigkeiten einer Klasse werden vom Erzeuger reingereicht. So könnte man z.B. ein Interface für die Sounds definieren:
public interface ISound { void Play(); } public class PlayerSound : ISound { public void Play() { \\ Spiele Sound } } Per Inversion of Control wird dies jetzt mit dem Player verbunden:
public class Player { public ISound Sound { get; private set; } public Player(ISound sound) { this.Sound = sound; } } Man sieht hier also, um eine Instanz von der Player-Klasse zu erzeugen, brauchen wir auch eine Instanz, die das ISound-Interface implementiert.
Zum Erzeugen der Player-Klasse müssen wir dann folgendes aufrufen:
var player = new Player(new PlayerSound()); Auf diese Weise ist die Player-Klasse nicht  mehr hart mit den Sounds verdrahtet und können die Sounds einfach austauschen. Beispiel:
public class PlayerASound : ISound { public void Play() { \\ Spiele "Uff" } } public class PlayerBSound : ISound { public void Play() { \\ Spiele "Ahh" } } var spielerA = new Player(new PlayerASound()); var spielerB = new Player(new PlayerBSound()); // ... spielerA.Sound.Play(); // Spielt "Uff" spielerB.Sound.Play(); // Spielt "Ahh"