Ich sehe häufig, dass ein komplexes LINQ-Statement in eine Zeile gequetscht wird, where-distinct-select-groupby-any. Auf den ersten Blick ein Einzeiler, der ja einfach zu verstehen sein müßte. Hier wären manchmal zwei oder drei Zeilen besser, weil der Gedankengang dann einfacher zu verstehen ist.
Hey Oliver, absolut, bei Linq wird es schnell problematisch... Frage ist halt, ob LINQ in den erwähnten Werkzeugkasten drin sein sollte oder nicht... Was meinst du? Gruß David
Ich habe mir angewöhnt bei so welchen Fällen das Ergebnis bspw. als bool in eine neue Variable zu speichern, die Beschreibt was sich hinter der Anweisung verbirgt, statt es gleich in eine if Klausel zu schreiben. Ansonsten ja, gerade am Anfang habe ich bei Datenbankabfragen versucht so viel Komplexität wie möglich in verschlungene Abfragen zu stopfen und da hilft es ein Jahr später auch nicht, wenn links daneben steht was man rechts abgefragt hat :P
Also was LINQ angeht schreibe ich fast immer alle Methoden in eine eigene Zeile - außer sie ist tatsächlich ziemlich kurz (z.B. ein Where mit einer Bedingung und ToList) Bei komplexen Abfragen lagere ich die gerne in eigene Methoden aus, ein klug gewählter Name kann dann Wunder wirken. Allerdings würde ich sagen, dass LINQ weniger das Problem ist, sondern eher die Tatsache "IEnumerable". Ich habe schon so viele Leute gesehen, die maximal wissen, dass es das gibt, aber keine Ahnung was das ist, wozu es gut ist und wie man es richtig (!) nutzt. Ein unvorsichtiger Aufruf kann sehr problematisch werden, deshalb wäre mMn. viel wichtiger, darüber nachzudenken, ob bei einer aufwändigen Aufgabe wirklich IEnumerable zurückgegeben werden soll oder nicht doch lieber IReadOnlyList
du bringst den Ausdruck von wartbarkeit und aenderbarkeit an. Ist eine Wartbare erweiterbare loesung zu bevorzugen, wenn sie doppelt so lange braucht um entwickelt zu werden? wenn ich doch mit einfacheren loesungen schon 3 weitere loesungen gebaut haben koennte. und dabei extra learnings habe und die loesungen dadurch besser und besser und immer guenstiger zu entwickeln sind. Ich moechte anbringen: das wir nicht nur den code besser machen, sondern auch uns selbst.
Das KISS Prinzip steht m.E. mit einer Reihe anderer Prinzipien und Praktiken in Zusammenhang. Manche Prinzipien unterstützen KISS, andere nicht unbedingt, sowieso nicht, wenn man sie falsch versteht. Zu den unterstützenden zähle ich DRY, YAGNI, SLA, SRP, SoC, DIP, Root Cause Analyse, Vorsicht vor Optimierungen, Code Reviews, Test First, Principle of Least Astonishment und Source Code Konventionen. Auf der Gegenseite können stehen: OCP, ISP, SRP bei Übertreibung, SLA bei Übertreibung, IoC Container, Test First und KISS selbst, wenn man es falsch verstanden hat.
Sich nur auf das Wesentliche fokussieren. Wenn es schon vorgegeben ist welche Faktoren zu beachten sind ist es simple. Ist die Anleitung fehlerhaft muss sie verbessert werden. So funktioniert Training. Wie lerne ich Tischtennis spielen. Intuition ist dann wenn ich das Wissen verinnerlicht habe. Ist ganz einfache Systemtheorie. Anwendungsbereiche im Gründe auf Alles, Weil Alles planbar ist. Wenn der Plan steht ist Alles einfacher. Siehe hierzu Professor Dr. Kruse zur Frage. Was ist Komplexität und wie gehe ich damit um.
Jetzt verstehe ich immer besser wieso so viele immer noch auf Windows Forms setzen anstatt auf WPF mit dem MVVM - Prinzip umzusteigen. - weil es das komplette Gegenteil von KISS darstellt! Beispiel: Ich will das Window schließen. Ohne MVVM: this.Close(); Aber mit MVVM musst du dafür extra ein Interface implementieren und auf deine View referenzieren. - und es gibt noch mehr Lösungen - aber alle haben gemeinsam das sie nichts mit KISS am Hut haben sondern eher so anmuten, als ginge es nicht ohne Workaround, wenn man MVVM auf C# mit WPF ernst nehmen will. Hintergrund: ich mach ein Refactoring einer mit Lazarus implementierten Anwendung und dachte: setze auf eine zeitgemäßere GUI-Entwicklungsumgebung als Forms. Ich konnte ja nicht ahnen, mit welchen Erkenntnissen ich mich davon wieder abwenden würde. Ich werde aber wohl bei WPF bleiben, nur MVVM wird ignoriert und stattdessen auf KISS geschaut, da sich nach mir irgendwann wieder jemand neu (und diesmal in meinen) Code einlesen muss.
Beim KISS-Prinzip denke ich an ein Zitat von Tony Hoare: „Ich stelle fest, dass es zwei Wege gibt, ein Software-Design zu erstellen, entweder so einfach, dass es offensichtlich keine Schwächen hat, oder so kompliziert, dass es keine offensichtlichen Schwächen hat. Die erste Methode ist weitaus schwieriger.“
Ich finde man kann etwas als "simple" bezeichnen, wenn man mit einem Blick auf den Quellcode (jetzt auf eine Klasse angewendet) direkt versteht was dort passiert. Keine Magie oder ähnliches. Dabei hilft zB auch das Prinzip "IOSP" sehr sehr gut
@@DavidTielke Hat natürlich auch so seine Vor und Nachteile. Finde es aber ganz angenehm, dass man innerhalb einer (Integrations-)Methode relativ einfach anhand der Methodennamen lesen kann, was dort passiert. Und wenn man für eine Sache mehr erfahren will, geht man einfach ne Ebene tiefer
Ich denke es fängt wenn möglich schon mit der Programmiersprache an. Wenn möglich Python und kein Java. Weniger Code der ist in der Regel leichter verständlich. Am besten die Programmiersprache, die schon Kinder verstehen bzw. eine Person, die keine Programmierkenntnisse hat. Also Low Code.
"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." (Albert Einstein) "Simple" übersetze ich hinsichtlich Softwareentwicklung mit "Schlicht". Ein schlichtes Design versucht Unnötiges wegzulassen und notwendige Kompliziertheit durch Struktur und Lesbarkeit zu kompensieren. "Schlicht" zu programmieren ist nicht einfach: wir neigen dazu unseren Intellekt durch coole Features und komplizierte Muster zu demonstrieren an Stellen, an denen sie einfach überflüssig ist. Ein Rückwärtsgang hält auch nur ein paar hundert Kilometer, alles andere wäre Over-Engineering. Ein anderer Entwickler sagte mal, er liebe langweilige Lösungen, denn dann habe man das richtige Tool für das richtige Problem angewendet. Zusammenfassend würde ich daher sagen: KISS - Halte es schlicht und langweilig. 😉
ok ich soll meinen Code so schreiben, dass auch meine Kollegen ihn ändern können. Wenn mein Kollege nun aber keinerlei Patterns Architekturen oder sowas wie OOP, SRP usw. nicht kennt, bin ich dazu verdammt monolithischen Spaghetticode zu schreiben?
KISS ist wichtig… sehr wichtig, aber ich will es eigentlich nicht anwenden, stattdessen erkläre ich lieber meinen Kollegen wie die angewendete Mechanik funktioniert, gleichzeitig schreibe ich, (auch wenn es gegen CleanCode arbeitet) bei neuen Designs einen Kommentar dazu wie mit diesem umzugehen ist. Nicht jeder kann mit Entkopplung und Interfaces etwas anfangen, aber ich will es auch nicht missen, vor allem bei den Vorteilen die so mach eine Architektur etc. bietet. „statt KISS, lieber weiterbilden“? An sich eine gute Idee, aber nicht alle wollen (die meisten kurz vor der „Rente“) / können (Zeitmangel) weitergebildet werden. (Monolog) KISS stellt für mich somit eher ein Dilemma da, mit dem man sich irgendwie arrangieren muss und für mich sind das momentan im Zweifelsfall Kommentare und Weiterbildung.
Moin Bias, Sehr guter Punkt, das ist in der Tat immer schwierig - ich denke ein gutes Mittelmaß ist hier richtig. Aber ist schwer zu finden... Gruß David
Hi Bias, ich kann dein Argument voll nachvollziehen, immerhin freut man sich, wenn sein Team ersichtlich besseren Code schreibt und in der Lage ist immer mehr und mehr Komplexität zu erfassen und über den Tellerrand zu schauen. Bei der Frage "lieber weiterbilden als KISS" muss man immer auch an neue und unerfahrene Kolleg*innen denken, die in komplexen Architekturen manchmal untergehen. Es ist meiner Erfahrung nach so, dass man nicht immer Zeit für eine 100-prozentige Einarbeitung bekommt und Teile des Codes selbst erarbeitet werden müssen und da helfen Codekommentare und Dokus (die meist nicht immer up-to-date sind) eher weniger als eine KISS-basierte Struktur. Ich selbst habe den Ansatz das Team weiterzubilden UND einen KISS-Ansatz zu nutzen, wobei KISS im Sinne des Environments zu sehen ist. Was das Problem mit "kurz vor Rente und weiterbildungsunwillig" angeht musste ich in der Vergangenheit schon ein paar mal ganz klar sagen, dass eine solche Einstellung toxisch für das Team ist und nicht toleriert werden kann, was mit der Versetzung in den Legacybereich führte. Danach waren alle Parteien wesentlich glücklicher.
Ich sehe häufig, dass ein komplexes LINQ-Statement in eine Zeile gequetscht wird, where-distinct-select-groupby-any. Auf den ersten Blick ein Einzeiler, der ja einfach zu verstehen sein müßte. Hier wären manchmal zwei oder drei Zeilen besser, weil der Gedankengang dann einfacher zu verstehen ist.
Hey Oliver,
absolut, bei Linq wird es schnell problematisch... Frage ist halt, ob LINQ in den erwähnten Werkzeugkasten drin sein sollte oder nicht...
Was meinst du?
Gruß David
Ich habe mir angewöhnt bei so welchen Fällen das Ergebnis bspw. als bool in eine neue Variable zu speichern, die Beschreibt was sich hinter der Anweisung verbirgt, statt es gleich in eine if Klausel zu schreiben.
Ansonsten ja, gerade am Anfang habe ich bei Datenbankabfragen versucht so viel Komplexität wie möglich in verschlungene Abfragen zu stopfen und da hilft es ein Jahr später auch nicht, wenn links daneben steht was man rechts abgefragt hat :P
Also was LINQ angeht schreibe ich fast immer alle Methoden in eine eigene Zeile - außer sie ist tatsächlich ziemlich kurz (z.B. ein Where mit einer Bedingung und ToList)
Bei komplexen Abfragen lagere ich die gerne in eigene Methoden aus, ein klug gewählter Name kann dann Wunder wirken.
Allerdings würde ich sagen, dass LINQ weniger das Problem ist, sondern eher die Tatsache "IEnumerable".
Ich habe schon so viele Leute gesehen, die maximal wissen, dass es das gibt, aber keine Ahnung was das ist, wozu es gut ist und wie man es richtig (!) nutzt.
Ein unvorsichtiger Aufruf kann sehr problematisch werden, deshalb wäre mMn. viel wichtiger, darüber nachzudenken, ob bei einer aufwändigen Aufgabe wirklich IEnumerable zurückgegeben werden soll oder nicht doch lieber IReadOnlyList
du bringst den Ausdruck von wartbarkeit und aenderbarkeit an. Ist eine Wartbare erweiterbare loesung zu bevorzugen, wenn sie doppelt so lange braucht um entwickelt zu werden? wenn ich doch mit einfacheren loesungen schon 3 weitere loesungen gebaut haben koennte. und dabei extra learnings habe und die loesungen dadurch besser und besser und immer guenstiger zu entwickeln sind. Ich moechte anbringen: das wir nicht nur den code besser machen, sondern auch uns selbst.
Das KISS Prinzip steht m.E. mit einer Reihe anderer Prinzipien und Praktiken in Zusammenhang. Manche Prinzipien unterstützen KISS, andere nicht unbedingt, sowieso nicht, wenn man sie falsch versteht. Zu den unterstützenden zähle ich DRY, YAGNI, SLA, SRP, SoC, DIP, Root Cause Analyse, Vorsicht vor Optimierungen, Code Reviews, Test First, Principle of Least Astonishment und Source Code Konventionen. Auf der Gegenseite können stehen: OCP, ISP, SRP bei Übertreibung, SLA bei Übertreibung, IoC Container, Test First und KISS selbst, wenn man es falsch verstanden hat.
Hey Thomas,
guter Punkt - welches ist für dich das wichtigste davon?
Gruß David
Sich nur auf das Wesentliche fokussieren. Wenn es schon vorgegeben ist welche Faktoren zu beachten sind ist es simple. Ist die Anleitung fehlerhaft muss sie verbessert werden. So funktioniert Training. Wie lerne ich Tischtennis spielen. Intuition ist dann wenn ich das Wissen verinnerlicht habe. Ist ganz einfache Systemtheorie. Anwendungsbereiche im Gründe auf Alles, Weil Alles planbar ist. Wenn der Plan steht ist Alles einfacher. Siehe hierzu Professor Dr. Kruse zur Frage. Was ist Komplexität und wie gehe ich damit um.
Jetzt verstehe ich immer besser wieso so viele immer noch auf Windows Forms setzen anstatt auf WPF mit dem MVVM - Prinzip umzusteigen.
- weil es das komplette Gegenteil von KISS darstellt!
Beispiel: Ich will das Window schließen.
Ohne MVVM: this.Close();
Aber mit MVVM musst du dafür extra ein Interface implementieren und auf deine View referenzieren. - und es gibt noch mehr Lösungen - aber alle haben gemeinsam das sie nichts mit KISS am Hut haben sondern eher so anmuten, als ginge es nicht ohne Workaround, wenn man MVVM auf C# mit WPF ernst nehmen will.
Hintergrund: ich mach ein Refactoring einer mit Lazarus implementierten Anwendung und dachte: setze auf eine zeitgemäßere GUI-Entwicklungsumgebung als Forms. Ich konnte ja nicht ahnen, mit welchen Erkenntnissen ich mich davon wieder abwenden würde. Ich werde aber wohl bei WPF bleiben, nur MVVM wird ignoriert und stattdessen auf KISS geschaut, da sich nach mir irgendwann wieder jemand neu (und diesmal in meinen) Code einlesen muss.
Hey Chris,
ganz genau das ist das beschriebene Problem :)
Gruß David
Beim KISS-Prinzip denke ich an ein Zitat von Tony Hoare: „Ich stelle fest, dass es zwei Wege gibt, ein Software-Design zu erstellen, entweder so einfach, dass es offensichtlich keine Schwächen hat, oder so kompliziert, dass es keine offensichtlichen Schwächen hat. Die erste Methode ist weitaus schwieriger.“
Ich finde man kann etwas als "simple" bezeichnen, wenn man mit einem Blick auf den Quellcode (jetzt auf eine Klasse angewendet) direkt versteht was dort passiert.
Keine Magie oder ähnliches.
Dabei hilft zB auch das Prinzip "IOSP" sehr sehr gut
Hey,
ja, das stimmt. Wobei ich finde das IOSP das Ganze eher komplizierter vom Aufbau her macht als wirklich leichter.
Gruß David
@@DavidTielke
Hat natürlich auch so seine Vor und Nachteile.
Finde es aber ganz angenehm, dass man innerhalb einer (Integrations-)Methode relativ einfach anhand der Methodennamen lesen kann, was dort passiert.
Und wenn man für eine Sache mehr erfahren will, geht man einfach ne Ebene tiefer
Ich denke es fängt wenn möglich schon mit der Programmiersprache an. Wenn möglich Python und kein Java. Weniger Code der ist in der Regel leichter verständlich. Am besten die Programmiersprache, die schon Kinder verstehen bzw. eine Person, die keine Programmierkenntnisse hat. Also Low Code.
"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." (Albert Einstein)
"Simple" übersetze ich hinsichtlich Softwareentwicklung mit "Schlicht". Ein schlichtes Design versucht Unnötiges wegzulassen und notwendige Kompliziertheit durch Struktur und Lesbarkeit zu kompensieren. "Schlicht" zu programmieren ist nicht einfach: wir neigen dazu unseren Intellekt durch coole Features und komplizierte Muster zu demonstrieren an Stellen, an denen sie einfach überflüssig ist. Ein Rückwärtsgang hält auch nur ein paar hundert Kilometer, alles andere wäre Over-Engineering.
Ein anderer Entwickler sagte mal, er liebe langweilige Lösungen, denn dann habe man das richtige Tool für das richtige Problem angewendet.
Zusammenfassend würde ich daher sagen:
KISS - Halte es schlicht und langweilig. 😉
ok ich soll meinen Code so schreiben, dass auch meine Kollegen ihn ändern können. Wenn mein Kollege nun aber keinerlei Patterns Architekturen oder sowas wie OOP, SRP usw. nicht kennt, bin ich dazu verdammt monolithischen Spaghetticode zu schreiben?
Nein, denn ihr habt guidelines, in denen steht welche Patterns als bekannt angenommen werden dürfen und welche (Spaghetti) zu vermeiden sind.
KISS ist wichtig… sehr wichtig, aber ich will es eigentlich nicht anwenden, stattdessen erkläre ich lieber meinen Kollegen wie die angewendete Mechanik funktioniert, gleichzeitig schreibe ich, (auch wenn es gegen CleanCode arbeitet) bei neuen Designs einen Kommentar dazu wie mit diesem umzugehen ist. Nicht jeder kann mit Entkopplung und Interfaces etwas anfangen, aber ich will es auch nicht missen, vor allem bei den Vorteilen die so mach eine Architektur etc. bietet.
„statt KISS, lieber weiterbilden“?
An sich eine gute Idee, aber nicht alle wollen (die meisten kurz vor der „Rente“) / können (Zeitmangel) weitergebildet werden. (Monolog)
KISS stellt für mich somit eher ein Dilemma da, mit dem man sich irgendwie arrangieren muss und für mich sind das momentan im Zweifelsfall Kommentare und Weiterbildung.
Moin Bias,
Sehr guter Punkt, das ist in der Tat immer schwierig - ich denke ein gutes Mittelmaß ist hier richtig. Aber ist schwer zu finden...
Gruß David
Hi Bias, ich kann dein Argument voll nachvollziehen, immerhin freut man sich, wenn sein Team ersichtlich besseren Code schreibt und in der Lage ist immer mehr und mehr Komplexität zu erfassen und über den Tellerrand zu schauen. Bei der Frage "lieber weiterbilden als KISS" muss man immer auch an neue und unerfahrene Kolleg*innen denken, die in komplexen Architekturen manchmal untergehen. Es ist meiner Erfahrung nach so, dass man nicht immer Zeit für eine 100-prozentige Einarbeitung bekommt und Teile des Codes selbst erarbeitet werden müssen und da helfen Codekommentare und Dokus (die meist nicht immer up-to-date sind) eher weniger als eine KISS-basierte Struktur. Ich selbst habe den Ansatz das Team weiterzubilden UND einen KISS-Ansatz zu nutzen, wobei KISS im Sinne des Environments zu sehen ist. Was das Problem mit "kurz vor Rente und weiterbildungsunwillig" angeht musste ich in der Vergangenheit schon ein paar mal ganz klar sagen, dass eine solche Einstellung toxisch für das Team ist und nicht toleriert werden kann, was mit der Versetzung in den Legacybereich führte. Danach waren alle Parteien wesentlich glücklicher.