Golo, mal unabhängig von dem aktuellen Thema, finde ich es immer sehr "deprimierend" wie du das immer alles schaffst. Alle möglichen Themen abarbeiten und aus meiner Sicht immer sehr gut erklären. Und "richtig" arbeiten scheinst du ja auch noch. Hat dein Tag 48 Stunden ? Oder wie geht das ? Mach weiter so!
Ein sehr gutes Video! Was ich noch hinzufügen würde: wir sollten gerade jungen Entwicklerinnen und Entwicklern noch weitere Prinzipien mit an die Hand geben. Viele unserer Prinzipien wie SOLID, YAGNI und Co. sind eher Richtung Software Design und wenig auf Interna, Performance und Security ausgelegt. Wie wäre es mit LTI (Learn the Internals), das aussagt, das man sich zumindest auf High-Level-Ebene mit den Frameworks, Tools und Runtimes auseinandersetzt, die man im Projekt einsetzt, damit man nicht nur APIs aufruft, sondern auch versteht, wie diese ineinandergreifen? Oder mit RPB (Respect the Process Boundary), bei dem man als Entwickler klare Unterscheidungen zwischen In-Memory-Aufrufen und I/O Aufrufen macht, da letztere deutlich länger brauchen, leichter fehlschlagen, Threads blockieren können (async await) und sauber abstrahiert werden sollten? Gerade wenn ich an meine Jugend zurückdenke, habe ich mich eher an Design Patterns, Prinzipien und Best Practices gehalten und damit versucht, meine Projekte zu gestalten. Als ich mich dann mit Interna, Performance und Security auseinandergesetzt habe, hat das meine Möglichkeiten deutlich erweitert und auch einen Gegenspieler zu erstgenannten dargestellt.
Sehe ich nur bedingt so. Man sollte ihnen die Prinzipien sicher an die Hand geben, aber man sollte ihnen unbedingt auch beibringen wie man entscheidet ob es sinnvoll ist oder nicht. Es gibt leider bereits zu viele Konsumenten des betreuten Denkens, die nicht mehr in der Lage sind ohne Handbuch ihre Schuhe zuzubinden. Wenn Entwickler nur noch nach Vorschriften und Büchern arbeiten (die gar nicht alle Randbedingungen abdecken können um wirklich JEDES Beispiel abzufrühstücken) geht die Qualität und die Performance extrem den Bach runter, weil nicht immer Clean auch Gut (in Hinsicht auf Lesbarkeit, Wartbarkeit und Performance) bedeutet und leider oft nicht unterschieden wird in wie weit eine Regel oder ein Prinzip hier Sinn macht. Es wird auf Teufel komm raus alles getan. Prinzipien, Muster und Regeln haben absolut ihre Daseinsberechtigung, aber viel wichtiger ist den Menschen das Fingerspitzengefühl bei zu bringen, wie weit man es treiben sollte und ab wann Schluss ist. Das sind Erfahrungen, die sie sammeln, die sie aber nicht sammeln, wenn sie alles nach Lehrbuch machen. Man sieht bei vielen Studenten und Absolventen der Ausbildung sehr gut wie wenig dieses ganze theoretische Wissen in der Praxis hilfreich ist. Ich habe mir das alles autodidaktisch beigebracht und habe dadurch weitaus mehr gelernt als durch das Studieren von hunderten von Büchern (die ich mittlerweile trotzdem habe, aber die mich mittlerweile mehr oder weniger nur bestätigen oder Kontroversen in mir auslösen). Man sollte einfach praktisch damit arbeiten, dann gemeinsam den Code reviewen und erklären was man hätte warum und wo besser machen können. Das Verstehen ist wichtig, nicht das stumpfe befolgen.
Vielen Dank für die Einordnung! Ich habe mir im Anschluss auch noch einmal das Video, um das es hier geht, angesehen, und fand es schon bemerkenswert, wie einseitig ist. Vor allem das Ende. Mir gefällt der Stil auf diesem Kanal hingegen sehr. Alles sehr sachlich, ruhig und vor allem nüchtern und differenziert. Sehr erfrischend in dieser RU-vid Dev Szene, wo Differenzierung Mangelware ist.
Diese einseitige Sichtweise ist halt leider auch, was ich im Alltag oft erlebe. Da werden Autoren wie Ikone behandelt, was sie in ihren Büchern schreiben ist die einzig richtige Wahrheit und dann stehen sich Menschen, die dem stumpf und blind folgen selbst ständig im Weg, auch Menschen wie Martin und Fowler haben "nur" ihre eigene Meinung, es ist weder eine umfassende und einzige Wahrheit noch ist es das Ende aller Weisheiten. Es sind Gedanken, Ansätze, Ideen und Vorschläge. Mehr nicht. Das wird aber von vielen leider nicht verstanden. Der Grund ist, dass unsere Gesellschaft zum großen Teil auf das blinde befolgen von Regeln konditioniert wurde. Dass wenige noch hinterfragen und viele einen Leitfaden zum Leben und zum Handeln benötigen. Ohne das geht es nichts mehr. Die offensichtlichsten und logischsten Dinge werden nicht getan, weil in keinem Buch steht, dass es getan werden muss.
Vielen Dank, Golo. Sehr gute Einordnung. Die Abwägung von dir Clean Code vs. Performance auf die Gegenüberstellung von Langfristigkeit (Wartung) und Kurzfristigkeit (nur Performance ist heute interessant) herunterzubrechen hat bei mir das Aha ausgelöst. 👍
Servus, vielen dank für das tolle Video 👍 Wenn man wirklich will und sich mit der Architektur genau auseinandersetzt, kann man auch mit Clean-Code gute Performance Werte erreichen. Hier kurz meine Story dazu: Ich selber hab vor 17 Jahren eine Fußballplattform gegründet mit mittlerweile 20 Millionen Pageviews und 1,5 Mio Visits pro Tag. Performance ist für uns aus Kostengründen, aber auch für den Nutzer + SEO-Bot sehr wichtig. Jahrelang hab ich versucht meinen Code immer auf Performance zu optimieren, mit wenig Abstraktionsschichten. Irgendwann hab ich gemerkt, dass ich der einzige bin, der den Code eigentlich versteht und dass ich so kein Team aufbauen kann. Vor einigen Jahren haben wir dann gestartet den großen Monolithen zu zerlegen in kleine Microservices mit deutlich lesbarerem Code. Zunächst war die Performance schlechter, aber durch die klare Struktur der unterschiedlichen Services konnten wir sehr einfach all unsere Backend-Services über ein CDN (AWS Cloudfront) cachen. Gewisse Endpunkte laufen jetzt im Schnitt mit 30ms-40ms, anstatt vorher 150-200ms. Wir haben seitdem wirklich "keine" Server-Probleme mehr. Gruß Michi / FuPa
Ich stimme dir zu - immer mit Bedacht solche Sachen angehen. Denn solche Gegen-Positionen sollen nicht blind und radikal betrachtet werden. Man kann, aber soll nicht unbedingt jedes Mal - jeden einz. Takt herausholen, jedoch in den vielen Themen kann man sowohl die Lesbarkeit aber auch die Performance berücksichtigen. Z.B. ein gut durchdachter Datenbank-Design kann vieles auf der Performance-Seite abnehmen und man kann im Code eine oder die andere Sache "besser" aus der Clean-Code-Sicht umsetzten. Doch die Erfahrung der letzten 20 Jahren zeigt mir, dass es sich sehr weniger Menschen solche Gedanken darüber machen - und weder nach Clean Code noch nach Performance streben. Sie machen einfach. Leider werden dadurch beide KPI völlig vernachlässigt. Daher - viel wichtiger in so einer Diskussion - überhaupt darüber sprechen. Vielen Dank für das Video!
Als ich das Video gesehen hatte, war mein Gedankengang auch ungefähr "Ja, er hat Recht. Wenn deine Hauptaufgabe darin besteht non-stop Flächen zu berechnen und du dafür jedes bisschen Prozessorzeit brauchst, was du kriegen kannst." Nur ist sowas eben selten der Fall und es ist viel wahrscheinlicher, dass man eben einfach neue Fälle hinzufügen muss und das möglichst ohne bestehenden Code anzufassen (lose Kopplung). Deshalb war auch mein Kommentar im Live-Stream, dass die Intention hinter Clean-Code (und allen Ansätzen mit ähnlichen Zielen) nicht verstanden wurde. Ich war also wenig überrascht, dass wir hier sehr ähnliche Meinungen hatten 🙂
Clean Code + Schnittstellen + Kombinieren statt Vererbung. Performance messen + nur da optimieren, wo es nötig ist und starke Effekte bringt. Algorithmen zuerst und danach erst die Implementierung. Einfachheit geht vor! Meine Strategie nach über 40 Jahren Programmierung.
Aus praktischer Erfahrung: Nur weil irgendetwas hässlich ist, ist etwas noch lange nicht schnell. Als Performanceenthusiast fange ich tausendmal lieber mit einem gut strukturierten System an. Natürlich gibt es auch Anwendungsfälle, in denen man durch grundsätzlich andere Programmierung mit weniger Abstraktion ganz andere Ergebnisse erreicht, aber das spiegelt nicht die Probleme der typischen Projekte wieder.
Naja, so ganz stimmt das nicht, womit der Molly einsteigt, dass es keine "Messlatte" zum clean code gäbe. Denn ein Sonar Checker wendet zum Beispiel die Heuristik der kognitiven Komplexität an. Und wenn man die markierten Stellen anschaut, würde man oft der Maschine recht geben, dass die x-fach verschachtelte Schleife an der Stelle eventuell durch etwas besser lesbares ersetzt werden kann. Aus dem Bereich Testautomatisierung erinnere ich mich auch noch an ein Beispiel, wo einfach durch neue Möglichkeiten der API der neuen Bibliothek, Teile von veschachteltem Code eliminiert werden konnten. Das bedeutet, dass die Entwickler auch durch die Möglichkeiten der ihnen (zu dem Zeitpunkt) zur Verfügung stehenden Werkzeuge durchaus limitiert sein können. Weiterer Punkt, Molly scheint ein C++ Entwickler zu sein. In C++ schreibt man oft ganz anderen Code, Systemprogramme die auf Performanz ausgelegt sind. Deshalb würde ich diese Aussagen durch diesen Filter sehen. Er redet vom L3 Cache. Also die meisten Entwickler, die jetzt nicht in C++ Programmieren, haben auf diese Sachen gar keinen Einfluss, weil die in einer "Sandbox" entwickeln. Sei es Browser, oder JVM oder Ähnliches.
SonarChecker ist kein Tool um auf "Clean Code" zu überprüfen. Codekomplexität ist auch nicht das, warum es in Caseys Video geht. Es geht bspw. nicht darum, irgendwie unlesbaren Code zu schreiben, um etwas bessere Performance hinzukriegen, sondern es geht darum, dass mindestens genauso gut lesbarer und wartbarer Code um Größenordnungen schneller sein kann, wenn man bestimmte Dinge nicht tut, die von "Clean Code" empfohlen werden.
Ich finde einen Satz von Golo ganz wichtig. "Wenn man die Funktionen richtig abstrahiert und sich Gedanken über das Design macht, kann man auch die Umsetzung der Funktionen austauschen und intern optimieren". (sinngemäß zitiert) Indem man auf die Verhaltensweise des Codes testet, kann man ohne große Risiken einzugehen nach und nach die Optimierungen einfügen, wo es auch tatsächlich was bringt. Für mich hat das auch ne Komponente aus der Informationstheorie mit Shannon Entropie. Wenn man dieselbe Information mit weniger Daten repräsentiert (Cohesion), ergibt sich fast automatisch ein gutes Design, das zur Problemstellung passt. Die Austauschbarkeit ist nämlich die wahre Form des Polymorphismus, nicht dieser Vererbungsschwachsinn, den man in der OOP Vorlesung im ersten / zweiten Semester lernt.
@@BinGanzLieb So ein Schmarrn. Man kann auch direkt Function Pointer übergeben, die dieselbe Signatur haben und dann die Funktion aufrufen. Dafür braucht man keine Klassen oder Vererbung 😂 Bei nem Klassenobjekt wird für jede virtuelle Funktion der Function Pointer als Attribut speichert. Diese Komplexität wird nur vorm Programmierer versteckt, damit man nicht darüber nachdenken muss 😂
@@BinGanzLieb Nein, das ist einfach nur Funktionale Programmierung, sowas wie Scala, Lisp, Haskell oder F# 😉 Du hast Datenstrukturen und Funktionen getrennt. Funktionen werden außerhalb von Klassen deklariert. Und man benutzt den Lambda Kalkül, der nur Fallunterscheidung und Rekursion kennt. Dein Programm sind dann ein Haufen geschachtelte Funktionen 😄
Fehler 2: Die Performance-Optimierung bei Netzwerkanwendungen gibt es genauso so. Sie ist sogar noch wesentlich wichtiger als die CPU-Rechenzeit-Optimierung. Die Optimierung lautet aber hier, mit möglich langsamen und unzuverlässigen Netzwerkverbindungen ein brauchbares Resultat zu liefert. Bei einer Navi-Software zum Beispiel "Graceful Degradation". Wenn das Netz weg ist, muss mit den vorhandenen Daten gearbeitet werden. Das wird heutztage häufiger vernachlässigt als die CPU-Zeit-Optimierung. Neetzwerkanwendungen, die bei Paketverlust gar nichts sinnvolles mehr machen, sind doch mittlerweile die Regel statt die Ausnahme. Jede Software sollte nach ihrer knappesten Ressource optimiert werden. Bei Mobil-Applikationen ist das häufig die CPU-Performance. Eine Navi-Software, die den Akku in 2 Stunden entlädt, ist z.B. unbrauchbar, selbst wenn sie flüssig läuft.
Du sprichst mir aus der Seele. Ich bin kein Fan von "Clean Code", wohl aber von guter Strukturierung. CC wird mir zu sehr als Religion betrieben. Ich programmiere immer beides, performant und strukturiert. Top down und bottom up gibt es bei mir nicht als solches, ich nenne mein Vorgehen edge to middle. Meist beginne ich mit dem bottom up Teil und setze auf volle Optimierung. In der top down Phase lege ich die Architektur mit möglichst sauberer Struktur an. In der Mitte treffen sich beide Ansätze. Beim Protokoll, wie ein Byte auf die Leitung geschickt wird, braucht man keine sonderliche Struktur. Da ist kurzer, knapper Code sogar verständlicher. Der Punkt mit nur optimieren, wenn man weiß warum, gilt allerdings auch für Abstraktion. Einfach mal auf Vorrat abstrahieren, nur weil vielleicht in Zukunft mal eine Situation eintreten können, macht die Entwicklung auch nur unnötig komplex. Auch Abstraktion kann bei Bedarf nachgerüstet werden, wenn man nicht allzu chaotisch programmiert. Ansonsten landet man schnell im Overengineerinwahn.
Sehr gutes Video. Wie bei allem muss man halt den Kopf benutzen und nicht blind Vorgaben verfolgen. Folgender Punkt fehlt mir in diesem Video. Die Entwicklung von Compilern, Interpretern und Runtimes geht auch weiter. Allgemein kann man sagen, dass die Compiler usw. immer besser werden und man an der einen oder anderen Stelle eine manuelle Code-Optimierung nicht durchführen muss, da der Compiler sich schon darum kümmert. Da aber die Optimierung von Compilern und co. komplex ist, sollte man immer messen (Profiler) um genau zu wissen, wo man im Bedarfsfall optimieren sollte.
Nicht wirklich und nicht relevant. Intel hatte auch daran geglaubt und dann mit 100 Millarden eines der groessten Fiaskos der Technikgeschichte hingelegt. Ich rede von Itanium und VLIW und EPIC (Verly Large Instruction Words + Explicit Parallel Instructuion Code). Nichts, gar nichts von dem hat funktioniert. Konnte auch nicht, bis auf reine Mathematische Berechunungen, aber die sind besser mit 5000 Cores auf ner GPU abgehandelt.
für Kontext das Orginal Video kommt von einem Game Developer... und kommt sicher aus einen GameDev Perspektive mit Hang zur Perfomance hier noch ein Interview danach das mit ihm von thePrimagen geführt wurde... ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-OtozASk68Os.html
Ich hab das Video auch gesehen und fand es aus technischer Sicht sehr interessant. Deswegen höre ich jetzt aber trotzdem nicht auf mich im Schreiben von Clean Code zu üben. Danke für dieses aufschlussreiche Video👍🏻
ich habe mir das molly rocket video angesehen und halte seine schlüsse für falsch. ein großer "nebeneffekt" von clean code ist es, dass performance probleme auf dauer entweder gar nicht erst auftauchen oder einfach zu messen und zu beheben sind. er hämmert viel zu sehr auf ein beispiel einer kleinen, nicht I/O gebundenen, zu binär kompilierten binary, wo natürlicherweise solche optimierungen noch gut zu überschauen sind und beeindruckende ergebnisse liefern können. lässt man den kollegen aber ein paar monate oder jahre eine komplexere anwendung entwickeln, so würden sich mit seinen ansätzen früh probleme bekannt machen, die die weitere entwicklung der anwendung hemmen.
Mir gefällt das Zitat von Joe Armstrong immer sehr gut: "Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!"
Ich habe das Video auch gesehen und habe das gezeigte Beispiel nachgebaut (Polimorphismus vs Switch). Bei 1'000'000 Iterationen konnte ich keine Nennenswerte Abweichung messen. Der Switch war weniger als 1% schneller. Einige Kommentare haben auch darauf hingewiesen, dass die Compiler ebenfalls Fortschritte machen. Ich habe Visual Studio 2022 verwendet. Ich hätte gerne ein Beispiel gesehen, indem Clean Code wirklich um Faktoren langsamer ist.
Obwohl es sehr nach clickbait ausgesehen hatte, habe ich mir das Video auch angesehen. Es ist halt schade das jemand "Clean Code" so aus dem Zusammenhang reißt und völlig unnötig schlecht macht. Ich beschäftige mich jetzt ziemlich genau seit 10 Jahren mit clean code und mich hat das schon sehr geprägt, Glaubenskrieger bin ich deswegen aber keiner. Lesbarkeit von Code steht sehr weit oben auf der Liste und genau da hilft es, es erhöht quasi die Entwicklungs/Maintenance-Performance.
Ich sehe dieses Video sehr spät und kann daher nur ~1 Jahr zu spät antworten, aber ich würde nicht zustimmen, dass "sauberer" keineswegs lesbarer und besser zu pflegen ist als "normaler" gut geschriebener Code. Am Ende von Kapitel 3 in Herrn Martins Buch gibt es das Beispiel der "public class SetupTeardownIncluder". Meiner Meinung nach ist dieses Stück Code völlig unlesbar und unklar. Dafür, dass wir weniger als 100 LOC haben und es keine komplexen Algorithmen gibt, liest sich der Code unglaublich schlecht und ist nur mit unnötiger Mehrarbeit zu verstehen. Meiner Meinung nach zeigt dieses Beispiel deutlich, dass sauberer Code als grundlegende "Norm" falsch ist und abgelehnt werden sollte. Die Prinzipien, auf die Clean Code aufbaut, sind nicht falsch, aber wenn sie zu einer starren Weisheit, zu einem Standard werden, sind sie abzulehnen, weil die meisten Programme nicht in ihrem Grundaufbau programmiert und verwendet werden, sondern in kleineren Untergruppen, die unnötig komplex und schwierig werden. So gibt es in diesem Beispiel Funktionen, die nur einen weiteren Funktionsaufruf enthalten oder einen einfachen Fakt zurückgeben. Warum wird hier eine Funktion benötigt? Damit die "Regel" von 4 Zeilen Funktionsinhalt nicht überschritten wird? Völlig hirnrissig ...
@@Manker00 Die primären Prinzipien die ich in diesem Beispiel sehe sind IOSP, SLA und SRP. Die Regel eine Methode sollte 10 Zeilen... es sollte schon mehr als nur ein Statement sein...)? Videos interessieren mich nicht, dass ist mir zu aufwändig, Text kann ich schneller verarbeiten...
@@ernstgreiner5927 Als Grundlagenbuch würde ich "A Philosophy of Software Design (2018) von John Ousterhout" empfehlen und auf keinen Fall "Clean Code von Robert C. Martin". Die 2-4 Zeilen Länge ist in Kapitel 3 "Funktionen". Am Ende desselben Kapitels gibt er auch das von mir erwähnte katastrophale Beispiel. Clean Code oder Anti-Clean Code ist meiner Meinung nach ein falsches Dilemma, da Anti-Clean Code kein einheitliches Konzept ist wie Clean Code auf der anderen Seite. Ich kann hier nicht alles kritisieren und erläutern, sonst wären wir morgen noch hier, aber nehmen wir SRP als Beispiel. Warum sollte man, wenn man dogmatisch bleibt, nur eine einzige Sache in einer einzigen Funktion tun? Warum nicht kontextuell arbeiten und vorhandenes Wissen nutzen? Warum nicht in Konzepten denken? Meiner Meinung nach macht eine solche Definition und Verwendung von SRP deutlich mehr Sinn. Aber das ist der grundlegende Punkt, den ich an sauberem Code so problematisch finde. Wenn man alles für bare Münze nimmt, hat man am Ende einen unnötig komplexen, manchmal unlesbaren Code. Wenn man das Ganze aber etwas entspannter sieht, neigt man dazu, sich für Anti-Clean-Code zu entscheiden und einfach gute Software zu schreiben. Keine Festlegung von Regeln, nur grundlegende Orientierungen.
@@Manker00 Das ist wirklich ein Dilemma mit dem Anti-Clean-Code-Dilemma. Das ganze Gelesene, das möchte ich für mich abschließend schon noch sagen, hinterlässt mich fast ein bisschen sprachlos, ich klinke mich hier also aus und überlasse dir die endgültig abschließenden Worte.
Performance ist halt nur ein Faktor von vielen. Hat dieser Faktor die höchste Priorität muss man andere Faktoren zurückstellen. Ich würde da jetzt keine Grundsatzdiskussion auslösen. Schöne Woche!
Richtig! Diese Diskussion: "So muß man es machen", gehen mir auf den Keks. Ich hadere beim Coden immer zwischen Performance, Struktur/Eleganz/Lesbarkeit, Ressourcenbedarf, quick'n'dirty (Wirtschaftlichkeit). Für jeden Programmabschnitt muß man sich für etwas entscheiden. Das kann manchmal bunt gemischt sein. Prinzipiell je näher an der Maschine, umso performanter und ressourcenschonender - lieber mehr dokumentieren und kommentieren. An der Oberfläche strukturierter und lesbarer.
@@pinkeHelga Genau meine Meinung und mein Stil. Abgesehen davon ist niemand perfekt und man entwickelt sich immer weiter. IMHO wird auch viel zu wenig kommentiert. Ich merke, sogar nach kurzer Zeit oft, dass ich da zu sparsam war. Der Mensch ist halt keine Maschine.
Kann dem Video nur voll zustimmen. Clean Code ist eine guter Leitfaden, aber wenn man aufhört nachzudenken und dies als umumstößliche Gesetze interpretiert kommt oft unsinniger Code raus. Beispiel: Nachdem ich eine Klasse, mit einigen zu komplex gewordenen nach dem Prinzip "Extract until you drop" durch viele kleine Methoden refactored habe, war ich kaum noch in der Lage mich in meinen eigenen Code zurrechtzufinden. Vor allem war die Lesbarkeit danach schlechter als vorher, da es ungemein anstrengend ist beim Lesen einen sehr komplexen callstack sich im Kopf zu merken anstatt eine längere Funktion einfach linear lesen.
Die Clean Code Regeln, die am meisten Lesbarkeit, Wartbarkeit und Erweiterbarkeit bringen haben keinerlei Einfluss auf die Performance: Kleine (reine) Funktionen, möglichst keine (ja keine! , wenn möglich) Verschachtelung von Kontrollstrukturen, gute Namensgebung, etc. Finde es deshalb vollkommen falsch die Themen Clean Code und Performance gegen überzustellen. Das motiviert nur diejenigen Entwicklern, die weiterhin elendig lange Funktionen mit wahnsinnigen Verschachtelungstiefen schreiben wollen, weil es sie nicht interessiert, ob ihre Team-Mitglieder den Mist lesen/verstehen können.
Das Clean Code, im Sinne von Bob Martins Buch, zu besseren Code führt, halte ich für diskutabel. Insofern finde ich Caseys Aussage, dass die bessere Wartbarkeit von "Clean" Code nicht ad hoc verifizierbar ist, die Performance hingegen jederzeit, nachvollziehbar. Die Fokussierung auf Entwickler:in-Stunden mit der kommenden Hardware-Generation zu begründen, ist schal geworden. Ist performanter Code per se schwer zu warten? Warum nicht ein wenig mehr Mechanical Sympathy? Bob Martins Buch ist arg in die Jahre gekommen. Reduziert die Unterteilung einer Funktion in mehrere Unterfunktionen die Komplexität der Systems? Woraus ergibt sich die Wartbarkeit eines Systems? Einem Berufseinsteiger würde ich wohl eher "A Philosophy of Software Design" von John Ousterhout empfehlen. Inbesondere die Dichotomie von deep vs. shallow Modules finde ich im Sinne eines wartbaren Designs einen guten Ansatz.
Es ist immer spezifisch zu betrachten. Handelt es sich um ein Sortieralgorithmus oder insbesondere um eine Matrixmultiplikation, sollte man 100% auf Performance legen. Wobei es vollkommen egal ist, dass die Technik in Zukunft noch besser werden wird und man dadurch glücklicherweise auch sogar mit seinem Clean Code etwas besser performen könnte als gedacht. Denn ein von Anfang an auf Performance ausgelegter Code hingegen wird die Schlucht dazwischen exponentiell größer werden lassen und noch weniger Ressourcen abfordern. Allein das öffnet dann wieder mehrere Türen für noch gewaltigere Technische Entwicklungen, statt das man den Speed der Technik verschwenderisch nur ausnutzt.^^ Außerdem sind Berechnungs-Algorithmen auch in Clean Code nicht direkt glasklar erkenntlich, wobei ich sogar hier maschinennahen Code sehr viel besser nachvollziehen kann, wie ich finde.^^ Ich stehe auf Effizienz und Performance und es kommt mir vollkommen am Ziel vorbei geschossen vor, wenn ich einfach nur "schön" programmieren soll.^^ Ich glaube aber das jeder hier mitgehen kann, dass man insbesondere Berechnungs-Algorithmen, die so oder so eine eigene Methode darstellen, als erstes auf Performance setzen sollte. Das man den Rest der Software freundlich gegenüber Änderungen gestallten sollte, dürfte auch jedem klar sein. Es sei denn man verliert zu viel Performance.^^
Meiner Meinung nach ist allerdings Code der nicht "Clean" im herkömmlichen Sinne ist darurch auch nicht automatisch schlecht lesbar. Wie du schon sagst: oft ist eben doch das einfache Swittch-Statement genauso einfach - oder einfacher zu lesen als eine komplexe Klassenhierarchie. Auch eine Methode mit 200 Zeilen kann gut lesbar sein, wenn sie gute Variablennamen benutzt und dokumentiert ist. Was die modularität und Erweiterbarkein angeht: Oft trifft hier ironischerweise das yagni Prinzip ("you aint gona need it") zu. Oft baut man Systeme "Zukunftssicher" und in der Zukunft stellt sich dann zu 90% heraus, dass man es entweder nie erweitern muss, oder doch sowieso eine komplett andere Implementierung erforderlich ist.
Vollkommen richtig, beim switch hast du übersichtlich alle Varianten zusammen, während bei der Klassenhierarchie alles über viele Files verteilt ist, was das Lesen des Codes sehr erschwert.
1 zu 1 deiner meinung und ich würde noch ein Argument/Anforderung für/am CleanCode mit einbringen. Entwickler höher Sprachen sind Anwender. Lesbarer Code ist eine Anforderung in dieser Zeilgruppe. Entwickler von Runtime, Compiler und Sprachen sind die Lieferanten unserer Werkzeuge. Entwickler höher Sprachen müssen lernen auch Ihre Anforderungen an die Werkzeuge einzufordern. Wenn das klappt können Entwickler höher Sprachen bei ihrem Cleancode durch die Weiterentwicklung von Runtime, Compiler und Sprachen profitieren. Codeoptimierung sollte man viel öfter als Workaround für Defizite von Runtime, Compiler und Sprachen betrachten. P.S.: Zwischen Cleancode und optimalen Code das passende Optimum für das Aktuelle Problem zu finden is ein Parameter an den man Entwickler messen kann. Dogmatismus = lvl 1
Ich finde Molly Rockets Video zeigt gut, wie ich Code optimieren könnte, wenn ich müsste! Allerdings hat er sich an der Stelle Clean Code als Feind genommen (für die Klicks), ohne die Punkte einzubeziehen, die du jetzt noch erwähnt hast. Kann mir beim besten Willen nicht vorstellen, dass er dir (uns ;-)) in puncto Lesbarkeit und Wartbarkeit widersprechen würde.
Ich find die angestoßene Diskussion gut und wichtig. Beide Extrema können gerechtfertigt sein. Entwickler brauchen meines Erachtens die Awareness dafür und müssen wissen, worauf es in welchem Fall ankommt. Und dann kann man (wie du ja auch sagst) im Einzelfall individuell entscheiden ob man in dem einen Fall Clean-code oder Performance eine höhere Bedeutung zuschreibt. Über solche und weitere Abwägungen muss man sich einfach Gedanken machen, was leider nicht jeder immer macht. Mit Performance vs. möglichst wenig Arbeitsspeicher-Bedarf (durch Caching etc.) hat man z. B. auch oft so einen Ziel-Konflikt.
Der Punkt der Diskussion, den extrem viele nicht zu erfassen scheinen ist der, dass "Performance" und "Wartbarkeit des Codes" keine Gegensätze sind. Du kannst hervorragend wartbaren code schreiben, der gleichzeitig eine gute performance liefert. Mit dem Aufstellen des Widerspruches biegt das Video gleich am Anfang falsch ab und der Rest der Argumentation ist irrelevant, da es sich um Folgefehler des ursprünglichen Irrtums handelt.
@@Tekay37 du hast noch nicht so viel programmiert, oder? Nichts für ungut. Hast du das Video geschaut? Da hat golo das detailliert erklärt und du kommst ohne Begründung an mit "Die Annahme ist falsch, der Rest des Inhalts ist daher irrelvant." What?!
@@anion21 Ich bin hauptberuflich Programmierer. Nichts für ungut. Der Großteil des Videos hat inhaltlich nichts mit der Diskussion aus dem ursprünglichen Video zu tun. Und das ist ein Problem, weil sehr viele in Reaktionen auf das Video über etwas völlig anderes diskutieren als das Thema des Videos (z.B. reden diese Leute dann davon, dass man keine "premature Optimization" betreiben solle, was nicht falsch ist, aber eben auch guter Hinweis darauf ist, dass der Kern des ursprünglichen Videos nicht erfassst wurde).
Jo, aber ich kenne normalisierte Datenbanken, wo ab bestimmten Stati man in Tabelle y und vorher in Tabelle x suchen muss. Performant ist das dann wohl auch nicht mehr. Bringt mich immer wieder dahin zurück, zu sagen, es wäre schön Entwickler zu haben, die ein großes Thema (DB, Business, DevOp oder Frontend) drauf haben und nicht alles beherrschen müssen. Das funktioniert auf Dauer halt auch nicht so gut. Vor allem, wenn Entwickler am System arbeiten und keiner weiss, was wer macht. Kann aber auch vollkommen daneben liegen und in anderen Unternehmen funktioniert das prima, weil einer den wirklichen Blick hat für das Ganze.
Ich (Hobbyprogrammierer) habe das Video gesehen und fand den "unclean" code teilweise wesentlich einfacher zu lesen als den "clean" code. Ich hatte nicht den Eindruck, dass er zeigen wollte, dass jetzt der eigenen Code komplett umgeschrieben werden sollte. Er konnte es ja nur ein zwei Richtungen zeigen. Die Alternative wäre ja gewesen, dass er den "unclean" Code als Ausgang nimmt und dann schrittweise in "clean" Code umwandelt. Das wäre aber nicht so spannend gewesen, da es immer langsamer geworden wäre. Dann hätte ich das Video wahrscheinlich nicht ganz angeguckt. Und aus meiner Sicht war der Code durchaus "schön" (Er hat keine extreme Optimierungen a la Assemblercode einfügen gemacht, keine schlechten Namen gewählt, auf viele Dateien verteilt, .... Hast Du, meiner Meinung nach, in dem Video indirekt behauptet) Der Tenor war aus meiner Sicht "Don't overengeenier, since you will loose performace".
Ging mir ähnlich. Meine Programmiererfähigkeiten halten sich auch arg in Grenzen, und manche "Clean Code" Beispiele erzeugten bei mir erstmal ein "Hä?".
Ich habe zu dem Video auch eine sachliche Gegendarstellung gesehen, mit sehr ausführlichen Beispielen. Unterm Strich optimiert der Compiler / Interpreter ebenfalls. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zVLuQAnNue8.html Für meinen Teil denke ich, dass "KISS" und Clean Code ein gutes Team sind. An dieser Stelle auch einen lieben Dank an dich für die zahl- und lehrreichen Videos.
Vielen Dank für dieses Video. Ich habe mich danach nochmal etwas intensiver mit dem Thema Cleancode und dem Thema Performance auseinandergesetzt. Sollte ich eine Aufgabe zu dem im Video gezeigten Beispiel lösen müssen, würde ich vermutlich nicht mal einen Rechner hochfahren. Das soll jetzt nicht ketzerisch sein, sondern für mein Verständnis hat man an dieser Stelle, zwei Extreme verglichen, die ich nicht als konkreten Praxisfall betrachten kann. Ich finde das Video nicht schlecht, vielleicht etwas provokant, aber er hat viel Aufmerksamkeit erregt und uns viele sehr gute, fruchtbare Diskussionen beschert. Und wenn man die Sache dann auch noch so ausführlich und versachlicht in Deinem Video ansieht, sollte doch jeder mehr gelernt als sich aufgeregt haben. Es ist zwar nicht zwingend im Zusammenhang zu sehen, aber Deine Ausführungen zu Abstraktionsschichten haben mich darüber nachdenken lassen ob das nicht mittlerweile zu viel des Guten ist. Eine Hochsprache zur Hochsprache. Wieder etwas in das jeder der am Projekt beteiligt ist eingearbeitet sein muss. Ich fühle mich z.B. mit SQL sehr wohl, wozu also Prisma. Ich denke da gibt's noch mehr. An dieser Stelle nochmals vielen Dank für eure Beiträge. Es ist mittlerweile nichts mehr was ich mir ansehe, weil ich's grad dringend brauche, sondern das gönn ich mir :)
In OOP hast du es häufig, dass du über eine Liste von Objekten iterierst, die ein Interface implementieren. Und es ist auch der Normalfall, dass du über diese Liste von Objekten iterierst und für jedes Objekt eine Methode aufrufst. Was genau soll daran kein Praxisfall sein?
@@Tekay37 Hallo Tekay, Ich stelle das gar nicht in Abrede und mache das selbst auch so. Wenn mir im Video nichts durchgegangen ist, handelte es sich durchweg um Berechnungen anhand sehr einfache geometrische Gebilde. Um das Problem zu demonstrieren ist es genau richtig, nicht zu komplizierten Code zu nehmen. In der Praxis habe ich andere Konstrukte. Eine Aussage darüber zu treffen welche Relevanz das hat, geht nur im konkreten Fall, reale Rahmenbedingungen reale Daten. Praxisbezogene Situation. Wie ich schon geschrieben habe finde ich finde ich das Video selbst und auch das Thema gar nicht schlecht und ich bin auch grundsätzlich offen, das was man so tut auf den Prüfstand zu stellen. Mich würden konkrete Fälle interessieren, dort wo es wirklich relevant wird, vielleicht auch mit der ein oder anderen Idee wie man es löst. Zu einer allgemeingültigen Aussage wird man nicht kommen. Ich beschäftige mich hauptsächlich mit Datenbankanwendungen, die häufig mit sehr schlechten Datenverbindungen und Bandbreiten klarkommen müssen. Damit dürfte ich eine andere Sicht auf das Thema haben als jemand der Spiele entwickelt Vielen Dank für Deinen Einwurf. Ich hoffe es ist jetzt etwas klarer. Gruß Adrian
@@Adrian-rd9fv Es ging da bei dem Beispiel nicht um die geometrischen Berechnungen, sondern um das Aufrufen einer polymorphen Methode. In der Praxis hast du oft nur 3-5 Implementierungen eines Interfaces (inkl. Null object) und da ist es dann im eine Größenordnung schneller, eine Funktion mit Switch zu erstellen. In vielen Fällen "spürst" du das allerdings nicht sofort. Es ist eher ein "death by 1000 cuts", also dein Programm ist insgesamt langsamer, weil du halt überall ein bisschen Performance verlierst, und es dadurch auch keine Spikes gibt. Bei uns haben wir einen Fall, wo wir für die Verarbeitung einer 300MB Datei fast 15 Minuten brauchen, obwohl das in 15 Sekunden oder sogar noch deutlich schneller gehen müsste.
Bin erst heute auf dieses Clean Code Buch bei Amazon gestoßen & überlegt es zu bestellen. Lohnt sich der Kauf oder sind solche Bücher eh nur für 1-2 Jahre, bei der sich schnell entwickelnte Technik, relevant?
Fakt ist, dass 99,9% allen Code auf dieser Welt Business Code ist bei dem Performance überhaupt keine Rolle spielt und noch nie gespielt hat. Was hier aber eine Rolle spielt ist, dass der Code bugfrei ist, denn ein kleiner Bug in so einem Code kann ein Unternehmen eines Tages Millionen kosten. Und genau solche unnötigen Bugs soll Clean Code vermeiden. Man darf das Originalvideo von dem Typen um das es hier geht nicht mal kommentieren und auch auf seiner Seite dürfen nur zahlende Mitglieder kommentieren, mit anderen Worten: Kritik ist nicht gewünscht und das spricht ja schon Bände. Anscheinend weiß er wie schwach seine Argumente sind und wie leicht man die zerlegen kann. Ich habe z.B. auch schon OpenGL Wrapper und Video Decoder nach Clean Code Prinzipien entwickelt und die waren überhaupt nicht langsam. Den Fehler, den er in seinen Beispielen macht ist der, dass er eben alles mit aller Gewalt in High Level Clean Code gießen will. Aber genau wie auch dieses Video erklärt spricht nichts dagegen innerhalb einzelner Komponenten auf Clean Code zu verzichten und zwar da, wo man eben mit rohen Bytedaten arbeitet. Deswegen kann das Framework drum herum trotzdem komplett nach Clean Code Kriterien aufgebaut sein. In meinen OpenGL Wrapper z.B. waren einzelne Vertices natürlich keine Objekte, sondern Gruppen von Vectices (und eine Gruppe kann halt aus zig tausenden Vertices bestehen) waren ein einziges Objekt und im Objekt waren Vertices einfach nur Float Zahlen in einem Array. Trotzdem war das ganze schön nach außen hin gekapselt als ein Objekt und die ganze 3D Welt eben aus solchen Objekten aufgebaut, die auch Texture Referenzen und Shader verwaltet haben und die man dann an den Renderer gegeben hat, um das Gesamtobjekt irgendwo in der 3D Welt zu zeichnen. Nach den gleichen Argument des Originalvideos müsste man alles in Assembler schreiben, weil das dann nochmal deutlich schneller ist als wenn man das in irgend einer anderen Sprache schreibt, in der Praxis aber gibt es in einer App nur ein paar Performance Hotspots und nur die würde man ggf. in Assembler optimieren. Für den Rest der App bringt es so gut wie gar nichts hier auf eine Hochsprache zu verzichten. Man würde damit nur perfekt lesbaren Code durch komplett unlesbaren ersetzen und as für 2% Performancegewinn.
Performance ist nur EIN Faktor. Tatsächlich ist aus meiner Erfahrung heraus dieser Punkt erstmal am unwichtigsten. Gesamtarchitektur ist wichtiger. Performance kann man später immer noch herstellen. Und ging in der Praxis auch immer relativ leicht.
Es ist aber auch sehr einfach sich mit Architektur oder grundsätzlich technischen Entscheidungen gewisse Optimierungsmöglichkeiten komplett zu verbauen. Denen sollte man sich schon bewusst sein.
Kann ich alle so unterschreiben wie es gesagt wurde. Ich hatte mit Kollegen schon oft die Diskussion über die Lesbarkeit von Code und der für mich wichtigste Maßstab für den Code einer Anwendung ist die Meinung des "neuen Kollegen". Wenn dieser nach kürzester Zeit alles versteht, mitarbeiten kann und vielleicht sogar zu mir kommt, weil es darüber so begeistert ist, dann glaube ich etwas richtig gemacht zu haben. Aber, auch mir ist klar, dass es Teile von Anwendungen gibt, die einfach schnell sein müssen. Gerade dann kann man gut auf Cleane Code verzichten. Ziel ist noch immer dem Nutzer die Anwendung zu liefern, die er braucht.
Super Zusammenfassung :) Ein Gedanke von mir zum Thema Kosten von Hardware vs. Entwicklung: Ich denke schon, dass auch Menschen bald aufgrund von Github Copilot etc. "das nächste Update bekommen" und wesentlich schneller und effizienter entwickeln. Mich würde in der Zukunft mal interessieren wie man den Fortschritt von KI unterstützter Entwicklung entgegen sinkenden Hardwarekosten pro Leistung berechnen würde und ob es irgendwann potenziell günstiger/effizienter ist einfach ChatGPT den Code auf Performance optimieren und gut kommentieren zu lassen.
Ich kann mir in 99% der Fälle keinen Performancegewinn vorstellen, wenn ich nicht auf Clean Code setze. Performanceprobleme sind fast immer nicht auf den Programmcode zurück zu führen.
Die Schlussfolgerung finde ich sehr gut. Es ist am Ende, wie so häufig, eine Abwägungssache. Persönlich habe ich leider schon viel zu häufig beide Extreme (Performance oder Clean Code) erlebt, was idr eine sehr unbefriedigende Erfahrung war
Die kleine Exkursion zu premature optimization ist auch großartig! Das habe ich ebenfalls bei der Arbeit häufig erlebt. Unnötige Änderungen, die sich quer durch die Anwendung ziehen, um potentiell 10ms schneller zu sein 👏
Ich denke, das größte Problem ist, dass viel zu wenige Code gesehen haben, der sowohl performant als auch gut wartbar ist, um sich vorstellen zu können, dass es nicht nötig ist, diese beiden Dinge gegeneinander abzuwägen.
@@Tekay37 ich glaube in dem Fall reden wir ein bisschen aneinander vorbei oder ich habe mich unglücklich ausgedrückt. Es ging mir nicht um die Abwägung zwischen “Performance und Wartbarkeit”, sondern um “Performance und Clean Code”. Dass zwischen den letzteren beiden ein gewisser Zielkonflikt herrscht, hast du selber in deinem Kommentar unter diesem Video gesagt
@@lou1134 naja, aber Wartbarkeit ist doch das Ziel von Clean Code. Wenn es eine Alternative zu Clean Code gibt, die alle Vorteile liefert, aber keinen der Nachteile, dann wäre Clean Code schlicht zu verwerfen und die Alternative zu wählen.
Am besten können es Leute beurteilen, die es jahrelang sowohl mit clean code als auch nicht mit clean code zu tun hatten. Es geht nicht nur um code performance, sondern auch um mitarbeiter performance (siehe wartung,motivation,einarbeitung,etc)
Im Grunde zeigt er nur die Kosten von Runtime Polymorphism/Dynamic Dispatch auf, mit einem Clickbait-Titel. Um sauberen Code an sicht geht es ihm gar nicht. Die Überlegung ist zwar valide, aber ich will behaupten, dass sich weniger als 1% aller Software überhaupt mit solchen Kosten beschäftigen müssten. Irgendwie Kernel-Module und Game Engines und in ein paar Fällen von embedded-Zeugs... und das wars. 99% der Software sind aber irgendwelche Geschäftsprozesse, Maschinensteuerung, an Enduser gerichtete Tools usw. bei der die hunderte von Stunden Entwicklungszeit viel wichtiger sinid, als die wenigen Nanosekunden Laufzeit, die man vielleicht spart, wenn man auf Polymorphie verzichtet. Zumal es natürlich auch noch Ansätze gibt, Polymorphie mit gescheiter Performance zu verbinden - siehe Entity-Component-Systeme in der Spieleentwicklung. Ein ähnlich verfehltes Video war das "Why OOP sucks" von Brian Will. Da werden Grenzfälle extrapoliert und der Allgemeinfall ignoriert. Er hat als Beispiel für "gute prozedurale Programmierung" seinen SNES-Emulator in Go auf GitHub angegeben - und ganz ehrlich, ich finde es super schlecht geschrieben. Teilweise Verschachtelungen, die so tief sind, wie man das von Legacy-Fortran-Code kennt. Zyklomatische Komplexität von horrent bis absurd. Ich halte das alles für schwarze Rhetorik und kann solche Autoren nicht ausstehen.
"Performance ist an dieser Stelle völlig unwichtig"... Ich würde gern mal einen neuen Punkt in die Diskussion bringen: Schlechte Performance verbraucht nicht einfach Rechenzeit, sondern Energie und (im Falle von nötig werdenden Hardware-Upgrades) weitere Umweltresourcen. Vielleicht müssen wir als Entwickler auch ab und zu daran mal denken. Wir erwarten das von anderen Branchen schließlich auch. Damit will ich nicht gegen Clean Code wettern, aber Optimierung und Reduktion von Overhead sollte immer eine Überlegung wert sein. Betrifft natürlich nicht nur CPU-Zeit, sondern auch Netzwerktraffic.
Erfahrungsgemäß, gerade wenn eine Software längere Zeit weiterentwickelt wird, ergeben sich Performance-Probleme auch oft dadurch, dass durch schlechte Programmierung der eigentliche Ablauf vor dem (anderen, neuen, whatever) Entwickler versteckt wird. Der sucht sich dann Schlupflöcher um für das aktuelle Ticket möglichst wenig Zeit aufbringen zu müssen oder möglichst wenig Änderung am Code vorzunehmen (beides wichtig, klar) und nach zig Iterationen verbrennt das Teil nur CPU (und HW, Netz, etc.).
Fehler 1: Die (approximierte) inverse Quadratwurzel in Quake hat nichts mit Nicht-Clean-Code zu tun. Es ist eine Implementierung hinter einem wohldefinierten Interface. Die Art und Weise der Implementierung ist für den Anwender irrelevant. Das betrifft heutzutage fast jede Funktion. Es haben sich schlaue Leute Gedanken über die Implementierung gemacht, haben sie implementiert und getestet und dokumentiert und der Anwender nutzt sie. Lesbar sind da insbesondere in C++ selbst einfache Funktionen nicht mehr, da man über zig Hilfsklassen und SFINAE-Konstrukte gehen, die bei mir nur noch Hochachtung und Mitleid für die Compiler-Entwickler auslösen.
Dieser Gegensatz, dass man Wartbarkeit und Performance gegeneinander abwägen müsse, wurde in Reaktion auf das Video oft vorgebracht. Caseys Argument dagegen ist, dass "Clean Code" WOWOHL in Sachen Performance katastrophal ist, ALS AUCH in Sachen Code-Lesbarkeit, bzw. Wartbarkeit. In sofern geht das Video am Kern von Caseys Video vorbei. Aber vielleicht ein Beispiel dafür, die schlimm "Clean Code" für die Performance eines Programms sein kann: Microsoft hat neulich stolz ein Video gezeigt, bei dem MS Teams nicht mehr 20 Sekunden zum starten brauchen, sondern "nurnoch" 9.1 Sekunden. Und Teams hat jetzt nicht unbedingt die ausgefeilteste UI mit ultrakomplexen grafschen Finessen. Ein anderes Programm dagegen, das ein Foto in ein 3D-Modell umwandelt und die verschiedenen Punkte des Fotos im Raum verteilt, und bei dem man die Kamera frei bewegen kann, braucht ca. 0.1s Sekunden zum starten UND laden der Datei, ist also in diesem Aspekt immernoch 100 mal schneller als Teams. Es wäre daher in Auseinandersetzung mit Caseys Video sinnvoller, sich seine Programmierweise mal genauer anzuschauen (e.g. Data-Oriented Design) und zu schauen, ob ein solcher Code wirklich Nachteile bei der Entwicklung und Wartung bringt.
Casey und Robert Martin haben im Anschluss an das Video eine hervorragende Diskussion auf github geführt, die unbedingt gelesen werden sollte, denn sie zeigt, dass sich die beiden in wesentlichen Aspekten völlig einig sind.
Die Argumente, die sich eigentlich gegenüberstehen, sind daher: (Bob): "wenn du wartbaren Code haben willst, dann musst du abstrahieren und das kann performance kosten" (Casey): "Du kannst perfekt wartbaren Code haben, der gleichzeitig bis zu 1000x schneller ist" Die Fragen, mit denn man sich in Reaktion auf Caseys Video also auseinandersetzen müsste, sind: 1. Ist Caseys Art Code zu schreiben wirklich genauso wartbar? 2. Ist dieser genau wartbare Code wirklich so viel schneller? Die Antwort lautet in beiden Fällen: ja.
Wenn der Code Testbar ist, dann hat man Clean Code. Das hat einen höheren Mehrwert als Clean Code / Performance. Und wenn du eine neue Sprache verwendest dann hast du beide Konzepte an deiner Seite. PS. Ich würde mich freuen, wenn du mit RUST beginnst.
@@marcotroster8247 Leider nicht. Wenn du deinen Code Objekt-Orientiert geschrieben hast, dann hast du mit großer Wahrscheinlichkeit wesentliches Potential für Performance deines Codes bereits aufgegeben, den du nicht mehr ohne erheblichen Entwicklungsaufwand zurückbekommst. Da ist es dann egal, wie viele Tests dein Code hat, denn die tests wirst du auch neu schreiben müssen.
@@Tekay37 Kommt drauf an, wie hart du an die Sache rangehen willst 😂 Ich sehe das Problem immer unter dem Aspekt der Entropie aus der Informationstheorie. Wenn man die Information mit weniger Daten repräsentiert, ergibt sich automatisch immer ein sehr ähnliches Muster, das zum Problem passt. Und wenn man dieses Muster der Codestruktur rausarbeitet, kann man alle möglichen Optimierungen sicher gekapselt innerhalb der Abstraktion halten 😉
@@marcotroster8247 Ne, es kommt da tatsächlich gar nicht drauf an. Wenn du ein einzelnes Objekt hast, das für sich genommen eine Liste von Daten (structs) verwaltet, dann bist du bereits um den Faktor 10 schneller als wenn du eine Liste von Objekten hast, bei dem jedes Objekt sich selbst verwaltet. Und wenn du dann noch deine Datenstrukturen auf Struct of Arrays umstellst, (statt array of structs), dann kannst du nochmal erhebliche Performance rausholen. In der objektorientierten Welt hast keinerlei Zugriff auf diese Art der Optimierungen.
@@Tekay37 Ich beziehe das doch nicht auf die Repräsentation der Daten, sondern auf die Signatur der Schnittstelle. Wenn die Schnittstelle was taugt, kann sich dahinter was auch immer befinden. Da kannst du dann gern dein Struct of Arrays machen, whatever 😂 Und klar, wenn man es intern schafft, mehr Cache Hits zu bekommen und SIMD Ops zu nutzen, ist es halt schneller. Ganz einfach. Man muss halt verstehen, wie ne moderne CPU funktioniert 🤔😂
Nachdem Ich selbst vor ein paar Tagen das Video gesehen hatte, hab Ich mir Gedacht "endlich sagt es mal einer". Mit deinem Fazit stimme Ich jedoch in keinster weise überein. 1) Er hat nur sachlich vorgetragen, was Ihr da hinein Interpretrieren sollt, hat er gar nicht vorgegeben. Ich hab Ihn nicht sagen hören "Schreibt gefälligst nur noch in Assembler, weil jede andere Abstraktion Perfmance kostet" Nö, er sagt einfach nur, das Abstraktion Performance kostet und Beispielhaft wieviel. 2) Der Grund warum es all diese Abstraktion gibt, ist schlicht und ergreifend "Kapitalismus". Die Leute machen sich gar keine Gedanken mehr was unter der Haube eigentlich passiert, denn es funktioniert ja, dass ist auch das was du prädigst "wenns funzt, nicht anpacken" Das ist basicly "Ich kann ja auch zum Kiosk um die Ecke mit dem Hubschrauber fliegen, weil ich hab's ja" .. Wir haben ja nicht nur einfach die Prozessor Instruktionen abstrahiert und dann nochmal dass Abstrahierte abstrahiert, na klar ist das schon eine Abstraktion, aber wozu hat's denn geführt? Zu Java. Die Abstraktion von Prozessor und Betriebssystem unabhängigen, zur Laufzeit kompilierten Instruktionen einer Sprache worin ALLES abstrahiert wird... 3) Du Rechtfertigst dem Compiler optimierungen vorzuenthalten, damit du an einer Stelle was ändern musst anstatt an 2 wenn du was ändern musst 4) "Andere können leichter meinen Code lesen, weil Ich alles abstrahiere und Ich zu faul bin Kommentare zu schreiben geschweige denn zu lesen" Fazit: Abstraktion in der Programmierung ist schlecht. Punkt. Der Grund warum es Sie gibt ist Kapitalismus. Punkt.
Mit Kapitalismus hat das nichts zu tun, denn durch "Clean Code" entsteht den Unternehmen ja kein Vorteil. Im Gegenteil sogar: die Entwickler sind genauso schnel oder langsam wie sonst auch, aber die Programme laufen langsamer. Es liegt eher daran, dass Software-Entwicklung noch eine sehr junge Industrie ist, die über Jahrzehnte den Vorteil hatte, auch immer schnelleren Rechnern entwickeln zu können. Da ist einfach kein Anreiz entstanden, auf Performance zu achten. Das Ergebnis sind jetzt zahlreiche Entwickler, die sagen "Performance spielt bei uns im Unternehmen überhaupt keine Rolle", weil das eben deren Erfahrung aus den letzten 30-40 Jahren ist und die verstehen dann aufgrund ihrer langen Erfahrung nicht, warum sie die Arbeitsweise, mit der sie ja lange erfolgreich waren, ändern sollten. Ich denke, die Lösung dafür wird Konkurrenz sein. Man kann das z.B. bereits bei Adobe Photoshop, das im Vergleich zum Affinity Designer eine absolut lahme Ente ist. Mit besserer Performance wirst du aktuell anderen Produkten kinderleicht die Stirn bieten können und auf diesem Weg wird Performance dann auch aus "kapitalistischer" Perspektive wieder interessant. Aber dafür müssen die derzeit erfolgreichen Unternehmen erstmal die nötigen Schmerzen durch die Konkurrenz zu spüren bekommen.
@@Tekay37 Dem ist ja nicht so. Kapitalistisch gesehen machen wir alles richtig, wie es in der Software Industrie läuft. Kann die deutsche Performance gegen das chinesische "einfach mehr" mithalten? Kann es offensichtlich nicht. Mit Java bisste einfach schneller bei Massenware und deshalb musst du um dem grösstem IDE Software Herrsteller noch die Stirn bieten zu können als eines der grössten Unternehmen der Welt ein Open Source Produkt in JavaScript-Chrome Bundle mit stabilem Addon System basteln um da noch irgendwie hinterher zu kommen.. (sprich Antikapitalistisch sein) Der ganze AI Kram läuft auf Python.. Tut mir leid, Ich sehe das nicht kommen. Rust und Go haben der Programmierung einen Bärendienst in der Zwischenzeit erwiesen, aber solange die Leistungsgrenze nicht erreicht ist, wird keiner an Optimierung denken. Das machen nur Freigeister. Kapitalismus halt. Ich sehe es als realistischer an dass wir bald mehr JavaScript Frameworks als C++ Entwickler haben, als das wir uns auf Performance besinnen.
@@MrOnePieceRuffy Das klingt alles sehr wirr, was du da schreibst. Der größte IDE Hersteller dürfte derzeit JetBrains sein und die sitzen in Prag. Die haben übrigens gerade auch eine verbesserte UI rausgebracht, die sich deutlich performanter anfühlt als die alte. Die Konkurrenz dazu, auf die anspielst (VSCode) ist übrigens auch gar nicht mal so gut. Ich würde da eher mal auf Neovim schauen. Du bist mit Java oder C# auch nicht schneller, sondern in diesen Sprachen gibt es Framworks, die dich für einen gewissen Preis schnell einfache Dinge tun lassen. Schon mittelfristig stehst du mit diesen Sprachen schlechter da, aber dann ist es schon zu spät, weil Umsteigen dann kurzfristig teurer ist. Dass KI in python läuft liegt übrigens daran, dass es für python zahlreiche Bibliotheken gibt, die in C geschrieben sind. Wenn du die in python benutzt, dann bist du tatsächlich schnell. Das liegt aber an C, nicht an python.
@@Tekay37 ich verstehe nicht wie dass einen meiner Punkte wiederlegt. Genau genommen, tut's das auch nicht. Es bestätigt mich ja eher nur. Und lass mal wettrennen machen, Ich in Java oder C# und du in C. Die challenge ist, kompiliere Hello World für Linux, Mac und Windows, gucken wer schneller ist.
@@MrOnePieceRuffy kompilieren für die verschiedenen Plattformen ist die vermutlich albernste Metrik, die es in dem Kontext geben kann. Sowas passiert heute in CI-Prozessen. Wer klug ist, der hat für jedes Betriebssystem eine main-Datei von der aus er das Programm compiliert, diese main-Datei enthält ausschließlich Betriebssystemspezifische Operationen und das war's. Betriebssysemunabhängigkeit ist heute kein Vorteil einer Programmiersprache mehr. Zusätzlich kann ich C und C++ aber auch als Sprachen nicht leiden, daher bin ich froh, dass es inzwischen das sehr schöne ODIN gibt und hoffentlich irgendwann bald auch jai.
@@michaelkebe Trivago und TYPO3 haben beide durch Clean Code ihre Performance enorm gesteigert. Trivago hat die Performance der Startseite enorm erhöht und TYPO3 ist zu einem der performantesten CMS überhaupt geworden. Dazu empfehle ich "WARP - A Web Application Rewrite Project" zu lesen. Bei YT geht es eben auch um Klicks, Meinungen und Interaktion. Das wird damit doch sehr gut erreichen ;)
@@NeverCodeAlone oh sorry, hab Deine Frage erst soeben gesehen. Der Satz "Nachts ist es kälter als draußen" ist genauso sinnlos wie der pauschale Satz "Clean Code holt locker mehr als 30% Performance raus". Es kommt doch einzig und allein darauf an, wie performant der vorhandene Code schon ist, auch wenn er total unsauber geschrieben ist. Falls der unsaubere Spaghetti Code voll auf Performance getrimmt ist, kann er nur ein wenig langsamer aber nicht 30% performanter werden, wenn man in sauber refaktoriert. Umgekehrt konnte ich total sauberen Code um 1000% beschleunigen, indem ich eine absolut dirty geschriebene Code Bibliothek zur Beschleunigung der Berechnung von mathematischen Funktionen eingebunden hatte. Ja, es gibt sicher Fälle, in denen man 30% oder mehr Performance durch Code Cleaning herausholt. Dann aber auch nur, wenn man strukturelle Fehler mit negativer Wirkung auf die Performance findet und behebt. Mein Tipp: sei vorsichtig bei Sätzen, die implizit oder explizit absolute Wörter wie z.B. "immer" oder "nie" enthalten. Dein Satz lautete "Clean Code holt locker (immer) mehr als 30% Performance raus"
Das Ding ist halt, wie in jedem anderen Beruf auch, dass man beim Arbeiten auch unbedingt das Gehirn benutzen muss. Man muss in der Lage sein abzuwägen zwischen dem Machbarem und dem Notwendigen. Wenn man sich durch Techniken und Prinzipien die Performance kaputt macht muss man natürlich überlegen welchen Preis man zahlen möchte. Und auch Fowler und Martin sind nicht der Weisheit letzter Schluss. Ich habe von Fowler erst vorige Woche "Refatoring - Wie sie das Design bestehender Software verbessern" gelesen und bin nicht in allem einer Meinung mit ihm. Das ist, was unsere Arbeit ausmacht. Wir sind schaffende Künstler, natürlich braucht man dafür aber auch eine gehörige Portion Verständnis von dem was man tut und Fingerspitzengefühl es richtig zu machen. Nicht nur Clean Code kann einem Probleme bereiten, auch Techniken wie ORM, wenn man z.b. sehr Laufzeitintensive, iterative Prozesse hat, die z.b. sehr große Dateien importieren. Leider ist es aber eben auch in unserem Beruf wie überall, richtige Fachkräfte, die ihren Job aus Leidenschaft machen und nicht, weil es Geld bringt, sind leider rar.
