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.