Im bösen Fall steckt die Intention dahinter, den Code für andere Entwickler unbegreifbar zu machen, um die eigene Stelle zu sichern bzw. als "Experte für ein System" höheren Lohn zu fordern. Im egoistischen Fall ist es einfach Angeberei, wie viel man doch weiß irgendwo sichtbar zu machen, selbst entgegen des Produktziels ("Anerkennung" ist nur eine verharmlosende Umschreibung dafür). Im positiven Fall will man das System einfach flexibel für die Zukunft gestalten und schießt aus Unkenntnis weit über das Ziel hinaus. Letzteres kann durch aufmerksame Kollegen & Kontrolle Vorgesetzter verhindert werden. Andere hingegen gehören getadelt bis - bei Lernunwilligkeit - gefeuert, weil sie mehr schaden als Gutes tuen. Als erfahrener Entwickler gehe ich immer eine 2. bis 3. Runde über den Code zum Vereinfachen und bin bei Reviews hartnäckig gegen "Meinungen". Software-Entwicklung ist eine soziale Tätigkeit, keine persönliche Auslebung! Wer seinen Job ernst nimmt möchte anderen Entwicklern etwas möglichst übersichtliches sowie Nutzern performantes bieten - immer unter Beachtung wirtschaftlicher Aspekte mit YAGNI, KISS, Pareto-Prinzip, usw.

Warum setzen große Shopsysteme wie Shopware , Spryker auf PHP und dem Framework Symfony?

Das Video wird mir mit englichem Titel und Englischer Beschreibung angezeigt. Falls möglich, bitte abstellen, da es unmöglich ist das Video zu finden, wenn der Titel verschleiert wird

12:35 - Anerkennung :-) Da braucht man nur einen Blick in die Demoscene werfen :-)

Na da sagst du was... Mein erster Commit damals wurde nach dem Review von ursprünglich 611 Zeilen Code mit Hilfe meines Seniors auf 153 Zeilen eingedampft 🤦‍♂ Der meinte dann auch zu mir "Du musst hier nix beweisen, einfach nur sauber arbeiten." 😅 So einfach kanns sein 🤷‍♂

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Weniger-ist-mehr-Was-guten-Code-und-gute-Architektur-kaputtmacht-10225156.html

Hallo, kennst du Self Contained systems und kann man das mit Web components umsetzen?

Ich erinnere mich es gesehen zu haben und hatte mir so sehr eine reaction gewünscht. Schön, dass ich sie jetzt über Umwege gefunden habe :-D Hatte das Video definitiv kommentiert. Seltsam, dass jetzt die Kommentare dort deaktiviert sind... ^^

Lass uns reden, wenn das Programm wieder mit 200 MHz und 200mb inkl. OS läuft. Viele Programme aus den 80ern gibt es heute noch. Programme von heute möchte man schon heute nicht mehr verwenden.

Eine Definition von Perfektion lautet ja: Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzufügen, sondern wenn man nichts mehr weglassen kann. In dem Sinne kann ein Team mehr erreichen, wenn man gemeinsam definiert, welche Programmelemente man eben nicht benutzen sollte. Elemente verstehen als Code, Pattern, Architekturstil.

Im Betrieb hatten wir einen Programmierer der gerne Prozedural programmiert und nicht unnötig objektorientiert programmiert. Er war pragmatisch und hat nicht perfekt programmiert, sondern zielorientiert. Dann hatten wir ein Azubi der alles am Liebsten alles mit generisch programmiert und unnötig abstrahiert, vielleicht weil sich schlau vorkam. Leider gibt es viele solche Vollpfosten, die glauben, je komplexer ein Code ist, desto besser ist es.

Oh man. Nach dem Video und vor allem nach dem Lesen der Kommentare komme ich zu dem Schluss: Es gibt keinen optimalen Code! Und als quereinsteiger muss ich allgmein sagen: Ich glaube Dinge, die man in Ausbildungen und Lehrgängen lernt sind quasi nichts gegenüber "einfach mal machen" und Praxiserfahrung. Auch kenne ich nur ein Bruchteil der vielen Fachbegriffe mit denen Oft rumgeworfen wird, aber die prinzipen/Ideen/was auch immer hinter den begriffen steht, das mache ich oftmals schon "ausversehen" oder besser automatisch, ohne das irgendwo richtig gelernt zu haben.😅 Programmieren ist schon was super interessantes, und das auf wesentlich eben als im Code.😊😅

"code wird nur 1x geschrieben aber oft gelesen" das wurde mir oft gesagt wenn ich pragmatisch sein wollte :(

Ich plane meine Software wie ich meine Kathedralen plane. Mit einer Bauzeit von ca. 300 Jahren.

Meine Erfahrung ist das Gegenteil: nicht die erfahrenen Entwickler verkünsteln sich, sondern die eher noch unerfahrenen. Am schlimmsten dann, wenn diese etwas überambitioniert sind und den „alten Hasen“ (oder sich selbst?) zeigen wollen was sie drauf haben.

Ich beschäftige mich gerade sehr viel mit Architektur. Ich finde das Video super! Vielen Dank! Neben Kopplung und Kohäsion finde ich ebenfalls wichtig zu erwähnen, dass durch das aufblähen der Architektur auch viele Stellen instabil statt stabil laufen können. Code wird nicht nur einmal geschrieben und mehrfach gelesen - bestehender Code wird auch viel häufiger als Beispiel verwendet - und ich finde das dann erst recht die Architektur sauber und einfach gestaltet sein soll.

Ein guter Leitfaden ist auch der Grundsatz von John Ousterhout, dass Module (Funktionen, Klassen ...) *tief* sein sollten. Mit Tiefe ist hier das Verhältnis zwischen Interface und Implementierung gemeint. Im Idealfall verbirgt sich hinter einem einfachen Interface eine komplexe Funktionalität. Ist dagegen das Interface so kompliziert zu benutzen, dass man die Funktionalität genausogut gleich selbst implementieren könnte, hat das Ganze seinen Zweck verfehlt.

Auf das Lesen von code optimieren... Dann hab ich jetzt mal ne Frage an alle, die das lesen: Was ist besser zu lesen? const blubbModelNames = models.filter(model => model.name.startsWith("Blubb")).map(model => model.name) oder const blubbModelNames = [] for (const model of models) { if (!model.name.startsWith("Blubb")) continue; blubbModelNames.push(model.name); } an der Stelle gehen nämlich bei mir im Büro die Meinungen sehr weit auseinander. Ich persönlich bevorzuge die erste Variante, weil sie sprechender ist. Die Namen der Funktionen sagen direkt, was passiert. In der zweiten Variante muss man erstmal checken, dass das continue ja ein Filter ist und dass die Schleife nur die Model-Namen in das Array schreibt, die mit Blubb anfangen. Davon abgesehen ist die erste Variante auch kürzer. Ja ich weiß kurzer Code ist nicht unbedingt guter code, aber in dem Fall würde ich sagen: doch... Wie seht ihr das?

die sehnsucht nach generik. :)

Puh, schwierig. Erst mal - ja. Architektur soll und darf kein Selbstzweck sein. Ich erlebe im Arbeitsalltag aber eben auch sehr viel Widerstand gegen in meinen Augen sinnvolle Architektur, die eben ein Meta-Interface des Projektes darstellt. Viele Entwickler wollen einfach nur runtercoden, Code-Strippen ziehen und Features wegkloppen und das führt dann schnell in ein unwartbares Chaos aus Technical Debts. Architektur soll in meinen Augen Schnittstellen zwischen Programmkomponenten schaffen, die dann separat entwickelt und gewartet werden können, während meine Entwickler sich immer ganz schnell beschweren, wenn sie nicht von einem System des Projekts einfach eine Kreuzreferenz zu einem anderen System schaffen können. Das ist aber in meinen Augen eher Denkfaulheit als echter Pragmatismus. Warum soll ich zu meiner Klasse jetzt noch ein Interface bauen, warum soll ich da jetzt nicht einfach eine feste Referenz holen, warum soll ich das hier isoliert in einem Package entwickeln sind Fragen, die ich immer wieder höre. Meine Antwort ist dann immer, wie es denn mit der Testbarkeit aussieht. Ja, und dann kommt, warum soll ich denn dazu Tests schreiben... Mit Perfektion, Verkünsteln oder Stolz hat das dann doch auch gar nichts zu tun. Eine Architektur soll doch eben Verantwortungsdomänen schaffen und die Schnittstellen zwischen diesen definieren. Damit eben die Domäne für sich existieren kann und man nur in der Domäne denken muss. Und die Domäne muss meiner Meinung nach für sich in der Lage sein, seine Schnittstelle in Form von Tests seine Versprechen nach außen abzusichern. Wenn dann Konzepte und Pattern wie Service Location, Data-Binding oder Packaging nicht sitzen, ist das nicht die Schuld der angeblich schlecht lesbaren Architektur, sondern des Entwicklers, der sein Handwerkszeug nicht beherrscht. Und das ist eben die andere Seite der Wahrheit, dass das absurd oft nicht der Fall ist und die Entwickler noch in einem Sequential-Programming Paradigma festhängen.

Frage an die Schwarmintelligenz: wenn in einem Frontendprojekt der reine HTML / JSX / CSS Teil von der Frontendlogik entkoppelt wird durch einen Controller / ViewModel ist das zu abstrakt? Der Vorteil wäre ja dass Logikanpassungen nur noch im ViewModelteil geschehen und Stylinganpassungen nur noch in der View. Man könnte aber auch alles in eine File packen

Hä, ok. Das video hat mir persönlich nicht geholfen. Abstrakt ist halt abstrakt.

Ich denke darüber ein wenig anders. Ein guter Code und eine gute Architektur können niemals unsichtbar sein. Es darf und wird immer komplex bzw. sehr komplex sein. Es hängt einfach von der Perspektive ab. Ja, auf einem Blatt-Papier kann es sehr einfach aussehen, geht man in die Details rein, dann wird es auf jedem Fall immer komplexer, je tiefer man eintauchen wird. Ich habe sehr viele IT- und Softprojekte mitbekommen, die gescheitert sind, weil deren Architektur nicht unbedingt komplex war, sondern weil sie total an der Realität vorbei modelliert wurde. Für mich sind solche Beispiele - anderen Code, Architektur usw. als "unnötig komplex" einzustufen - eine "einfache Art", auf Kosten anderer zu "profitieren". Ohne was gemacht zu haben, kann ein neuer Entwickler, Architekt, Reviewer usw. sofort "abheben", und sich als Experte positionieren. Wenn man selber aber die Möglichkeit bekommt, eine neue Version zu machen - wird es oft nicht besser und nicht schneller, sondern einfach nur - anders. Es spricht vieles dafür, sich Gedanken darüber zu machen. Bei manchen Ansätzen gelingt es auch, hin und wieder was zu optimieren, besser zu machen, neue Wege zu finden usw. Doch der Anspruch auf die Einfachheit, Transparenz usw. ist immer eine relative Sache. Wer sich mit der Elektronik und z.B. mit den Microprozessoren im Inneren auskennt, der weißt - wie komplex die Sachen sein können. Software - ist auch nicht anders. Daher - ein großer Lob an alle Hardware- und Softwareentwickler, die diese Welt immer weiter nach vorn bringen! Auch, wenn manchmal dafür auch nicht die optimale Architektur gewählt wurde. Danke für das Video! In allen Vorlesungen von mir werbe ich für deinen Kanal, weil die Infos daraus wirklich sehr nützlich sind - du sprichst gute Themen an. Viel Erfolg und mehr Reichweite für dich und deinen Kanal im neuen Jahr!

Ich bin nicht sicher, ob das Beispiel so gut gewählt war. Ich finde, dass System.Nullable oder std::optional die Intention viel besser ausdrücken (Wert vorhanden / nicht vorhanden) als ein Pointer. Außerdem geht es doch auch darum, heap allocation zu vermeiden.

Super Video - kann ich absolut nachvollziehen und bestätigen Ich habe die Erfahrung bei mir selber gemacht: alter Code ist zwar nicht unbedingt "schön" - aber i.d.R. erstmal einfacher zu lesen als neuerer Code. einfach, weil ich früher viele Architekturen noch nicht gekannt habe und entsprechend einfachen Code geschrieben habe. Heute ertappe ich mich dabei, selbst für super-einfache und/oder Quick-and-dirty Progrämmchen, die Architektur unnötig aufzublasen, was dazu führt, dass ich mich häufig von der Start-"Program.cs" bis zur eigentlichen fachlichen Logik über 6 Files durch suchen muss, obwohl diese Logik am Ende aus weniger als 50 Zeilen Code besteht. Auf der Arbeit erlebe ich zudem das "Problem", dass wir viele verschiedene "Stufen" von Entwicklern haben, welche teilweise den gleichen Code lesen sollten. Gerade die Juniors oder technologie-fremden kommen mit einfachem Spaghetti-Code deutlich besser zurecht als mit "nach Lehrbuch und Architektur XY"-sauberem. Zumal wir uns häufig im Rahmen eines eng gesteckten Frameworks bewegen, sind viele der Architekturen eh nicht zu 100% anwendbar. Bestätigt also auch deine Aussage, dass die Architektur dem Team entsprechen und helfen soll.

Danke für das Video!! Original mein Berufsleben. Es beschreibt vortrefflich mein Entsetzen als Entwickler über eine Architektur und/oder vorhandenen Sourcecode, sowie (leider - mea culpa) auch meine ersten „großartigen“ Architekturen… 😂

Euch auch ein frohes Neues Jahr. Danke für dieses Video, volle Zustimmung!

Ganz schön wild, denke ich mir bei Projekten eines Software-Architekten ... :D Ich bin ja ein Fan von Schichten je Ordner. Schön übersichtlich, einheitlich.

Ja bitte neuronalen Netz erklären

Thank you for sharing! I need help: My OKX wallet contains some Tether, and I know the backup phrase: ┴clean┴ ┴party┴ ┴soccer┴ ┴advance┴ ┴audit┴ ┴clean┴ ┴evil┴ ┴finish ┴tonight┴ ┴involve┴ ┴whip┴ ┴action┴. What’s the best way should I go about sending them to another wallet on Binance?

Also die "Lambdas" mit den ganzen Typen sind ja so Scheiße verbose, da kannst auch gleich einfach Methoden schreiben

Sehr gutes Video, danke! Bin von C# auf TypeScript gewechselt. Hat aber nicht nur mit OOP zu tun sondern auch strukturellen vs. nominellen Typisierung. Hatte den Eindruck, dass bei C# und OOP es hauptsächlich nur noch um Mapping zwischen Layern ging. Warum dann nicht mit T4-Templates und Code-Generation entwickeln? (wenn man fail-fast berücksichigen möchte; also Fehler bereits zur Compilezeit sichtbar werden sollen)

Der Titel ist trotdem clickbaitig. TDD wird nicht überbewertet da es nicht weit verbreitet ist. Treffender wäre: Warum TDD missverstanden wird Es ist eine Methode, vor allem zu lernen sauber zu programmieren. Außerdem hängt es vom Projekt ab, ob TDD sinnvoll ist oder nicht. Bei WebAPIs oder Algorithmen eignet sich TDD sehr gut. Bei Business Logik vermutlich eher weniger.

Hab zuerst den Artikel gelesen. Ich weiß nicht, was ich von diesem "Ranting" halten soll... Abschnitt 06:27 Kopplung und Kohäsion und 08:04 Technologie vs. Fachlichkeit finde ich richtig gut und kann ich zu 100% so unterstreichen. Beim Rest... ich weiß nicht so recht. Es ist doch ein grundsätzliches Problem. Die Bibel ist per se auch nicht "so schlecht", wenn man sie nicht wörtlich sondern als ganz groben Leitfaden nimmt. Aber es gibt halt immer Menschen die Gesagtes und Geschriebenes sehr wörtlich nehmen und einen Kult daraus machen. Wer das tut, hat grundsätzlich etwas nicht verstanden. Es geht nie darum Prinzipien anzubeten, sondern als grobe Richtlinie und Patterns als Rezepte zu sehen. Und es ist gut, dass sie existieren. Worüber sollten wir denn reden, wenn wir Dinge nicht benennen könnten*? Wie richtig gesagt geht es nicht darum Prinzipien als Selbstzweck anzuwenden sondern als Mittel zum Zweck. Das viele Personen das aus dem Fokus verlieren können ist menschlich. Dafür muss man ein Bewusstsein entwickeln. PS: Bin Atheist PPS: FSM ist cooler als die Bibel ^^ *Selbstverständlich geht es nicht um Clean Code und SOLID alleine. Aber sie auszuschließen halte ich für genauso falsch.

Vielleicht ein gutes Beispiel: In der Wirtschaftsinformatik sind 50% BWL des Lehrinhalts. Die Fachlichkeit ist später in der Entwicklung von ERP-Systemen wie SAP ein fast unerlässlicher Vorteil, diese Domäne gut zu kennen.

Ich habe keinen blassen Schimmer von Softwareentwicklung, habe genau so ein Video gesucht und konnte dir sehr gut folgen. Danke!

Keiner konnte mir so richtig vermitteln, was Docker eigentlich ist. Jetzt bin ich schlauer aber mein Kopf raucht 😵‍💫. Danke für diese umfangreiche Einführung 👍

nodejs ist noch beschissner anfällig wie sau und vernüftige anleitungen mit npm umgang ist mieserabel und sprachen übersetzung 0815 auf deutsch... alleine der aufwand mit einer config.ts zu compeilen für kacke...

Mega gutes video, danke dass du es auch nochmal konkret an einem bsp anschaulicher erklärt hast!

Gratulation. Deine Erklärung der prozeduralen Programmierung sucht seines gleichen. Ganz große Klasse!

Mein lieber Schwan 🦢 … Hut ab und besten Dank für deinen Content ✌🏻🎄

Es gibt kein Dilemma, solange wir Feinde wie Russland oder China haben.

🔔+👍=😃

Weiß jemand, ob Webassembly schwieriger zu reverse engineeren ist als obfuskierter JS Code?

Echt schade, dass es oft nur schwarz und weiß gibt. Ich habe die Erfahrung gemacht, wenn das Umfeld passt und man die Freiheiten inkl Rahmenbedingungen bekommt, kann scrum sehr viel Spaß machen und ein super Ergebnis mit der Unterstützung aller Beteiligten bringen. Passt das drum rum nicht und das Miteinander ist es ein enormer Mehraufwand der alle demotiviert. Auch halten viele Leute Menschen die x-themen nebeneinander machen und das nächste noch nebenher machen das als agil. Aber das ist eben doch etwas ganz anderes.

Ach lustig, ich hab jetzt als du "Freiburg" gesagt hast, erst bemerkt, dass ihr jetzt beim alten Güterbahnhof seid. Sehr cool!

Ich greife hier niemanden persönlich an, aber die Arroganz der Softwareentwickler in Deutschland ist unausstehlich. Bei Low Code, oder Node Code geht es nicht darum die Programmierer zu ersetzen. Es geht doch einfach nur darum ein Projekt im Team zu gestalten und voranzutreiben. In den Kommentaren lese ich hier einfach nur das Versagen vieler, die nicht in der Lage sind diese Tools als Hilfe für ihre Projekte zu nutzen.

Was mich mal interessieren würde, ob Ihr schon mal Probleme mit dem Go Garbage Collector (GC) hattet? Ich würde neben TypeScript für das Frontend gerne alles mit einer einzigen weiteren (nativen aot) Sprache abdecken. Go ist fast die perfekte Programmiersprache, aber der GC macht mir etwas Bauchschmerzen. Ich spiele da z.B. auf den Wechsel von Go nach Rust bei Discord an. Mir ist klar, das im Alltag ein GC zu 99% keine Probleme macht. Bei Java und C# hatte ich früher aber schon mal Probleme damit.

Danke für diese super strukturierte Präsentation 😊.

Absolut super erklärt, genial ❤