Zen of Python: Grundprinzipien (nicht nur) der Softwareentwicklung (1 von 2) #23

Hallo liebe Zuhörerinnen, einfach komplex heute geht es mal um das sogenannte Zen of Python oder die Grundprinzipien für das Schreiben von Computerprogrammen. Das senden auf Python ist so 19 leitprinzipien wie wie man Code schreiben kann, woran man sich halten sollte. Wir haben das ganze bisschen aufgebohrt, weil das war bisher nicht genug. Was hat dich dazu bewogen, das noch n bisschen aufzubauen, ist eine gute Frage. Ja, also wir wollen mal ne Folge machen, aber es gibt so.

Es gibt so tolle abstrakte Leitlinien. Ja für Entscheidungshilfen quasi wenn man Code macht. Man muss sehr viel entscheiden irgendwie, wenn man wenn man Code schreibt. Und zwar nicht nur im technischen Detail, sondern auf großen Linien.

Und dass das, dass R Python und mir immer schon hier gewesen, aber es gibt natürlich noch viel mehr Leitsätze und Leitlinien, die da jetzt nicht drin vorkommen, und deswegen habe ich gedacht, dass wir so machen, sondern Philosophie folge, bisschen, dann nehmen wir gleich mit rein, mal gucken, wie vielleicht ein bisschen deswegen, heute aber schauen wir mal durchgehen so kurz einmal aus dem Off.

Wir haben es nicht geschafft, alle Prinzipien, alle Grundprinzipien der Softwareentwicklung in einer Folge unterzubringen und daher werden wir das Thema splitten und diese Woche nur die von uns kuratierte Liste vorstellen und nächste Woche auf die auf Python eingehen. Viel Spaß mit der Folge ich finde es spannend übrigens den auf Python Gerrit und ich haben das kurz vorher nochmal gegoogelt, weil wir beide nicht wussten was eigentlich senden. Jetzt muss ich gucken, ob ich s wiedergeben.

Es kommt glaube ich aus dem Buddhismus hast du gesagt und das ist so ne Art, ja heißt Meditation, Versenkung und so weiter. Und ich glaube, es wird auf der Begriff wird vielleicht benutzt für ein vollkommenes abgeschlossenes System, über den ja das irgendwie in sich stimmig ist, einheitlich wo ich drüber nachgedacht habe, wo ich mich rein versenkt habe, das passt eigentlich gar nicht so schlecht

zu dieser Folge weil. Genau diese Leitlinie besprechen wollen die sollen den Anspruch haben, dass man in schwierigen Zeiten, wo man irgendwie diffus im Kopf ist, ja wieder Fuß fasst meditativ fast also irgendwie wieder auf dem richtigen Wege geleitet wird, ist so ne Art, ich will jetzt nicht sagen Religion so aber irgendwie so Grundkonzept Bibel Regel und so weiter für alles Mögliche was eine Software kommen kann ne

normale. Ich finde den Anspruch n bisschen damits spannend wie folgt dar also die sind wirklich wichtige Dinge, die mir schon ganz oft geholfen haben bei schwierigen Entscheidungen so dann kann man echt sich mal so Leitlinien nehmen. Gibt ja viele kluge Köpfe der

Softwareentwicklung auch. Also sollten auch alle dranbleiben, die jetzt nicht aktive Python, Programmierer sind oder programmieren ganz allgemein, sondern ich höre, das ist, was viel übergreifendes auch in anderen ja, ich sag mal Abteilungen Bereichen, aber auch im Leben ganz allgemein helfen kann nicht nur in der Programmierung ihr werdet

vielleicht sehen oder hören. Besser gesagt, wenn es losgeht, was wir damit meinen, woran ich gedacht habe ist da wir ja dann auch noch den anderen oder die andere Linien im Call Call Podcast haben. Die Zuhören ist es ja auch

wichtig. Vielleicht dann doch mal der Entwicklungsabteilung auf die Finger gucken zu können, oder malt rauszuhören hey, habt ihr gewisse Leitlinien befolgt oder habt ihr hier eigentlich Prinzipien, nach denen ihr arbeitet oder ist das relativ wild und willkürlich was ihr macht, kann man dafür auch verwenden die Folge?

Hm, weiß ich nicht, ich glaube, das mag die Software, die ich so, wenn man hingeht, so ihr kennt die Regeln habt ihr die befolgt so keine Ahnung ich glaube, es würde ein privater Auslegen. So jeder hat ja seinen Stil und man kann überhaupt nicht über einen Kamm scheren. Es gibt also also das Erstellen von Software und die Prinzipien.

Die sind so bunt und so vielfältig wie beim Komponieren der Musik. Ja, und es gibt ja auch ganz viele Arten von Musik, also von Klassik über Jazz über Pop oder was alles hat seine Rechtfertigung und seinen Anspruch und deswegen würde ich sagen.

Ich kann jetzt nicht irgendwie auf dann jetzt sagen das oder das musst du so machen, aber es sind einfach ein paar Konzepte, wie man sagen kann OK, wenn du das vielleicht diese Regeln im Kopf hast, klingt vielleicht irgendwie so OK und da gibt es noch verschiedene Kategorien und so aber alles klar würde ich n bisschen locker und eher privat so jeder, jeder muss sich dann ja auch aus diesen ist ein Blumenstrauß von von Guidelines.

Manchmal sind die auch manchmal gar nicht vielleicht in Richtung, vielleicht sogar ein bisschen widersprüchlich und jeder muss sich selber seinen Weg bahnen und richtig interpretieren für sich so. Gut, dann lass uns nicht weiter Zeit verlieren tatsächlich wir haben 30 dieser Prinzipien vor uns, die sind vielleicht zum Teil überschneiden sich n bisschen vielleicht zum Teil widersprechen sich auch n

bisschen. Wir werden sehen und manche werden wir sicherlich ein bisschen besser gesagt, hat andere vielleicht relativ schnell abhandeln. Diese 30 setzen sich zusammen aus 19 ja leitprinzipien oder Grundprinzipien Principles guiding principles eigentlich auf Englisch für Python und 11 weitere die ja wir jetzt einfach für sehr relevant halten. In unserer täglichen Arbeit und insbesondere der der Entwicklung der Software. Mit denen werden wir tatsächlich starten, also diese diese

weiteren Wissens diese zusätzlichen Weisheiten, diese 11 zusätzlichen Weisheiten mit dem Anfang Burkhard, die erste, die du aufgeschrieben hast Always have a Single Source of Truth? Uns fehlt dazu der entsprechende Autor wir wissen nicht ganz genau, wo der Ursprung liegt bei den ganzen anderen werden wir dann bei diesem wissen wir nicht genau n Konzept, was sich so entwickelt hat über die Jahre,

was verbirgt sich dahinter? Ja hab ich als Erstes aufgeschrieben, weil das erste ist, was mir irgendwie eingebläut wurde, als ich angefangen hab Software zu schreiben ja, das ist eigentlich ganz einfache Regel ja, okay Single. Also nur eine Quelle der Wahrheit? Ja, und das hat ganz viel mit

Daten zu tun. Wir arbeiten immer mit Daten und Funktionen quasi das Macht die Software aus und die Frage ist wer wer speichert, welche Daten im Grunde genommen haben wir viele Datenbanken und wir haben ja große Systeme heutzutage und manchmal hast du 2345 Systeme, die miteinander arbeiten.

Dann gibt es auch so Management Meeting, wo man sagt so was ist denn hier das Leitsystem und welche anderen hängen sich dran und so weiter und sofort, denn es gibt ja oft ne Integration so größere integrative Projekte hast und da ist aber als Softwareentwickler. Als Designer sag ich einfach mal, wir können ja sogar ein bisschen von der Softwareentwicklung, ja gut kurzen einen Schnitt mache ich kurz, bevor ich jetzt hier gleich noch weitere warum machen

wir das jetzt? Nicht nur für die Softwareentwickler, sondern die Folge ist auch total relevant für alle No Code Low Code Tool Entwickler weil ja, ob ich jetzt, ob ich jetzt software wirklich schreibe oder ob ich jetzt das diesem das System einfach nur Designer indem ich irgendwie zum Beispiel nutze bleibt es aber den gleichen Anspruch ja also diese großen Designprinzip sich dachten ja, das ist so wenigstens mindestens zu einem großen Teil. Kurze Zwischenstopps und jetzt zurück?

Single Source of Truth also es kann schon sein, dass ein System zum Beispiel eine Datenbank, wo bestimmte Daten gehalten werden und das andere System braucht diese Daten halt auch um den unter Task zu zu machen oder irgend sowas macht halt einen komplementären Task und jetzt schon die Frage was passiert denn dann schick ich dir dann immer einzeln zu zu den Systemen oder kriegt die Daten quasi auch ja und hat dann eine eigene Datenbank und so weiter und sofort, wir haben ja schon

Austauschformate gehabt, gerade in der letzten Folge und das sind dann sind Scheidungen ja also quasi nur System a die Datenbank. Alle anderen Systeme, die auf den Daten arbeiten müssen, kriegen nur on the Fly als Austausch geschmissen. Oder gibt es da einen Cash und so weiter und da kann man sich diese Grundregel auch nehmen und sagen ist eigentlich egal, kannst du austauschen kannst du auch eine eigene Datenbank haben? In den Austauschsystemen s Wurst?

Aber du musst wenigstens mental ein System festsetzen, was die Single Source of Truth ist also das ist die Wahrheit ja, dann kannst du auch synchronisationen machen. Davon spricht man oft, musst halt Dateien synchronisieren, wenn sie, wenn sie persistiert, also wenn sie nur nicht quasi im Kabel sich austauschen, wenn sie irgendwo liegen, kann man alles

machen. Aber wir wissen, gegen wen wir synchronisieren müssen und wir wissen, wer hier die Wahrheit angibt, so ja, dann müssen nämlich alle BCDF Systeme haben zwar auch eine Kopie von System A aber System a gibt die Wahrheit an so ja und im Falle von von von ich weiß nicht genau, was los ist oder dass vielleicht alt synchronisiere ich mir die Daten von A wieder zurück, sogar das total wichtig, dann geht nix durcheinander und das ist halt auch nicht nur

designprinzip, das ist auch n. Ja, das muss man mit den Projektpartnern auch diskutieren, so dass jeder weiß ja, es gibt ja viele, die vielleicht schreiben und so weiter und da muss man vorher festlegen wer hat hier die Wahrheit? Ja, wer hat hier die Wahrheit der Daten und können viele können?

Viele Single Source of Truth geben aber nie für die gleichen Daten so und ein wichtiges Prinzip, wenn man das beachtet, glaube ich kriegt man kriegt man ein sauberes System und wenn es nicht beachtet ist, auf jeden Fall Chaos vorprogrammiert was du gerade muss aus dem Marketing, was ich jetzt in jeder Firma, in der ich bisher gearbeitet habe, erlebt habe, dass unklar war, wo oder dass zumindest das zu Problemen geführt. Wo liegt der Zentrale?

Folienmaster ja, damit sichergestellt wird, dass jeder Foliensatz, der in diesem Unternehmen oder auch für Externe produziert wird, genau gleich aussieht. Ja, und davon darf eigentlich nur existieren, den alle benutzen sollten als Template für was auch immer hat jetzt nicht so viel mit Daten und und und softwareprogrammierung zu tun. Aber auch da ist total sinnvoll diese Single Source of Truth to haben ja was ist hier gerade der Datensatz, der einfach die Wahrheit oder die Wahrheit

darstellen? Er spricht mir aus dem Herzen Gottes, hatte ich sogar noch mit reingeschrieben die Planung, denn das ist ja ganz viele von diesen Themen. Sind natürlich erstmal für Software ausgesprochen, aber haben eine viel größere Relevanz, ja für Management für auch ganz andere Berufe und so weiter. Single Source of ist im ganzen Büromanagement glaube ich auch eine sehr gute, eine sehr gute Regelung.

Folienmaster ist oder oder die die die die die CI Farben und so weiter und sofort ja hab ich davon mehrere Ordner und das liegt mehrfach und ich ändere das und habe es nicht überall geändert. Ja, dann ist der erste Mitarbeiter, der weiß davon nichts und so weiter. Ja, also das geht immer schief so also eine einfache Regel. Ich glaube, da muss man gar nicht da war nicht viel mehr dazu sagen ne? Tatsächlich haben wir 5 Minuten drüber reden wir heute gut nochmal 2 die wir rausgesucht

haben ist premature Optimization is the root of All Evil, also voreilige Optimierung ist die Wurzel allen Übels frei übersetzt ja und hier haben wir Quelle das Buch The Art of Computer programming. Weil Donald Knut aus dem Jahr 1980 schon ziemlich alt. Was hat er damals schon so einen

wahren Satz gesagt? Ja. Ja, ich denke da damals vielleicht noch viel relevanter als heute, weil ich glaube, Computer Optimierung, Programmierung sollte 1968 war noch ein dickes Brett als heute mit es gibt viel mehr links und so weiter. Das wird einfacher zu optimieren.

Aber vielleicht auch nicht, weil das ist ja auch die Software ist dafür sehr vielschichtiger geworden sehr viel, ja intransparenter auch für den Entwickler wir ganz viele Bibliotheken arbeiten, die wir gar nicht kennen und das, das muss ja alles mit betrachtet werden, wenn nicht bei, wenn ich optimiere was heißt denn Optimierung?

Ja, ich hab also ich hab erstmal ne Funktion mir überlegt und bin und und und will erstmal funktionale Produkt machen und dann, wenn ich das Kodiere ist vielleicht nicht so schnell wie ich das gerne hätte. Aktives Beispiel Ich habe Oberfläche gemacht so und ich mach Grad und das fängt irgendwie an Zucker hatten wir auch. Da gibt es ja mal ne und dann und dann?

Und jetzt musst du überlegen, wann wann fängst du an, rum zu optimieren, ne und dieser dieser diese Wahrheit oder dieser diese Weisheit sagt Halt macht das Halt ganz spät ja und kann ich

nur bestätigen. Weil es ist unglaublich zeitintensiv, eine Performance zu optimieren, weil was ich vorher machen muss ich muss erst mal rausfinden was ist überhaupt ein Bottleneck, also wo, warum ist es langsam ja find das mal raus, weil einer komplexen Software da gehst du ganz lange in die Analyse und dann findest du raus, das war mein, das war mein Bottlenecks und dann fängst du an zu optimieren. Ja, und dann ist es wieder immer noch langsamer kommt der nächste

und so weiter. Das ist unglaublich aufwendiger Prozess, der ganz viel Zeit kostet und der sofort wieder unnötig war. Wenn ich die Software funktional n bisschen schreibe, dann ist eine ganz andere.

Bewiesen hat vielleicht schon andere Probleme, die die zuerst da sind so. Ist wichtig, aber function first ja und dann Optimization second sag ich auch immer also das ist, das ist ganz ähnlich, wenn ich mir ein Beispiel bringen darf in in der in der Optimierung von Produktionsprozessen, also physische Produktion von meinetwegen Autos oder oder was auch immer da gibt es ja so Ansätze wie Leben oder Sigma und

sowas. Ich kann Experte aber auch da geht es immer darum, erstmal das tatsächliche Bottleneck zu identifizieren und dann dort auch zu optimieren und nicht einfach loszulegen OK verstanden dann den dritten finde ich ziemlich cool, ja, weil man redet viel darüber. Es geht um Skalierbarkeit. Und ich glaube, deine Ansicht, da ist ganz spannend und zwar lautet es oder lautet dieser System diese Weisheit Scalability the number one problem people don't actually have but still salve.

Das basiert auf einem Tweet von Eberhard Wolf aus 2019 und ja, wieder frei übersetzt ist das Nummer 1 Problem, was Menschen versuchen zu lösen, aber was eigentlich nicht existiert. Ja, ich liebe diese Weisheit passt auch ganz gut so inhaltlich, zu der der vor also ein bisschen so ähnlich.

Jetzt Optimierung, aber es ist quasi schon ja, es ist auch Optimierung durch, wenn ich skalieren will und optimiere ich quasi trotzdem, die das System damit irgendwie verformt bleibt auch unter Last, also mit vielen Nutzern ja. Ich find den so wichtig diesen Satz ja, und das ist nervt mich

so heutzutage wenn du wenn du mit irgendwelchen Leuten sprichst, so auch das haben wir auch ganz oft so ja ist denn Architektur nutzen Dennis und wie ist das verteilt? Wir machen in welcher dann haben Sie in der Cloud Riese Lösung und so weiter? Und wenn ich dann sage, so NÖ,

haben wir erst mal nicht. Wir haben erstmal ne Maschine so und klar haben wir Microservices und so aber wir brauchen gar keinen Cybernetics ja, wir kommen jetzt mal ganz klar mit den mit den einfachen Sachen von Docker und so weiter ist alles überschaubar ja, das geht doch nicht muss doch mitdenken und so weiter völliger Quatsch so ja also ich manchmal das Gefühl, dass heute also da werden ja Waffen rausgerückt und Kanonen ja um Probleme zu lösen, die gibt es ja gar nicht.

Ja, und die Leute fragen die das wollen. Das haben die haben noch nicht mal ein Produkt gesehen. Ja, die wissen überhaupt nichts über die Skalierbarkeit und ich kann auf 1000 Arten. Skalieren so ja, und bevor ich überhaupt keine Probleme hab mit meinem System, muss ich auch nicht anfangen, aber Skalierbarkeit nachzudenken, wenn die das Design der Software sauber mache, löst sich Skalierbarkeit zum Schluss von ganz alleine.

Da kommen wir schon viele Gedanken ja, wenn wir mit Containern Manager mit Containern arbeitet, muss man da nicht am Anfang drüber nachdenken. Ja, und ich glaube, es wird also unglaublich viel Wasser warm gemacht und und Münzen irgendwie aus dem Fenster geschmissen.

Für riesige Systeme, die die machen einfache Webauftritt oder Irgendsowas. Und dahinter steht ein riesen AWS Cloud mit Load Balancer und was nicht alles, was die heute aufsetzen, weil man denkt OK, wenn wenn der 5000000 User gleichzeitig klickt ja dabei hat man irgendwo oder irgendwas also da bin ich sehr allergisch gegen dieses diese und mag das halt besonders gerne hat das natürlich auch verrückt, ja sehr ist eine ausgewählte Weisheiten Liste wenn man sich was weiß ich

so ein Dienst wie Netflix anguckt oder sowas natürlich skalierbar sein und ist entsprechend hoch skalierbar und du hast jetzt viele technische oder Technologien Reingeschmissen mit Kubernetes und Loadbalancer. Vielleicht sind sie einfach eingesetzt werden, wenn man skaliert oder um skalieren zu können.

Letzten Endes Software aber auch da wieder ich glaube, dass so ein so ein lean Ansatz da also Lean startup Ansatz gibt es auf RS für Softwarefirmen, insbesondere auch für andere Firmen ganz, ganz gut sein kann, einfach mal erstmal zu gucken und zu testen und wenn man die Probleme stößt, die dann auch zu lösen, explizit aber von vornherein das ist auch wichtig sagst du die Software so aufzustellen, dass sie mal skalierbar ist ja, indem du sauber mit Container Technologie

arbeitest, ja und Microservices, die wir übrigens infolge weiß ich nicht 34 oder sowas mal erklärt haben ja genau dafür sind die meisten noch wie ich den Code zu schreiben, dass er dann auch weiter. Papa ist so ne vielleicht noch einen Satz den hatte ich gerade im Kopf, als du das gesagt hattest man ist ja auch verwöhnt ja, weil wir haben halt dieses ganze Zeug und das macht ja auch irgendwie Spaß dann Rumkommen führen aber am Ende wird es total komplex.

Keiner versteht mir wirklich, was da los ist. Das ist ja wirklich auch wirklich komplexe Materie mit diesen ganzen Loadbalancer in der Cloud, was total heilsam ist, was ich erleben durfte Gott sei Dank, wenn mal ein Stück Software entwickelt, für so ein Embedded also für so ESP 32 also einen Chip, der irgendwie so in so einem Kochfeld oder sowas

drin ist, da ist halt nichts mit laut und laut Balance und ABS und manchmal wirklich irgendwie sparsam da codieren muss und dann erfährt man überhaupt mal wo wo überhaupt mal was skaliert werden muss ja, man muss ja erst mal ich ich spreche den meisten Leuten davon ab überhaupt gesehen zu haben, dass ihr. Programm irgendwie in die Not kommen, skaliert werden zu müssen, ja, da musst du erstmal hinkommen, das ist ja cool, wenn es so ist, dann so viele User hast, dass da tatsächlich mal so

n sind. Ja fette Rechner hätte CPU ist, dass die immer irgendwie in die Knie gehen, dann würde ich erstmal Beifall klatschen. Cool ja n Ding, jetzt kannst du mal gucken, ob die Zweite einen zweiten Server brauchst skalieren soll. Also geht ein bisschen letzten Endes ja und wenn Ressourcen einfach billig sind, dann nutzt man sie vielleicht einfach ja, aber man muss sich vielleicht einmal Gedanken darüber, wie ich das Ganze eigentlich ist voll ist voll, nicht nachhaltig und wirtschaftlich.

Wenn man das mal so von auch von der genau cool, ja und witzig relativ frisch. Der Tweet wurde Eberhard Wolff 2019 OK, weiter gehts Nummer 4 ist Don't repeat yourself d.

Er will ja nicht zu wechseln. Mit DI wurde geprägt von Andy Hunt und Dave Thomas. In ihrem Buch Die Pragmatic Programmer in 1999 schwierigste Englisch hier ja also Yourself Burkhard das passt nicht auf den Podcast ja, wiederholen schon ab und zu mal ja, das ist tatsächlich Lebensweise, die nicht so gut auf andere Felder übertragbar ist, sondern auch beim Lernen und so weiter. Soll ja gerade wiederholen.

Hier geht es um Sourcecode. Dass man halt quasi den den den Sourcecode so aufräumt und in Funktionen teilt, dass man halt nicht gleiche Dinge noch mal aufschreibt, der hat auch ganz viel mit dem ersten Punkt Single Source of Truth zu tun, jetzt aber quasi nicht von den Daten her gesehen, sondern vom Quelltext her ne, also schreib mir kurz wenn man quasi verschiedenen an verschiedenen Stellen im Code immer wieder das gleiche macht, eigentlich so fast Kopien hat von Blöcken von

Code, dann ist das nicht drin, wie man sagt, sondern das ist halt repetiert. Was sagt man auch gerne, was ne trockene, trockene, kurze ja? Ja, so ein bisschen Nerd wir sind natürlich auch in ner Ebene schon bisschen angelangt, hier dieses aber das macht ja nichts so. Das ist offensichtlich warum das nicht so gut ist?

Weil ja, wenn ich dann zum Beispiel ein Bub und ich hab irgendwie 4 5 stellen, wo ich den Code hinkopiert habe, dann muss ich halt finden auch ja und den und den gibt es garantiert dieser stellen, weil s halt paste ist. Und wenn ich dann vergesse, dann dann hab ich 3 gefixte und einen kaputten dann habe ich noch einen finsteren Bug danach so und das wird immer schwieriger zu finden.

Also an sich ist eine gute ne gute Idee, die ist aber total diskutiert und auch gar nicht so einfach immer umzusetzen.

Und ich sage gleich warum, wenn man nämlich jetzt in Microservices denken, also das funktioniert ja nicht so lange in melodischem angucke, dann muss ich mich darin nicht wiederholen, hab ich aber Microservices Container, dann ist dann schon nicht mehr olympisch und jetzt haben Microservices ja auch schon Teile von Funktionalität, die durchaus gerne mal überall wichtig sind Rest API dran was weiß ich datenbankschnittstelle oder oder ne oder Login System

oder so, das müssen die alle irgendwie machen und jetzt habe ich das Problem, weil ich habe ja quasi in Containern. Jetzt muss ich mich wiederholen, weil das sind halt einfach wie verschiedene Anwendungen. Ja, wie weit geht jetzt dieses System hier? Ja und wie mache ich das? Ja, das habe ich tatsächlich diskutiert. Das ist überhaupt nicht jetzt erstmal auf Anhieb gar nicht so

klar. Ja, da haben wir auch darüber nachgedacht auch n anderen Firmen, wo ich angestellte Entwickler war, nimmt man dann irgendwie Files und die teilt man dann auf, die werden geladen in die verschiedenen Microservices, so per Link und wie und so ne alles gar keine gute Idee, ja und tatsächlich hat sich. Ich glaube auch die Gesamtmeinung so etabliert, dass das Drive Konzept dann nicht mehr so wichtig ist. Ja also. Weil, dann wird das System so kompliziert vom vom von der Konfiguration.

Wenn ich jetzt anfange irgendwie Source aufzuteilen in verschiedene Microservices und so weiter.

Es gibt noch andere haben gar nicht Kid Kiss ja, dann wird es nämlich kompliziert, ja und das ist schlimmer, als dass wenn ich da ein bisschen Kot wiederhole, ja, also an der Stelle. Darf man es nicht zu eng nehmen? Jetzt muss man da ein bisschen andere Prinzipien auch angucken, und die haben ja alle nicht die Prinzipien, indem also in diesem Fall gerade bei Microservices überwiegt, das macht es nicht zu komplex.

K simple ja und dann dann lieber ein bisschen wiederholen und ja, dann muss ich halt irgendwie, wenn ich da n Fehler drin hab, dann muss ich da durch alle Microservices durch und da angucken OK dann weiter mit Nummer 5? Und dann verstehe ich tatsächlich nicht auf Anhieb, also wenn ich nicht softwareprogrammierer bin, also ich verstehe nicht auf Anhieb Convention over Configuration ein Konzept, was von David Heinemeier Hansen in seinem Ruby on Rails Webframework eingeführt wurde.

Erklär uns bitte was ist das eigentlich ne hohe Flugebene die diese Aussage hat, vielleicht etwas zu tun? Mit explizit und implizit also worum geht es?

Ich hab ja? Wenn ich, wenn ich Software schreibe, vor allem, wenn ich auf der Schene unterwegs bin, dann habe ich hier einfach ne ne riesen Dialekt an Möglichkeiten, das ist ja wie Sprache ja, ich mach n Beispiel klar, wenn du jetzt irgendwie was ausdrücken willst einen Zusammenhang und schreibst auf auf Deutsch oder auf Englisch dann hast du ja auch Gerrit 1000 möglichkeiten es aufzuschreiben ja.

Du kannst einfacher formulieren du kannst mehrere Sätze draus machen und so weiter und sofort ja, es hat auch was mit Kontext zu tun ja, also du willst was beschreiben? Mit einem bestimmten Kontext und jetzt ist die Frage holst du aus und schreibt explizit alles nieder so als, als hätte deinen Zuhörer noch nie irgendwas gehört von deinem Thema und du erklärst alles nochmal im Detail, dann wird es ein langer Text, der ist aber sehr explizit ja.

Aber extrem nervig zu lesen lang, du musst dann auch wieder, wenn du den quasi updaten willst, weiter durch Malen stimmt das ja oder du sagst halt das andere extrem, du machst ganz kurz sagst du OK, das ist sowieso alles Standard.

Sagst so OK, das wissen schon die Leute sind gar nicht diskutieren ich erwähne, wenn ich nichts dazu sage, dann wird ist das das, was die im Kopf haben ist schon das Richtige so ja also n bisschen schwierig zu sagen wie soll ich sagen also du bist irgendwo auf einem zum Beispiel hat wework gemacht und dann dann man kann auch sagen, das sind gute TVS ja, du wählst halt. Du willst halt ganz viele Sachen aus, die eigentlich konfiguriert werden müssen, aber du nimmst

halt super defaults. Von denen du meinst, dass die Leute auch denken, dass der Stand die Standard der Standardweg sein soll, wie sich das verhalten soll? Das Programm? Und dann gehst du dazu rüber, dass du quasi die Leute aufforderst, nur noch das, was abweicht vom Default vom Standard auszudrücken und den

ganzen Rest wegzulassen. Dann wird quasi das, was du schreibst, in einer Programmiersprache oder wenn du auch im Load bist ja. Total einfach und übersichtlich ja, tatsächlich passiert ja im Hintergrund noch viel mehr, was du auch hättest konfigurieren können, aber da sind halt quasi

die Vorgaben die Defaults, die greifen dann ja, das meint das ja Convention over Configuration, dann sparst du dir auch riesige Konfigurationsscripts und so weiter. Ob die XML sind und so weiter, weil sie sind quasi eigentlich im System drin. Ne, wenn das schick machst, dann kannst du trotzdem für Leute, die den dann auch selbst der Standard Standard ja nicht gefällt, sondern die da auch noch ne Ausnahme haben möchten die Möglichkeit bieten s zu tun. Ja, aber die versteckst du

erstmal richtig doll. Dies erstmal nicht, da damit es einfach wird gut, dann weiter zu Nummer 6 composition over inheritance, das ist wieder etwas, was du uns nochmal genauer erklären musst und das kommt aus dem Buch Design Patterns Elements of Reusable Object Oriented Software aus dem Jahr 1994 ja etwas älter, wieder richtig, aber hier kann ich mal kurz sagen dieses Buch, das wurde mir auch nahegelegt, das hab ich schon immer. Das hat dann noch einen anderen.

Das hat einen internen Titel, das Buch der Gang vor. Das haben viele Leute geschrieben. Das sind nicht nur Softwareentwickler. Sind tatsächlich echte Architekten dabei? Das ist ganz cool. Das Buch handelt davon von Design Patterns also ist ja auch der Titel, die sind halt gültiger als nur für Software, die gelten zum Beispiel auch für richtige Architektur und deswegen ist das ein ganz spannendes Buch. Das ist immer aber für Software

total bekannt geworden, ne? Das ist jetzt ein sehr technisches ne technische Weisheit, aber die kann man nicht mal unterbrechen. Eben also erstens Komposition Inheritance Inheritance heißt ja Vererbung ja, hier geht es um Objektorientiertes Programmieren und da gibt es im Prinzip diese

2 großen Möglichkeiten entweder. Erbe ich was von jemandem anderen oder ich nutze was von jemandem anderen, also ich habe quasi Eigenschaften von jemandem anderen und ich mach mal ein Beispiel aus der realen Welt, die Software nichts zu tun, stellt Euch vor Gerrit ist mein absolutes Vorbild, mein Idol. Ja, es gibt ja auch wir hier Influencer und so weiter. Ja, und ich würde gerne so sein, irgendwie wie Gerrit ja dann würde ich am liebsten alle Eigenschaften von Gerrit Erben.

Ja i ich spreche mal ich am liebsten so irgendwie in den Genen. So ne alle. Seine äußerst kann so im besten Fall noch so eine Art und Weise hätte ich das geerbt. Quasi ja.

Das ist der naheste Austausch zu einem Vorbild, ja, ein Vorbild im Computer ist ne Klasse ja, die kann ja irgendwas ja die ist meistens zum Beispiel irgendwie Netzwerke oder irgend sowas kann zum Beispiel ne ne Klienten klasse, kann zum Beispiel Verbindung Server aufbauen oder irgendwas und jetzt bin ich jemand anders hab noch hab noch meine eigenen natürlich meine eigenen extra Features also bin nicht die bin nicht der Client selber so ja möchte jemand sein der das auch kann.

Ja, dann kann ich erben von dieser Klasse ja also wie gesagt, ich will die Eigenschaften von Gert Erben, ja

kann das auch eine Klasse? Und nun erstmal die Möglichkeit aussortieren und wenn ich das nicht mache ich nicht haben will, dann könnte ich auch sagen AOK, ich bin schon ich selber, ich habe das nicht, ich Erbe Gerrit nicht, aber ich möchte, ich möchte seine ganzen Features und was er so kann nutzen so ja also ich habe den Gerrit in der Tasche ja und jetzt muss ich jetzt kann ich nicht einfach und automatisch, sondern ich muss quasi mir n paar Sachen noch aneignen so zu sein wie Gerrit

aber ich kann ihn benutzen ja, ich hab nen Referenz zu Garrett könnt ihr mal fragen und dann antwortet der für mich oder so ja, das nennt man Komposition ja, also ich habe quasi nur den

Handel an dich. So ich hab dich im Arm so und kann dich immer fragen was brauch aber ich benutze das für meine eigene interne Kommunikation, ne jetzt kommt mir sofort das oder das Prinzip von einer in den Kopf, dass ich einfach irgendwo was aufrufe und ausführe und nutze letzten Endes, um es dann wieder bei mir weiter zu verwerten genau das das Prinzip ist richtig bei der API nur also die Flughöhe ist dann anders. Diese Konzepte besprechen wir dann quasi innerhalb eines Stücks Quellcodes.

Das ist ein bisschen enger an einem Quellcode, man hat wirklich mit Klassen und Objekten zu tun. Wir hatten auch schon Erfolge genau und aber aber das Designprinzip. Ist genauso wie du es gesagt hast geritten. Genau es ergibt sich und das hat man über lange Zeit rausgefunden. Das ist typischerweise günstiger. Ist zu komponieren also eine Komposition zu machen als zu

erben? Ja, wenn nicht Erbe, dann habe ich halt allen Trash mit so ich kann nichts machen, ich halt genau alle Eigenschaften ja ich ich kann auch nicht mehr modifizieren, dann dann dann bin ich halt zu einem gewissen Teil.

Gerrit so ja und mein eigenes Wesen kommt dann vielleicht ein bisschen kürzer so ja, es gibt noch ein großes Problem damit, wenn ich vor allen Dingen nicht cool finde, sondern jetzt irgendwie noch jemand anders ja. Dann muss ich auch von dem Erben und jetzt habe ich auf einmal 2 Leute, von denen ich Erbe und die haben vielleicht Eigenschaften, sind dann doch gar nicht mehr so orthogonale widersprechen sich vielleicht und so weiter und dann komme ich in Konflikte mit mir selber ja,

und das ist tatsächlich in der Software auch so. Ja und es ist einfach besser zu sagen OK, ich hab hier ich hab hier den Gerrit und ich hab vielleicht noch den Lars und den und die Annette oder irgendwie ja auch immer und die habe ich irgendwie greifbar und ich kann auf die zugreifen, aber einfach in Komposition so ja und das ist hat sich herausgestellt, dass das viel cooler ist. Warum ist das gar nicht so offensichtlich? Und warum ist das so?

Was ich gebe das jetzt mal als Beispiel die Programmiersprache Java, die kennt ja wahrscheinlich jeder schon mal gehört ja so eine der bekanntesten Programmiersprache auf der Welt. Wie basiert aber ganz krass auf diesem inheritance Projekte? Das ist tatsächlich so, dass jedes einzelne Objekt in Java von einer von einer rot Klasse sogar erbt. Ja, das ist so aufgebaut, dass quasi die das immer wieder vererbt wird, sogar das Macht,

aber im Nachhinein die Programmiersprache doch sehr kompliziert, ja, und dann gibt es multiple Harrys mit mehreren und so weiter und sofort das ist einer der größten Kritikpunkte dieser dieser dieser Sprache und dieses dieses Konzeptes, das ist zu stark auf Vererbung setzt und zu wenig auf Komposition soll das steckt hinter dieser Weisheit ja alles klar.

Also Komposition ist der Vererbung zu bevorzugen, so ist es in einem Satz zusammengefasst was ich gerade 5 Minuten lamentiert hat ja, ich habe es einfach nicht einfach übersetzt jetzt, ich hab das verstanden ja gut, es deutet sich schon an, dass wir hier raus 2 folgen machen werden, ja schon zwischen und wir machen einfach weiter machen die Einzelheiten 0 7 duplication or the one Abstraction also die Duplizierung ist der falschen Abstrahierung zu bevorzugen, so

wieder frei übersetzt aus einem. Talk von Sandy Metz all the little Things and the Post oder unter Post the Wrong Abstraction, also Sandy Metz, ist hier für verantwortlich ist eine Frau, die das Handy. Ja, genau wollte ich nochmal sagen es ist ja nicht so oft. Deswegen muss man herausstellen, dass man in der Software Entwicklung gibt es meiner Meinung nach viel zu wenig weibliche.

Personen. Aber egal genau das ist auch ne ne Weisheit die das 3 Konzept ein bisschen einschränkt, steht ja quasi schon drin, ne also das wäre quasi repetition ne, die steht im Widerspruch zu yourself. Die holt quasi diese Regel auf die richtige Ebene wieder ab.

Also wenn ich mich nicht wiederholen will, dann muss ich oft nendel höher gehen in der Abstraktion ne also Sachen standardisieren und wenn ich standardisieren, überbügeln ich manche Sachen ja immer, wenn ich abstrahiere, dann wird der vielleicht das Detail nicht mehr ganz richtig für alle Sachen.

Es ist ja auch so ne, das ist ja alles sehr konzeptuelle Grundlage ich so ja was wir hier sprechen muss oder manchmal wenn ich zu abstrakt wenn ich zu standardisiert unterwegs bin, dann habe ich die Details sowas von über gebügelt, dass die dem Anwendungsfall auch nicht mehr gerecht werden, ne dann bin ich

zu stark abstrahiert. Ja, und dann komm ich ganz schlecht von dieser Abstraktionsebene, weil wir müssen ja denken wir Code schreiben, dann ist es so, als hätte ich irgendwie ein Lied komponiert, so ja, ich fand das ja alles bezieht sich aufeinander die Komponenten und hab ich erstmal ein falsches Abstraktionslevel erwischt.

In meiner Anwendung und will das wieder ein bisschen näher ranbringen an den an den an den Anwendungsfall ist gar nicht so einfach, weil alles miteinander zusammenhängt ja. Hier sagt die Weisheit quasi Pass gut auf, dass du nicht zu krass abstrahiert so ja, es gibt noch andere Weisheiten, die

übrigens gleich mein Mann sagen. Versuche nicht alles zu verstehen und alles zu abstrahieren das ganze Leben ja so das krasse Beispiel wäre die Weltformel so ja, das ist die Abstrakteste Aussage, wie alles zusammenhängt. So ja, das ist natürlich man hat natürlich so auch als Softwareentwickler oder überhaupt als Mensch irgendwie so. Das Gefühl, so boah, das müsste ich eigentlich noch. Wo sind hier die großen Linien,

die ich zusammenziehen kann? Wie ist das abstrakter zu formulieren, so das Problem ja, aber da verliere ich manchmal

vor allen Dingen zeitlich. Und und zweitens verliere ich mich dann einfach in der in der Usability, für das eine kleine Problem ja, wir dürfen nicht vergessen wir lösen ja mit mit Software nicht die Welt, sondern eigentlich immer viele kleine Anwendungsfälle. Und der Softwareentwickler, der das ständig macht, der tendiert gerne dazu irgendwie auch, was gerne zu über abstrahieren oder irgendwas komplexer zu sehen, als es eigentlich sein müsste so das kennst du Gerrit von den

Problemen, ne also es gibt ja auch Cartoons wo du willst irgendwie individually haben und ich weiß nicht ob ihr dieses Beispiel dieses Spiel kennen, ja also ich der Kunde will einfach ne Schaukel haben so und der Softwareentwickler macht daraus den Wahnsinn so ja, weil weil der denkt so OK, das kann ich irgendwie schon mitteilen, dass schwingen und fängt an ein riesiges Ding zu bauen, damit du später aus der Schaukel vielleicht noch irgendwie nen Bananen.

Gut dann machen kannst oder was weiß ich so ja, so denken halt die Softwareentwickler und dieser Wahrheit sagt Halt so Pass auf, dann baust du lieber 2 schaukeln, die mit den verschiedenen ne, also einem schaut und das andere ist für Babys, die nicht ausfallen müssen, schade, aber deswegen

musst du jetzt nicht. Dann machst du die und die Seile und das Gestell ja die die die sind dann doppelt ja die ersten 2 mal codiert, aber versucht die Schau zu erfinden, wo dann irgendwie mit Adapter und Anschluss und und so weiter das wird zu kompliziert, um da die Softwareentwicklerin entschuldigen. Ja, dieser Cartoon geht weiter. Da bringt auch Sales und, und und. Produktmanagement bringt auch eine Menge Verein ja genau ganz

genau, aber ich weiß genau, was du meinst ich glaube, die viele Zuhörer haben auch schon schön, wenn die Achterbahn darstellt oder sowas ja ganz genau ist der Klassiker das Ding so prima ja spannend, dass ich das in Teilen oder ich würde sagen ergänzt 3 ja also es schränkt das eben zum Teil ein und ergänzt das an der richtigen Stelle den nächsten find ich richtig cool und es hat auch nen Autor den ich sogar kenne. Ich persönlich natürlich wer ist der Linus Torvalds, der ich

täusche? Erschaffer von Linux und auch Git. Genau 2006 gesagt Bad Programmers Warrior about the code good programmers various data structures and the relationships also. Schlechte Programmierer kümmern sich um den oder sorgen sich um den um den Code gute Programmierer sorgen sich um Datenstrukturen und deren Beziehungen untereinander. Schieß los, es ist so, wie es da steht.

Ich weiß gar nicht da kann nicht mehr viel zu sagen, das ist irgendwie eigentlich selbsterklärend ich kurz machen Punkt aber genau wir hatten ja die Folge auch ein bisschen über die Datenstrukturen austauscht das ist die Komplexität ja also und da müssen die Gedanken rein, wie wenn ich gute Datenstrukturen hab und diese Weisheit gibt es in Abwandlungen ja. Data structures First und so weiter. Das ist die hohe Kunst der ich

hab halt ich sage ich ja immer. Wir haben Daten und wir haben Funktionalität, wir haben Algorithmen und Daten und die Daten gut darzustellen und zu beschreiben, dass sie ohne viel Aufwand ohne viel Umformatierung jedes Mal gut von den Funktionalitäten in Algorithmen genutzt werden können.

Ist total wichtig, ja und die Daten sind ja auch gerne mal volatil, die müssen gut und effizient gespeichert werden können in Datenbanken und die müssen gut und effizient ausgetauscht werden können in Austausch, Files in Formaten und das können sie nur, wenn ich sie sauber und gut beschreibe und dann die Daten Beschreibung quasi.

Ja, auch quasi in sich. Eine Single Source of Truth trägt ja, dass ich da auch keine quasi Überlappungen habe, ja, dass ich das, dass ich, dass das nicht zweifelhaft ist, was das jetzt ausdrückt, sondern das ist mit kleinsten Ausdehnungen effizient, alles gut beschreibt so das ist die sauber getrennt voneinander speichern kann und neuen Beziehungen setzen kann. Ja das ist es klingt so einfach ist sehr kompliziert, ja und wenn das gut gemacht hat, dann kann man quasi und das sollte

man tatsächlich zuerst machen. Über die Daten nachdenken wie sehen die aus? Und dann kann ich darum Funktionalität, Design e, die damit gut umgehen kann ne, ich musste gerade denken an Texte die man hier und da mal

verfasst, also zum Beispiel eine Studienarbeit oder eine Bachelorarbeit. Diplomarbeit jetzt vor kurzem einen Förderantrag, ja den wir geschrieben haben für ein Projekt, wo wir auch uns erstmal eine gute Struktur tendenziell überlegen sollten um dann auf dieser Struktur aufbauen einfach die Lücken zu füllen oder ein guter Vortrag den man irgendwo hält oder sowas in der Art oder ein Pitch irgendwie in einem Gerüst folgt und dass man dann so ein bisschen auffällt also

das ein Stück weit zu übersetzen in andere Bereiche. Das fällt mir dazu ein. Kann man das vergleichen, können wir vergleichen ja kann man, so kann man so stehen lassen, genau ja, dann weiter zum neunten oder zur neunten Weisheit von Robert C Martin in der Clean Coal Collection und den Übersetzer nicht das überlasse ich dir, weil every time you recommend you and feel the failure of your ability of expression.

Ich glaube, ich verstehe es schon, aber ich also was da steht, aber ich checks nicht richtig ja, ich sag mal auf Deutsch also. Immer, wenn du dich dabei ertappt, dass du Kommentare in deinen in deinen Quellcode einfügst. Dann solltest du dich dann solltest du dich mal kurz zurücklehnen darüber nachdenken, was da eigentlich tust und überlegen, ob du nicht das viel besser hinschreiben kannst. Gleich im Code und den Kommentar streichen kannst. Ja, ich liebe diese Aussage und

ich bin da sehr. Ja, wie soll ich sagen, ich bin da sehr schon geprägt, dass da nicht viele andere Meinungen zu neben meiner und neben dieser dieser dieser Weisheit steht. Es heißt so viel wie schreib gefälligst deinen Code so sauber hin, dass du ihn lesen kannst, fast wie ein Buch ja, und zwar ohne, dass du dir da irgendwelche extra Kommentare

dran musst machen musst. Ja, die wieder erklären, was der Code eigentlich sein sollte ja. Es geht dahin, dass man sagt, wenn du einen Kommentar schreibst, dann, warum schreibt man. Kommentar Es ist ja auch im normalen Text vielleicht so, ne schreibt es können ja PF oder von Word und so weiter du schreibst irgendwie und dann schreibst du noch Kommentare hin. Und vor allem wenn du zum Beispiel 2 arbeitest, dann gern wieder mit mehreren, wenn wir so an einem Dokument arbeiten.

Was für mehrere ist oder was gleichzeitig bearbeiten, dann arbeitet man ja gerne mal schreiben konnte, was hier los und so weiter und warum schreibst den Kommentar ein, weil du vom Text her noch nicht gerafft hast, was hier los ist ja, oder weil du noch was fehlt oder irgendsowas.

Dann war der Text nicht klar genug, ja, ist der Text so klar, so glasklar und ohne Fragen, dann brauchst du kein Kommentar, schreiben mehr und das heißt, dass wir Software schreibt, seinen Quellcode so klar, dass das ohne Fragen und ohne Kommentare für jeden verständlich ist nur für dich.

Ja, das ist total wichtig. Wir schreiben ja Software im Team nicht nur alleine das also das ist immer wie ein geteiltes Dokument, ja und jeder der da, der auf das erste Mal das liest, der muss in der Lage sein, es sofort zu verstehen, ne? Und hast du den Kommentar drin, kannst ja machen, ja, aber dann musst du auf jeden Fall nochmal refactory isieren. Das Thema ist ja auch eine Leidenschaft von mir also.

Ich sag ja gar nicht, dass du das mit dem ersten Anlauf können musst, kann ich auch nicht so ja und manchmal ist auch die Zeit nicht da ist zu tun, weil es gibt ja auch Kunden und du musst was fertig machen und so ja. Und dann hast du es nicht besser gekonnt dann schreibst du halt irgendwie Krempel hin, der wurde schon weißt Boah von hinten durch die Brust ins Auge funktioniert so ja, aber man muss auf jeden Fall nochmal dran schreiben Kommentar nochmal vorbei an dieser Stelle ja, das

geht noch in den und den auf jeden Fall schief so oder du hast noch gar nicht analysiert wo es irgendwie noch knallt ja.

Und dann ist es total wichtig, dann wirklich mal vorbeikommen das Faktorisieren so ja und schmeiß den Kommentar weg ja, ich freue mich immer, wenn ich irgendwie so ich hab auch ich hab in meinem Code ganz wenig, aber ich habe Kommentare drin und ich gehe immer, wenn ich wenn ich das mache ich immer wieder regelmäßig durch und gucke ich mir immer löschen kann, weil ich einfach der drunter ist. Besser schreibe total wichtig ja, für kann ich gar nicht sagen. Wie ist also das war jetzt

irgendwie ganz in diesem? Aber für ein gesundes Softwareprojekt total Essential in meiner in meiner Meinung ne, ich vermute es gilt die Einschränkung, dass das für jede und jeden Softwareentwicklerin lesbar sein soll, ja jetzt nicht für mich ja also der kommt, man muss die, man muss die Syntax und die Sprache beherrschen genau die Vokabeln kennen ja und dann das ist schön, dass du sagst also da gibt es ja dann

wieder auch. Wie soll ich sagen, ne also so ne Programmiersprache ist ja hat ja auch seine Eigenheiten und seine Grammatik und seine speziellen Konstrukte und jetzt ist die Frage für jeden Anlass schon gesagt ne, also auf jeden Fall für jeden Softwareentwickler das ist das schon mal gesetzt mit dieser Weisheit. Jetzt ist die Frage für jeden Softwareentwickler grundsätzlich oder jeder, der diese Sprache sehr gut kann.

Das ist auch eine Riesendebatte immer so ja also es gibt ja verschiedene Programmiersprachen und die sind manchmal auch tatsächlich so unterschiedlich wie echte Sprachen. Ja, und er habe ich noch nie irgendwie was weiß ich C plus plus gesehen? Dann verstehe ich das auch nicht selbstwickler. Ich kann fließend javascript programmieren. Kein Problem kann Werbeflächen richtig schön jetzt krieg ich so ein C plus plus Code dahin, ne.

Das ist dann erstmal Fremdsprache, obwohl ich eigentlich Ahnung habe ich Software geht so. Und jetzt ist die Frage, ob es dann auch jemand anders lesbar sein, ich würde sagen Nein, ne also ich und sogar mit Absicht ich würde auch sagen nutzt halt alle grammatikalischen und Fremdwörter dieser Programmiersprache geht davon aus, dass es nur für jemanden, der auch sehr gut diese Sprache kann, lesbar ist, ja. Dann, und das ist aber nicht das

ist nicht kommen kommen. Wie soll ich sagen gemeinschaftliche Meinungen ja, haben andere andere Meinungen als ich? Also deswegen gibt es die verschiedenen Programmiersprachen, weil die halt verschiedene Sachen sehr gut sind. Und du manchmal ganz kurz was ausdrücken kannst, weil die Programmiersprache, die von der Grammatik her erlaubt, ja in anderen geht, dann vielleicht nicht. Also jetzt versucht aber dann nicht irgendwie nur damit, dass

jeder lesen kann. Jeder Hansel und Kumpel, der meint, er könnte Software entwickeln, deswegen irgendwie so zu programmieren, dass ich nur die rudimentären Features von der Programmiersprache und damit auch jeder lesen kann, ne? Dann finde ich schießt man sich auch ins Knie. Weil weiß ich nicht, dann nutze ich ja nicht die sich h die Programmiersprache als Technologie ausgewählt um irgendwas zu tun so ja mit also musst du die bitte.

Auch bis zum maximalen Extend und derjenige, der es dann nicht versteht. Aber deswegen, weil eigentlich die Sprache nicht beherrscht, der soll dann nochmal bitte ins Studium gehen und die Sprache gut lernen kann das auch lesen

wie ein Buch? Da werden vielleicht ein paar Leute sagen ja heißen, das ist aber ne krasse Ansage so aber ja ist halt so sich so also warum sollte man sich einschränken in in in in den Möglichkeiten die dann gegeben sind na ja also ich mein Beispiel aus dem Leben, ne also die deutsche Sprache ist ja auch kompliziert, ja und wenn die Juristen sich nicht einschränken, dann verstehst du als Normalsterblicher auch nix mehr ja, da sagst du ja auch jetzt pass mal auf ihr könnt ihr

das bitte mal formulieren für Normalsterbliche ja?

Und dann kriegen die aber haben die gar keinen Bock drauf, weil die haben halt die haben halt ihre Vokabularien und so weiter und die sind richtig ja, dann muss ich halt ein bisschen arbeiten ja und was ich sage ist quasi liebe Juristen bitte schreibt eure Texte im juristischen Deutsch so ja und versucht einfach zu schreiben so ja ne, aber was ich sagen will, wenn du den wirklich in der Tiefe verstehen willst und sowas zu beitragen willst juristischen Text dann sage ich halt OK, dann

musst du halt kannst leider nix machen, dann musst du halt zum gewissen Maß an diese diesen Gloria aneignen. Ansonsten bringt auch nichts zu suchen. Im Text soll das macht es nicht besser. Ja, da bin ich voll bei dir. Im Zweifel ist ja ein juristischer Text. Dafür andere Juristen, und das ist ja auch explizit ganz klar an der Stelle und man kann das natürlich verstehen, aber nicht in allen Auswirkungen, die die Folgen abschätzen, ja, von so einem juristischen Text als Laie

dann eben. Cool OK, dann haben wir 2 also nochmal 10 und 11 jetzt kommen die sich mehr Richtung UX, also User Experience orientieren und da standen wir mit User Centricity, der lautet Put the users needs first and make decisions based on what you know about them and what they want from the product? Ich versuchs nochmal frei zu übersetzen. Also setze die Anforderungen der Nutzer an erster Stelle und basiere deine Entscheidung darauf, was du über die Nutzer und Nutzerinnen weißt.

Und was Sie an dem Produkt möchten oder erwarten genau schieß los also, wir haben jetzt hier keinen keine Quelle, vielleicht noch in der Beschreibung ja, es ist vielleicht ich weiß nicht, ob sich eine Quelle das ist so grundsätzliche Regeln l user centricity ich finde, ich hab Pommes ist eine Binsenweisheit, könnte man sagen klar sollen wir den Nutzer in den Mittelpunkt. Jetzt aber muss auch mal sagen

so ja, wann. Es wird viel nachgedacht über Software und wie man das machen kann und man man ertappt sich dabei irgendwie das Produkt zu bedenken. Auch so, wie es irgendwie funktioniert und die Datenbanken und so weiter. Alles nicht so wichtig ja und ich finde dieses Thema so wichtig, weil also so designen wir auch mit unseren Kunden Produkte. Ja, ich ich kann also, ich denke selber über eine Software und über deren Abstraktionslevel was wir haben wollen darüber nach,

indem ich. Vom User her kommen ja. Und ganz zurückgehe bis zu den bis zu den Datenbanken bis zu den Datenmodelle. Ich finde, das ist A und o bei einer guten Software, man muss sich vorstellen was was wird. Der Endnutzer klicken, haben wollen, sehen, wollen, verstehen wollen. Ne und wenn wir mit dem Kunden auch wenn Slow ist mit dem Kunden besprechen, wie die aussehen soll, dann fangen wir int an. Und das funktioniert hervorragend ja, wenn man.

Wenn man, wenn man nicht vom Front, also selbst wenn Fronten anfängt, nur die Knöpfe macht, dann kommen die ganzen wichtigen Fragen so ja, ach so, vielleicht müssen wir noch, können wir zurück, kann man das nochmal löschen oder nicht? Ist dann gesetzt? Und so weiter und hat man das

Frontend designed? Dann hat man schon mal den Grundlagen roten Faden für alles andere gelegt ja, also, das ist total wichtig diese Weisheit ja denkt, dass von der Nutzbarkeit her und dann hast du auch ne Anwendung passiert so schnell Problem nicht, das kann ich extrem bestätigen mit mit ganz aktuellen Beispielen aus unserer Aus unserer täglichen Arbeit bei der heißen Ware vielleicht ein kleiner Anekdoten, vielleicht für die Zuhörer auch ganz spannend.

Wenn wir jetzt Kundenprojekte angehen und teilweise auf unsere eigene Plattform für oder mit den Kunden gemeinsam Apps kleine Programme entwickeln, haben wir uns jetzt den ja den Prozess angeeignet, dass wir tatsächlich Int starten, was sich im Low Code. Tool extrem gut machen lässt und einmal erstmal uns über den User Gedanken machen also wie wird das Produkt nachher verwendet werden die Applikation das Fundament aufbauen, mit den Kunden in den Austausch gehen?

Ob das so passt oder ob wir noch anpassen müssen und immer wieder reisen in die eigenen Wünsche und Anforderungen denn letztendlich ein User und wenn das Mal geschehen ist wie das

Backend bauen in Anführungsstrichen, also sprich auch wieder da die Funktionalität reinbringen, eigentlich die Applikation heißt nicht, dass man nachher das nochmal anfasst, ja und vielleicht basierend auf echten Tests dann natürlich Anpassungen vornimmt. Aber erstmal hat man irgendwie Grundlage, über die man spricht und wir verwenden kann. Dann macht das letzte und 11.

Und der sonstigen Weisheiten, bevor wir dann eigentlich zum Senden of Python kommen, ist die Konsistenz consistency, also b consistent with what you users expect? Also sei konsistent mit dem, was deine Nutzer erwarten, wenn ich darüber nachdenke, dann stelle ich mir vor wie keine Ahnung irgendwie kann ich Rechtsklick, mache. In der Applikation soll immer ein Kontextmenü auftauchen. Oder irgendwelche Dinge, die ich machen kann oder wenn ich. So so eine Strukturierung mehr oder weniger User.

Das User Interfaces passt das so ist genau das genau das was meint es gibt ja immer verschiedene Wege, also sowohl visuell als auch im Code irgendwie die gleichen Sachen zu machen. Ich nehme halt irgendwie genau wie du gesagt hast. Entweder ist es im Rechtsklick und hab Kontextmenü oder man klickt es nur einmal und irgendwas auf. Wie auch immer, es hat alles vor und Nachteile, aber entscheide dich halt quasi innerhalb einer

eines Ökosystems einer. Einer Sphäre für eine Art und Weise, und benutze sie überall gleich ja, ansonsten wird deine Nutzer quasi ihre, wenn es andauernd irgendwie anders ist so. Für die US kann sich sehr gut vorstellen, dass das total Sinn macht, deswegen hab ich nochmal gemacht natürlich viel mehr regeln, so aber ich will mal sagen, dass das für für den Code für das Einschreiben von Sachen für mich auch total richtig ist und ganz wichtig.

Und ich bin auch sehr akribisch, ihr merkt schon nicht clean Code und solche Sachen sind bei sind bei mir irgendwie ja, ich weiß auch nicht irgendwie total wichtig, denn jetzt wieder wenn ich ein schreibe, da kann ich auch wieder haben wir schon mal gehabt, ich verschiedene Arten ausdrücken ja, ich könnte zum Beispiel ein schreiben ich einfach da, wo ich mein Publikum duze ja und ich hab n Text ich sie ja.

Ist eigentlich egal ja, oder? Auf einer Webseite stellt sich über die sprechen wir sprechen wir unsere unsere Visitors an ja, wenn ihr einfach geduzt auf Deutsch oder wenn die so ja. Ich würde mal sagen klar kann man sich irgendwann entscheiden, wenn du dich entschieden hast, dann sieh halt immer in jedem Textblock oder du sie halt immer, aber mischt das nicht ja so und im Code im Code gibt es Tausende.

Also wir schreiben ja wie ne, hab ich gesagt ja, wir haben 1000 Möglichkeiten, etwas aufzuschreiben und dann auch den Text zu formatieren. Ich gehe so weit, dass man, dass ich sogar formatieren Art des Aufschreibens das gehört zu mir alles zu consistency, das muss man einmal genau festlegen und festsetzen. Gott sei Dank geht es heute einfacher, weil unsere Integrated Development Environment also quasi unsere cleveren Editoren, die uns

helfen, Software aufzuschreiben. Die haben sowas wie Auto formatieren und so gibt es ein bisschen einfacher, da muss man sich nur nur einigen, welches Format man möchte. Es gibt immer noch verschiedene. Ich kann Java Script verschiedene Arten formatieren. Aber hier finde ich auch total wichtig macht das einmal und dann wird die gesamte Codebase, egal wie groß das Projekt ist, zieht das gleichmäßig durch ja und zwinge alle, die im Team mit entwickeln, das Gleiche zu

machen. Die haben alle in der jeder hat eine Vorliebe ja jeder der eine setzt die Kammer in nächste Zeile, der andere hören und so weiter. Das gibt religiöse Diskussionen ist total gruselig. Ja, da muss ein Diktator sagen, so wird es gemacht und nur so geht ein neuer Code in die Codebase. Ja, s hat diese Konsistenz zu befolgen. Ob dir das passt oder nicht ja zu vorher einmal entschieden,

dann demokratisch machen. Kompromiss finden irgendwie, wie man s macht und einmal entschieden ist, muss es exakt gleich sein, denn das führt auch und das ist total Key. Es muss alles lesbar bleiben, ganz einfach lesbar so einfach wir haben ein komplexes Thema mit Apps, ne und die Bedienung ist komplex. Das anschauen ist komplex. Der Code ist komplex. Also müssen wir alle, ich komme zum Schluss dieser Folge. Wir machen auf jeden Fall dann nächsten Folge. Wir müssen dafür sorgen.

Es passt auch zum zum zum Podcast Thema einfach komplex, ja Komplexität rausnehmen, indem wir das rausnehmen, was wir können und vereinfachen also. Lasst uns doch bitte immer einen Standard folgen, also die Lesbarkeit erhöhen ja die Nutzbarkeit erhöhen, indem wir mit da schon mal die Dimensionalität quasi runterdrehen, ja, indem man nicht alles erlauben, ja und nicht alles wiederholen ja.

Das ist total wichtig, also Lesbarkeit und und Verständnis darf sein, dass man sich im Moment erstmal einlesen muss. Auch in der Anwendung finde ich immer das kann vielleicht irgendwie ganz komisch sein am Anfang ja ganz neu, ja ganz neues Erlebnis so und du denkst du bist 5 Minuten lang oder 10 Minuten lang bist du völlig verwirrt so was ist hier los. Ja, wenn du einmal dahinter kommst. Und dann alles total elegant und konzeptionell ineinanderpassen

konsistent ist. Dann wird es richtig schnell richtig gut ja, also du sprichst über den Code, insbesondere dass der diese Konsistenz aufweist. Ich würde da beim UX oder bei der bei mir Interface sagen darf eigentlich keine 5 Minuten

dauern. Ich würde sagen, das ist dann schon viel zu lange, wenn man 5 Minuten braucht, um einen Tour in seiner Grundfunktionalität zu erfassen oder oder wie man dort etwas tut schon verloren aus meiner Sicht da verehrter Herr, wir sind die Zeiträume etwas größer gewählt bei bei Skype, da kann man schon mal ne halbe Stunde sitzen und irgendwie

erstmal. Aber ganz viele Zeilen Code lesen und man weiß doch gar nicht, was los ist, so ja, da würde man jetzt im Endeffekt vielleicht eher intuitiven User Interfaces sprechen ja, wobei das ja auch schwieriges Konzept ist was Software angeht, weil so richtig intuitiv ist die Software nicht, weil solange gibt es noch nicht, er hat das schon sein Gehirn verankert ist dennoch versteht man irgendwie warum aber klar Konsistenz ist in beiden Fällen extrem wichtig,

wenn man sich mal entschieden hat, so, dann machen wir einen Cut nach diesen 11 ja zusammengewürfelten und und von Burkhardt und mir kuratierten Weisheiten um dann nächste Woche über die. Grundprinzipien für das Schreiben von Computerprogrammen oder die Sense of Python von Tim Peters nochmal zu sprechen und diese einzeln durch Züge bis

nächste Woche Tschüss habe ich. Vielen Dank fürs Zuhören dieser Folge von einfach komplex die Folge gefallen dann lass uns doch ne gute Bewertung da oder Teile die Folge mit jemanden aus seinem Netzwerk für Kritik zufolge Anregungen und Fragen für neue Folgen, freuen wir uns auf deine Email anpodcast@web.com Abonniere jetzt unseren Podcast um keine Folge mehr zu verpassen bis zum nächsten mal Tschüss aus Hamburg h.