Sie lauern in der Softwareentwicklung überall Anti
Patterns, die heimlichen Saboteure eurer
Softwareprojekte. Sie tarnen sich als schnelle
Lösungen, führen aber geradewegs den technische Schulden und
meistens auch Chaos. In dieser Folge reden wir über
die gefährlichsten Anti Patterns, reden darüber, wie sie
in der Literatur genannt werden und zeigen euch, warum sie nicht
nur euren Code, sondern vielleicht auch eure Projekte
komplett ruinieren können. Und damit ganz, ganz herzlich
willkommen zu einer nigelnagelneuen Folge vom to do
Cast, dem Developer Podcast auf Deutsch mit Malte Lantin und mit
mir Robin Manuel Thiel. Heute geht's um Anti Patterns
Anti Patterns kommt so ein bisschen drauf an, ob man's
deutsch oder Englisch ausspricht und ich glaube, wir alle haben
sie schon ganz oft gesehen oder vielleicht auch nicht gesehen
oder ist so was begegnet? Wir haben beide so bisschen in
der Recherche von dieser Folge gesagt, Hey.
Lustig, dass diese Dinge, die uns im Alltag schon häufiger
begegnet sind, tatsächlich irgendwie einen, teilweise auch
lustige Namen haben. Bin ich mal gespannt, da gehen
wir gleich ein Paar mit euch durch, bevor wir einsteigen,
aber wie immer ein kleiner Rückblick auf die letzten, die
letzte Woche und die letzten Wochen und dann Dankeschön,
Dankeschön erstmal an Rainer Rainer hat uns nämlich 5 Kaffee
spendiert. Vielen Lieben Dank, das freut
uns immer sehr, wenn ihr uns Kaffee ausgebt, wenn ihr auch so
cool sein wollt wie Rainer, dann und euch die Folge gefallen hat,
dann findet ihr unter jeder Folge auch so einen kleinen Link
zu Bimir Coffee tut es wie Rainer und ladet uns auf einen
Kaffee ein, da freuen wir uns immer sehr.
Dankeschön. Und dann vielleicht noch ein
kleiner Rückblick auf das, was zwischen der letzten Folge, wo
wir über AI Coding Assistance gesprochen haben und heute
passiert ist. Wir haben nämlich zum ersten Mal
ein kleines Video separat von einer Folge aufgenommen, weil
ihr habt sicher alle mitgekriegt, die große Welle
durch die Tech Industrie ging als aus China das neueste
Sprachmodell Dpcr One kam. Und das hat natürlich den ganzen
Markt erschreckt. Wir haben uns das uns natürlich
auch angeschaut und wir wollten das gern n bisschen einordnen,
haben wir gedacht, wenn wir da ne ganze Folge dazu machen, ist
es vielleicht schon zu spät, das interessiert sich keiner mehr
dafür oder ihr habt ohnehin schon alles gehört und von da
haben wir gesagt wir machen n kurzes Video lasst uns gerne
wissen ob Ihr das Video gesehen habt, wir haben es auf unseren
Social Media Kanälen Tik tok, Instagram, linkedin
veröffentlicht. Und sagt uns gerne, ob ihr es
gesehen habt, ob wir auch mehr solche ad hoc Videos mal machen
sollen zwischen den Folgen, weil wir fanden es sehr wichtig das
Thema einfach kurz einzuordnen, auch für euch noch mal ein
Update zu geben, bevor wir jetzt heute in die nächste Folge
einsteigen können. Genau das ist so unsere Methode.
Oder soll vielleicht noch mal unsere Methode werden, so wie
malte ja gesagt hat, so kleine News, die irgendwo passieren
noch mal einzuschieben, wo es entweder zu lange dauert, bis
wir das nächste Mal eine Folge machen oder die vielleicht auch.
Gar keine ganze Folge füllen. Ich weiß nicht, ob wir in einem
developer Podcast wirklich 2030 Minuten lang nur dann über Deep
Sea R One reden wollen, deswegen haben wir so ein bisschen
eingeordnet. Warum war denn da eigentlich die
Timeline voll, ist es ja vielleicht auch mehr als nur
wieder ein anderes Model, was irgendwie gut war.
Ja, würden wir uns super freuen auf Feedback dann weil wir haben
Lust sowas auch irgendwie öfter zu machen, lasst uns das gerne
mal wissen. Und deswegen auch jetzt hier
diese Folge mal ein Thema glaube ich ganz ohne AI, auch weil
malte mir verboten hat hier jede Folge mit euch über KI zu reden.
Ich wir hatten so eine Diskussion EY hier malte Deep
Sea One ich ich will eine Folge dazu machen und du hast mich
dann direkt gebremst und gesagt ich weiß nicht ob das eine ganze
Folge ist und darauf kam dann auch irgendwann diese Idee
deswegen. Ja, eine eine nicht KI folge.
Das ist ja auch selten geworden in der aktuellen Zeit.
Ich merk aber auch gerade als malte mich darauf aufmerksam
gemacht hat, dass wir schon sehr viel über KI reden und da
irgendwie, dass es so wahnsinnig viele Neuerungen gibt, auch
wahnsinnig viele Neuerungen, die uns als Entwicklerinnen und
Entwickler betreffen, dass ich auch so n bisschen KI müde
geworden bin irgendwie, ich hab das mit diesem Deep Seek Modell
auch gemerkt, so ja es ist n weiteres Modell und ich fand das
Modell eigentlich überhaupt also 0,0 spannend.
Was spannend war, war alles so drumherum.
Es kommt aus China, so, und das ist der erste Auftakt für die in
dieses, dieses Rattenrennen von irgendwelchen Modellen, das hat
ne Zensur, es war so n bisschen, es gab so n bisschen so ne so ne
backstory drumherum, die hat mich sehr interessiert, aber ob
das Modell jetzt irgendwie 0,2% besser in irgendwelchen
Benchmarks ab irgendwie abschneidet als andere ist
eigentlich relativ irrelevant, dass das deutlich günstiger
macht und warum, das ist glaub ich schon eher relevant, das
haben wir in dem Short auch noch mal.
Dann irgendwie so n bisschen thematisiert, aber was ich
eigentlich sagen will ist, dass bei mir so ne.
So eine kleine AI Müdigkeit irgendwie einsetzt.
Und wenn da jetzt nicht irgendwie was, also was
Bahnbrechendes passiert und da immer nur so kleine Tropfen
irgendwie, jetzt kann das irgendwie ein ganz kleines
bisschen was mehr bin ich auch. Manchmal merke ich gerade ich
komme an so einen Punkt wo ich das so ein bisschen leid oder
satt bin, geht's dir da ähnlich? Ja, also mir geht's absolut
genauso, insbesondere weil das ganze Thema sich ja so schnell
weiterentwickelt, dass irgendwie wirklich jede Woche irgendwelche
Neuigkeiten kommen und es auch super schwer ist da.
Jederzeit irgendwie to date zu bleiben, aber ihr merkt es.
Wir haben jetzt schon wieder fast 5 Minuten über KI
gesprochen. Du hast gerade noch gesagt, wir
machen eine Folge ohne KI, eigentlich sollte, sollte es am
Anfang nur der Aufruf sein, folgt uns gerne auch auf unseren
Social Media Kanälen, damit ihr auch solche vielleicht aktuellen
Themen zwischen den Folgen mitbekommt und lasst uns gerne
wissen, ob das etwas ist, was wir mehr machen sollen, einfach
mal. Tagesaktuelle Dinge aufgreifen
und mal einfach außer der Reihe ein kurzes Video aufnehmen?
Dann lass uns ins Thema einsteigen.
Wir hatten gesagt, wir sprechen heute über Anti Patterns, sprich
Dinge, die in der Softwareentwicklung immer und
immer wieder gemacht werden, die aber eigentlich negativ und
schädlich für unsere Projekte sind.
Und diese Folge soll niemanden irgendwie an den Pranger
stellen, sondern es geht darum, einfach ein Verständnis zu
schaffen. Welche Anti Patterns gibt es,
welche haben wir gesehen, auch in der Vorbereitung auf dieser
Folge, welche werden in der Literatur besprochen, wie werden
diese in der Literatur genannt, um damit das Verständnis zu
schaffen, was es gibt und natürlich auch darauf aufmerksam
zu machen, wie man diese. Probleme auch vermeiden kann
bevor sie uns, unsere Softwareprojekte und natürlich
auch unseren Code kaputt machen. Von daher lass uns kurz
einsteigen, erstmal mit einer Begriffsdefinition.
Was sind Anti Patterns? Ich glaube, das ist wichtig,
dass wir da irgendwie uns kurz alle alle einig sind, worüber
wir da reden. Und soweit ich weiß, kommt der
Begriff als so ein Gegenbegriff zu Design patterns.
Da hat ja, glaube ich, jeder schon mal von gehört, dass es so
gewisse Entwurfsmuster heißt, das Glaube ich auf im Deutschen.
Für die Softwareentwicklung gibt, da gibt es bestimmte
Dinge, die empfohlen sind, auf eine bestimmte Art und Weise zu
tun. Man kennt so Single
Responsibility Patterns und Kapselungen und also also
Sachen. Und dann sind, glaube ich, im
Laufe der Zeit aber vielen Menschen aufgefallen, dass es
aber auch Dinge gibt, die nicht explizite dus sind, sondern
explizite Donts sind, also nicht sagen, Hey, guck mal, das, so
sollte man es machen, dann kann es trotzdem passieren, dass man
sich an all diese Design patterns hält und trotzdem Code
schreibt, der dann am Ende technische Schulden hervorruft,
die Produktivität reduziert, dadurch auch das Team
demotiviert. Und es ist einfach so so, dass
gewisse Fallstricke einfach in der es in der
Softwareentwicklung gibt, die zu vermeiden sind, und die haben
teilweise, das haben wir in der Intro gesagt, haben wir gerade
gelernt, lustige Namen, aber die sind bestimmt vielen von uns
auch schon mal begegnet und ich glaube, das ist so, da kommt der
Begriff werden ein Anti Pattern, wo ein Pattern sagt, so solltest
du im Idealfall, wenn du in dieser und jeder Situation bist
und das und das mit Code lösen, sagt das Anti Pattern das.
Das solltest du explizit versuchen zu vermeiden, wenn du
Code schreibst. Genau.
Ein wesentlicher Punkt ist hier auch, dass es trotzdem immer
wieder dazu kommt, dass wir als Developer in diese Muster
verfallen, ohne es vielleicht zu wollen, weil es einfach
vielleicht auch in der Natur des Menschen liegt, Probleme einfach
möglichst schnell lösen zu wollen oder auf eine bestimmte,
einfach nachvollziehbare Art vielleicht zunächst einfache
Art. Und dementsprechend treten diese
Patterns immer wieder auf und wir gehen jetzt einfach mal ein
Paar von denen durch, die wir auch aus unserem Alltag kennen
und schauen mal, wie kann man diese auch abgrenzen, wie kann
man sie benennen und wie kann man sie letzten Endes auch
vermeiden? Ja, steigen wir ein.
Genug der Vorrede, das erste, wie könnte es anders sein, ich
glaube, das haben die meisten auch schon mal gehört, ist der
gute alte Spaghetti Code. Ich glaube, das kommt aus einer
Zeit, in dem irgendwie keine Ahnung, alte
Programmiersprachen, so die von oben nach unten abgearbeitet
wurden. So go to statements drin hatten.
Da konnte man dann früher sagen, wenn du an der Stelle bist vom
Code, dann spring jetzt zur Zeile 45.
Und wenn du das abgearbeitet hast, mach ich n IF Statement
und wenn das so und so ist, dann springe zur Zeile 500 ansonsten
springe zur Zeile 30 so hat man früher so n bisschen vermieden,
dass man ne Code duplikation hat und das wurde natürlich immer
total unübersichtlich und man hat sich irgendwie gedacht, OK,
wenn ich das jetzt irgendwie aufzeichne, also wenn ich ne
früher wurde Code auch viel einfach noch ausgedruckt wenn
ich da aufzeichne mit einem Kugelschreiber von wo man nach
nach wo alles springt, also diese beiden diese go to Zeile
45 dann mit einer Linie zur Zeile 45 verbindet und dann
sieht das am Ende irgendwann aus wie ein großer Teller Spaghetti
und daher kommt dieser Name Spaghetti Code.
Heute gibt es natürlich arbeiten wir natürlich in modernen
Programmiersprachen und Frameworks sehr, sehr wenig mit
diesem Go to Statements, es ist aber geblieben als Bezeichnung
einfach für unstrukturierten und dadurch schlechte wartbaren Code
ohne eine klare Modularität, also sehr sehr, sehr
verschachtelter Code, auch man schon mit vielen, irgendwie mit
mit vielen IF else conditions. Einfach Code, der sehr
verschachtelt ist, der nicht gut auf verschiedene Dateien
aufgeteilt ist, der nicht klar lesbar ist, der nicht einer
klaren Struktur folgt, dem man beim Lesen nicht klar versteht,
was passiert eigentlich hier, wann und in welcher Reihenfolge.
Das ist, glaube ich, bis heute der Begriff geblieben für
Spaghetti Code. Und letzten Endes macht das mein
Code wirklich schlecht wartbar und dementsprechend
fehleranfällig. Wir können auch den Code
schlecht debuggen, wenn wir in unserer Anwendung Probleme
finden und wir weichen dementsprechend dann auch von
solchen Architekturprinzipien wie Solid und Kiss ab, das
heißt, wir haben es halt nicht simpel klar strukturiert, Single
Responsibility, sondern wir haben halt irgendwelche
riesengroßen klassischen. Lassen und Objekte, die alles
Mögliche tun und bei denen der Code halt furchtbar
verschachtelt ist und dementsprechend auch unlösbar.
Und damit kommen wir eigentlich auch schon zu unserem zweiten
Anti Patterns, was wir gefunden haben, was damit eng verwandt
ist und ich habe es gerade schon gesagt, das ist das Anti Pattern
des sogenannten God objects, das heißt, ich habe irgendwie in
meiner Anwendung. In dem Fall einer
objektorientierten Anwendung eine riesige Klasse oder ein
riesiges Modul, was 1000 Dinge tut und wo ich vielleicht viel
zu viel Logik an einer Stelle zusammenführe und
dementsprechend es wiederum super schlecht wartbar ist und
wir gar nicht mehr ganz klar Verantwortlichkeiten zuweisen
können. An welcher Stelle passiert
eigentlich was und am Ende einfach dieser eine Bestandteil
meiner Anwendung immer weiter wächst?
Und häufig dann auch in Kombination mit solchem sehr
verschachtelten Code einfach dazu führt, dass wir diese Dinge
auch einfach innerhalb von dieser Anwendung und anderen
Anwendungen einfach auch nicht wieder verwenden können, weil
alles irgendwie an einer Stelle zusammen gepflanzt wird.
Wie man sowas vermeidet ist dann tatsächlich so ein bisschen mit.
Das hat auch dann wieder ein bisschen was mit dem Spaghetti
Code zu tun, nämlich mit Single Responsibility ist einer von
diesem Solid, was malte eben schon erwähnt hat, das ist ein.
Design Pattern also das ist ein gutes Pattern, das also gerade
bis hier Solid und Kiss hatten wir eben eben erwähnt, ich
glaube, da kann man eine ganz eigene Folge zu machen.
Es ging, ging, deswegen gehen wir jetzt nicht ganz tief drauf
rein, haben am Ende auch noch ein paar Literaturempfehlungen
für euch, also das sind positive Patterns und zum Beispiel das S
im Solid steht für Single Responsibility und damit kann
man eben auch versuchen diese deutsche Gott Objekte zu
vermeiden. Indem man nämlich ganz klar
sagt, Hey, in meinem Code ist eine bestimmte Klasse, wenn ich
Objekt orientiert, programmiere oder eine oder eine bestimmte
Datei oder eine bestimmte Funktion dafür verantwortlich,
eine einzige Sache zu lösen und die gut zu machen.
Und ich habe nicht diese eine große Klasse, die irgendwie
sämtliche Abfragen in sämtliche Datenbanken oder sowas
übernimmt, sondern kann das eben auf Kleinigkeiten, auf kleinere
Teile runterbrechen. Das hat den sehr, sehr großen
Vorteil, und das ist ja für mich die also also neben dem, dass es
klar Verantwortlichkeiten trennt, dass ich genau weiß,
wenn ich mir diese klasse angucke, was sie macht, dass die
Klassen dadurch kleiner werden, was sie übersichtlicher macht.
Die größte Auswirkung ist für mich aber halt die Wartbarkeit,
die die ein, die ich eben nicht habe, wenn ich ein solches, ein
solches Gott Objekt baue. Und natürlich auch die geringe
Wiederverwendbarkeit. Na, ich habe eine S.
Man nennt das Kopplung in der in der Programmierung, das heißt
ich habe dann sehr viele Referenzen auf dieses eine große
Gott Objekt oder dieses große Gott Objekt holt sich ganz viele
andere Referenzen rein wie den Klein für die Datenbank, weil es
mit der reden will und referenziere alle möglichen
weiteren Klassen und hat noch ganz viel unter Logik irgendwie
drin, das heißt es wird super schwierig zu testen ich kann es
fast nicht wieder verwenden und. Ich weiß meistens schon
irgendwie, wenn eine wenn eine Coding Datei mehr als was ich
sag mal 2 300 Zeilen lang ist, dann ist das ein ganz gutes
Indiz dafür, dass ich hier vielleicht au aufbreche in
kleinere Klassen, in kleinere unter Funktionen und Dateien,
wenn ich nicht mit Klassen arbeite und die dann einzeln
teste, wo brauchen dann ein Test zu schreiben eine Sache von 5
Minuten ist und nicht dadurch natürlich.
Durch diese Single Responsibility Pattern Gott
Objekte vermeiden und deutlich wartbaren oder deutlich
wartbareren Code bauen kann. Und ich glaube, gerade heute
müssen wir da auch noch mal ein besonderes Augenmerk darauf
legen, dass wir nicht solche überbordenden
Verantwortlichkeiten an einer Stelle aufbauen, weil wir häufig
mittlerweile mit diesen KI Developer Tools arbeiten und die
häufig nicht die Fähigkeit Mitbringstand heute bestimmte
Architektur muss. Muster und die Trennung in
verschiedene Komponenten zu befolgen und man damit natürlich
verführt, ist an der Stelle, an der man gerade unterwegs ist,
einfach immer noch mehr einzubauen, was einem die KI
vorschlägt und die KI mir natürlich auch die Möglichkeit
gibt, sehr große Dateien einfach schnell zu verstehen und zu
überblicken. Und ich glaube, da müssen wir
tatsächlich auch ein bisschen vorsichtig sein.
Ich möchte gerade hier eine kurze Pause bei diesem Podcast
machen und für das Protokoll. Erwähnen, einfügen, dass malte
gerade dreimal KI erwähnt hat und es dadurch eine K auch eine
KI Frau geworden ist. Dass das nicht immer nur ich
bin. Danke.
Okay machen wir weiter mit dem mit dem nächsten Antipattern und
da wusste ich, das war zum Beispiel 1, da wusste ich nicht,
dass es so heißt. Es gibt das Antipattern das
nennt sich Cargo Cult Programming.
Und was sich dahinter verbirgt, haben vor allem viele, die in
einem Team programmieren, bestimmt schon mal gesehen.
Das ist, da wird ein Kult, dass er daher kommt, auch auch dieser
Name herum oder fast schon einen Kult um ein bestimmtes Pattern
oder eine bestimmte Library oder irgendwas geschaffen, die jetzt.
Verwendet werden soll, weil sie ja, wie wie das oft auch auch in
so Kulten ist, als der Heilsbringer angepriesen wird,
ohne dass ich ein tiefes Verständnis dafür entwickel, was
denn die, dass die zugrundeliegenden Probleme sind,
die ich damit lösen will, oder warum ich denn überhaupt, ob
jetzt dieses Pattern einsetze, also ne von all den
Antipatterns, die wir hier reden, gibt es eben auch diese
positiven Patterns, und um viele von diesen Patterns und.
Das wird man gerade merken, wenn man in in größere Teams kommt,
wo es viele verschiedene Meinungen gibt.
Gibt es tatsächlich so ganze Kulte um diese Patterns herum?
Klassische Beispiele sind irgendwie, es gab ne ganze Zeit,
da musste man alles mit Microservices lösen, egal ob
vielleicht n Monolith gebraucht wurde oder oder nicht oder ob
man das überhaupt in Microservices aufbrechen musste,
was ja auch Komplexität bringt. Oder es gibt Verfechter von
Domain driven Design, die sagen, das ist die einzig richtige Art
und Weise, Software zu entwickeln, weil ich da mal ne
Podcast Folge zugehört habe. Deswegen, wenn ihr diesen
Podcast hört, geht, tut euren Kollegen den Gefallen und
prangert dann die Sachen die ihr hört, nicht als nicht kultartig
an und sagt es muss jetzt so gemacht werden, sondern seht,
dass er als Staat sich damit tiefer zu beschäftigen und dann
zu schauen, ob das auch wirklich auf die ja zugrundeliegenden
Probleme passt. Und auch ganz oft, wie
eigentlich überall im Leben, gibt es mehr als eine Antwort
und mehr als einen Weg zum zum Erfolg.
Und das wird ganz oft in der Softwareentwicklung, gibt es
dann aber so religiöse Tendenzen, die sagen, das muss
aber mit müssen das Domain driven oder wenn nicht Test
driven entwickelt, der hat keine Ahnung und sowas und ich glaube
das versteht sich unter diesem Cargo Kult programming.
Ja, ohne den Begriff zu kennen, musste ich in den letzten Jahren
häufig drüber nachdenken, als halt das ganze Thema Cubinetis
immer populärer wurde und man dann in immer mehr Projekte
reinkam und es nicht mehr darum ging.
Wie können wir das Problem am besten lösen, sondern es ging
nur darum, wie bauen wir eine Anwendung, die wir nachher auf
Cubinetis laufen lassen können. Da fragt man sich.
Löst das euer Problem, dass ihr diese Betriebsplattform wählt?
Nein, aber es war dieser Kult, entstanden rund um Kubernetis
und man hatte irgendwie das Gefühl, das ist die Lösung für
alle unsere Infrastrukturprobleme in der
Zukunft und das führt natürlich dazu, dass man häufig
überdimensionierte Lösungen hat, die vielleicht für die Lösung
des Problems gar nicht angemessen sind.
Und ganz häufig ist es einfach ein blindes übernehmen dieser
Muster, die man bei anderen sieht und die vielleicht
wirklich kultartig zelebriert werden.
Und man ist natürlich sehr empfänglich dafür, gerade wenn
man nicht die entsprechende Erfahrung mitbringt, weil dann
kann man das gar nicht so gut bewerten und man geht dann
einfach davon aus, weil es alle so machen muss das die Lösung
sein und dementsprechend folgt man dann diesem Muster und ich
glaube man kann das einfach umgehen, indem man sich einfach
noch mal die Zeit nimmt das Problem zu verstehen und zu
sagen okay was. Was sind jetzt die möglichen
Lösungen und dann jeweils die auszuwählen, die für meinen
Anwendungsfall der beste Weg nach vorne ist?
Ja, zumal diese überdimensionierten Lösungen ja
oft auch wahnsinnig viel Komplexität mit reinbringen.
Ich bin ein riesen Verfechter von Cubanitis, das ist ein ganz,
ganz tolles Werkzeug, aber man kann nicht wegdiskutieren, dass
es A eine wahnsinnig steile Lernkurve hat und b einfach sehr
viel Komplexität reinbringt, die.
Gar nicht jedes Problem braucht, wenn ich irgendwie also ne
unsere kleine Podcast Website Landing Page, die muss nicht auf
Cobonitis gehostet sein, die ist nicht mehr in einem Container
und ja, ich glaube diese Komplexität unterschätzt man
oft, weil es dann auch irgendwie schnell gehen muss oder weil man
auf einer Konferenz war und da in jedem zweiten Talk über
Cobonitis gesprochen wurde, müssen wir das jetzt auch machen
und ich glaube diesen einen Schritt weiter zu gehen, zu
verstehen, OK was bedeutet das? Was hat das für Implikationen,
vor allem auf die Komplexität? Und löst das wirklich unser
Problem oder haben wir das Problem gar nicht?
Was Kuranides löst, würde vermeiden, in diesen Carco cool
Programming Anti Patterns gefangen zu sein.
Dann weitergehend zum Thema Dinge ohne Sinn und Verstand
übernehmen, haben wir gefunden. Den Begriff Copy paste
Programmierung. Wir beide haben erst mal gedacht
okay. Ganz klar, das bedeutet, ich
gehe ins Internet, gehe auf Stack Overflow und kopiere
irgendeinen Text, aber letztendlich letzten Endes wird
in der Literatur damit beschrieben, dass man innerhalb
seiner eigenen Anwendung den Code immer wieder copy pasted
und das ist ja etwas, was, glaube ich, wir alle schon mal
irgendwann gemacht haben, weil wir gesagt haben, okay, es geht
jetzt schneller einfach 20 Zeilen Code von A nach b zu
kopieren statt irgendwie nicht. Ein Modul zu bauen, welches ich
dann an der anderen Stelle aufrufen kann, um dann
Wiederverwendung in meiner Anwendung zu haben und unter
damit dem DRY Prinzip zu folgen. Don't repeat yourself und damit
ein positives Design Pattern zu übernehmen, sondern wir gehen
halt einfach hin und sagen, OK, wir haben jetzt gerade keine
Zeit dafür, das machen wir dann irgendwann vielleicht mal
ordentlich und dann übernehmen wir einfach die 20 Zeilen Code
von a nach b. Und irgendwann refactoren wir an
der einen Stelle was, und dann haben wir 2 voneinander
abweichen. Implementierungen der gleichen
Sache und haben am Ende einen Anwendungscode, der super schwer
wartbar ist. Letzten Endes ja.
Das ist ein ganz klassischer Anfängerfehler, würde ich sagen.
Dieses, dass man Code von hin und her kopiert, anstatt das
richtig zu Kapseln. Also Code gehört dann gekapselt
und dann wiederverwendbar gemacht, das ist eigentlich ein
Geschenk, wenn ich irgendwo merke, Oh guck mal, hier brauche
ich den gleichen Code wieder, ist das eigentlich eine.
Wahnsinnig mit Geschenken, mein Ich ist ein gutes Zeichen dafür.
Ach guck mal, das kann ich schon mal.
Diesen kann ich schon aus meiner wahrscheinlich gerade immer
größer werdenden Datei oder klasse rausziehen, weil der wird
ja offenbar noch mal an einer anderen Stelle gebraucht, kann
den da isoliert testen, wenn es irgendwie Logik ist oder wenn
es, wenn es irgendwie konstanten sind, kann ich sagen, gut,
vielleicht fange ich mal an überhaupt irgendwo konstanten
zentral abzuspeichern und so und habe sie dann auch auf einen
Blick. Und sehe ich auch immer wieder,
vor allem dann deswegen Anfängerfehler, weil ich habe
mich, ich fange gerade vielleicht an, mich mit einem
neuen Framemark zu beschäftigen. Ich lerne irgendwie gerade go
oder sowas und weiß noch gar nicht, wie ich das Kapsel dann
kopiere ich das schnell irgendwie schnell irgendwie
rüber und komm laufe dann natürlich Gefahr, wie Malte
gerade gesagt hat, dass ich das an irgendwie ein Bug habe, den
ich an einer Stelle fixe und dann verzweifle daran, warum der
nicht gefixt ist und ohne. Und nur um dann zu merken, dass
mein anderes Modul noch eine Kopie von meinem Code, wo dieser
Bug nicht gefixt ist, verwendet und referenziert.
Abgesehen davon, dass es natürlich ja den ganzen Code
schwierig zu warten macht, schwieriger zu verstehen macht
und die Lösung ist natürlich, wiederverwendbare Funktionen
oder Bibliotheken zu erstellen, wenn ich über mehrere Projekte
hinweg brauche, diese Logik. Gerade wenn wir über
Wiederverwendung sprechen, da reden wir dann nicht nur über
Wiederverwendung unseres eigenen Code, sondern auch
Wiederverwendung von Code, den andere geschrieben haben,
irgendwelche Libraries und Frameworks und da gibt es auch
ein Anti Pattern drumherum, nämlich das Not invinted here
Syndrom. Das heißt, wir haben es nicht
gebaut. Wir können es besser und man
implementiert das gleiche, was andere schon erfolgreich
implementiert haben, wo das Problem schon hundertfach gelöst
ist. Einfach noch mal, weil man ein
grundsätzliches Misstrauen gegenüber irgendwelchen
Drittanbietern hat, oder vielleicht kostet die
drittanbietersoftware Geld und dann investiert man einfach
intern viel mehr Geld, weil man hat ja die Leute und merkt es
gar nicht. Da rein einfach dieses Problem,
was eigentlich schon gelöst ist, noch mal zu lösen und
verschwendet damit viel Zeit und hat dann vielleicht am Ende ne
Lösung, die weniger effizient oder weniger wartbar ist als die
Lösung von dritten. Es kann aus der Open Source
Community kommen, es kann ne kommerzielle Lösung sein.
Und das lässt sich natürlich auch entsprechend einfach
vermeiden. Und jetzt muss ich tatsächlich
noch mal KI sagen, weil ich ja ganz häufig in dem Umfeld der KI
Softwareassistent unterwegs bin und ich habe halt immer wieder
irgendwelche Unternehmen, mit denen ich spreche, die sagen ja,
das, was es da am Markt gibt, das ist alles schön und gut,
aber ich glaube, das erfüllt nicht hundertprozentig unsere
Anwendung, wir stellen jetzt einfach mal ein Team von 100
Leuten ab, die bauen einen eigenen KI.
Coding Assistant und da fragt man sich ja genau.
Glaubt ihr selber, dass ihr das besser könnt und dass am Ende
eure Lösung eure Probleme besser löst als das, was ihr am Markt
findet? Man mag es anzweifeln, aber das
passt für mich ganz gut in dieses Not invented here
Mindset, wo man dann sagt, nee, ich glaube alles was bei uns
intern gebaut wird, ist einfach vom Prinzip her erstmal besser.
Ja, die Ursache ist natürlich immer sowieso keine Ahnung,
falscher Stolz. Oder halt irgendwie so ein
Misstrauen gegenüber von irgendwelchen Drittanbietern.
Aber was du gerade sagst, dieses Beispiel mit diesem, wir bauen
jetzt selber irgendwie einen KI Coding Assistenten, das finde
ich sehr sehr maßgeblich dafür, dass man sich einfach mal fragt,
Okay ist das denn eure Expertise, also seid ihr ein
Coding Assistenten Software laden oder seid Ihr vielleicht
ein Pharmakonzern der Software schreibt und einen Coding
Assistenten braucht, dann müsst ihr euch ja also da würde ich
mich ja immer wirklich fragen, können wir das besser und wenn.
Wenn wir glauben, dass so viel besser zu können, warum nehmen
wir dann nicht an diesem Markt der Coding Assistenten teil,
gründen unser eigenes, unsere eigene Ausgründung von unserem
Unternehmen und bauen da jetzt irgendwie den Coding
Assistenten, der dann irgendwie für alle bereitgestellt wird,
wenn wir wirklich glauben, da konkurrenzfähig sein zu können?
Ich sehe es aber auch, vor allem wenn eine Software das kann ja
auch nur irgendwie eine kleine Library sein, das muss ja gar
nicht wieso was Großes sein, sobald die irgendwie ein
bisschen Geld kostet, ein paar Euro kostet wahrscheinlich sogar
noch eine Lizenz pro Developer. Dann überlegt man sich aber dann
das nicht irgendwie selber schreiben kann und vergisst da
ganz oft was das alles ein Rattenschwanz mit sich zieht,
mit Testen, mit Warten, mit Security Updates, mit das
irgendwo an einer zentralen Stelle auch vielleicht
bereitstellen so inner Source mäßig, dass ich wenigstens wenn
ich ein großes Unternehmen bin, sage, wir haben jetzt was cooles
gebaut, das kann auch andere gebrauchen, wie stelle ich es
bereit, wie sorge ich dafür, dass wenn jemand das Unternehmen
verlässt, dass das weiterhin gewartet wird, und das ist ja in
der Regel Zeitverschwendung. Dinge, die es schon gibt, also
man man sagt im Deutschen so schön das Rad neu zu erfinden,
vor allem nicht, wenn es meine, wenn es nicht meine
Kernexpertise diese ist, Räder zu bauen, sondern wenn ich
Software Software ist ja kein Selbstzweck, sondern Software
will ja immer irgendwie ein Problem lösen und wenn ich das
beschleunigen kann, weil ich da mir eine Abkürzung nehme, wo
jemand anderen schon anders schon was gebaut hat, ist das
ist die Lizenzkost fast immer deutlich günstiger als selber zu
bauen. Dann vielleicht noch verwandt zu
dem, was wir vorhin besprochen haben mit dem Cargo Kult. 2
weitere Ausprägungen, die sich irgendwie in dem Bereich bewegen
und das eine ist das silverbullet Syndrom, wo ich das
Gefühl hab, dass. Das ist diese Technologie, mit
der man jedes Problem erschlagen kann.
Und das löst halt am Ende alles und das kann etwas sein, was
einfach sich kultartig aufgebaut hat, aber das kann auch etwas
sein, was irgendwie einem von extern angepriesen wird, dass
irgendwie ein Zulieferer, ein anderer Softwarehersteller kommt
und sagt, hier, wir haben hier diese Bibliothek gebaut, und die
löst alle eure Probleme und da dann einfach wirklich naiv daran
zu glauben, ist natürlich auch etwas, was.
Unrealistische Erwartungen auslöst und am Ende dann zu
hohen Enttäuschungen führt, weil man dann am Ende vielleicht dann
doch irgendwie an Grenzen stößt. Und immer wenn jemand kommt und
sagt Okay für diese Probleme im bestimmten Umfeld haben wir die
einzig wahre Lösung am Markt, dann sollte man glaube ich
skeptisch sein und ähnlich ist es natürlich auch, wenn man.
Und das ist ein anderes Phänomen, was so ein bisschen so
unter dem Namen Kitchen Sync oder Swiss Army Knife fällt.
Wenn jemand kommt und sagt, Wir haben hier diese Standardlösung,
damit lösen wir in der Regel alle unsere
Softwareentwicklungsprobleme wir haben schon immer auf diesem
Framework aufgebaut und damit kann man eigentlich alles
machen, und ich glaube auch dann sollte man hellhörig werden,
weil das natürlich eine unrealistische Erwartungshaltung
auf der einen Seite ist, aber auf der anderen Seite auch dazu
führt, dass man. Sich verschließt gegenüber
vielleicht neuen Innovationen, die am Markt verfügbar sind,
neuen Technologien, die vielleicht spezifisch für mein
Problem der bessere Lösungsweg wären.
Ja, das sieht man halt viel auch mit irgendwelchen Libraries.
Wenn also gerade so im Fonda Bereich, wo dann irgendwie sagt
okay alles muss React sein und wenn das nicht irgendwie und wir
versuchen auch die statische Landingpage irgendwie mit React
zu bauen, sowas sehe ich manchmal.
Viel mehr seh ich es aber wirklich mit so
Programmiersprachen oder oder Frameworks.
Gerade mit diesen großen frameworkswie.net im C Sharp
Bereich oder wie Java, wo dann immer erstmal versucht wird,
weil wir haben ja die Expertise dafür im Haus und ich find das
darf man auch nicht. Missachten, das muss man okay
wenn wir jetzt irgendwie sagen, hey, wir bauen jetzt keine
Ahnung, diese kleine serverless function, die ganz kurz
hochfahren und eine Message bearbeiten und dann wieder
runterfahren soll mit Java, weil da haben wir die Expertise im
Haus. Vielleicht ist aber gar nicht,
dass das richtige Framework, weil das gar nicht, weil das
viel langsamer vielleicht startet als als jetzt vielleicht
jetzt irgendwie eine kleine Go oder Rust Anwendung macht.
Dann muss man natürlich auch irgendwie überlegen.
Ja, ist das denn wirklich, auch wenn wir da so viel Erfahrung
mit haben und auch wenn wir damit irgendwie, wenn das der
Hammer ist, mit dem wir all unsere Nägel oder all so
Probleme, die wie Nägel aussehen, reinschauen,
reinhauen, nicht reinschauen, ist es dann brauchen wir denn
diesmal wirklich einen Hammer oder gucken wir uns das Problem
noch mal genau an und das sehe ich vor allem in so größeren
Unternehmen, wo ist ja auch sinnvoll, ist das irgendwie,
dass da nicht 45 verschiedene Programmiersprachen rumschwirren
und. Aber gerade bei so Tools und und
und Frameworks, die dann irgendwie alle Probleme lösen
sollen, hilft es glaube ich, dass man sowas vor allem das
Problem und die Technologie kurz kurz kritisch evaluiert
gegeneinander stellt und sagt Okay wir haben diesen Hammer im
Haus, aber ist das überhaupt Nagel?
Und ich glaube, dass das hilft, aber man sieht's wirklich oft,
dass man alles versucht mit diesem einen Tool, mit dieser
einen Programmiersprache, mit diesem einen Framework, diese
einen Library zu lösen. Dann haben wir noch 2 letzte
Anti Patterns hier auf unserer Liste, die ich gerne mit dir
besprechen würde, weil ich einfach die Namen toll finde.
Zum einen Lavaflow, also ein Fluss von Lava und den den Boat
Anker, also den Anker des Bootes und vielleicht erzählst du mir
gleich noch mal ein bisschen was zu dem Boat Anker, aber ich
finde einfach diesen Lavafluss so toll, weil er eigentlich.
Genau das beschreibt, was wir in der Realität ganz häufig im
Rahmen der Softwareentwicklung sehen.
Wir haben irgendwie einen Fluss von Code, der tut etwas, er
fließt in die richtige Richtung, aber irgendwann erkaltet der und
dann haben wir toten Code, das bedeutet, Wir haben Bestandteile
in unserer Software, die einfach nicht mehr gebraucht werden, wir
haben irgendwie neue Funktionalitäten gebaut, wir
haben Refactoring betrieben, aber ganz häufig bleiben
bestimmte Code Bestandteile zurück und.
Bis auf wenige Leute wissen vielleicht viele gar nicht mehr,
dass dieser Code in meiner Anwendung gar nicht mehr
ausgeführt wird. Das heißt, den Schlepp ich dann
vielleicht über viele Jahre noch mit und niemand weiß mehr, was
dieser Code tut und dass dieser Code eigentlich gar nicht mehr
in meiner Anwendung ausgeführt wird, aber.
Aber er bläht meine Anwendung auf und kann natürlich auch das
Risiko bergen, dass er dann irgendwann wieder von anderen
Leuten in Betrieb genommen wird und dann irgendwelche
Sicherheitslücken wieder reinkommen, die vielleicht
eigentlich in den letzten Jahren gar nicht relevant waren.
Und das kann auch zum Beispiel auskommentierter Code sein, den
man mal schnell rausgenommen hat, um was zu testen und der
wird dann einfach immer mitgenommen.
Und ich glaube, ein Alarmsignal ist immer, wenn irgendjemand,
der jetzt schon einige Zeit auf dem Projekt war, dann im Team
fragt, sagt man, was macht eigentlich der Code und warum,
warum haben wir den überhaupt in unserer Anwendung.
Das ist natürlich dann immer ein Alarmsignal.
Und wenn dann die Rückmeldung kommt, ist Fass den besser nicht
an, weil wir wissen seit Jahren nicht, warum der in dieser
Anwendung ist. Ich glaube, dann sollten
wirklich alle Alarmglocken losgehen, dass man da einem
Antipattern folgt im eigenen Unternehmen und das.
Und ich glaube, das ist etwas, was wir alle aber auch schon mal
erlebt haben. Und ich fand einfach diesen
Begriff. Dieses Lavafluss ist, der
irgendwann erkaltet, fand ich einfach eine schöne Analogie.
Ja, stell dir vor, du hast diesen diesen Lavafluss und da
schwimmen aber schon so die ersten Magmabrocken so drauf mit
rum, die irgendwie gar nicht mehr geformt werden können oder
die keiner mehr mehr verwendet. Ich finde es, ich finde es
drückt sich dann immer aus wenn also.
Es gibt ja diese es. Es gibt ja viele Frameworks, die
einem irgendwie schon in der IDE anzeigen, Hey, die hier die, die
die Funktion die du hier geschrieben hast, die wird gar
nicht verwendet, da denkt man ja immer okay dann nehme ich die
natürlich raus, wenn die nicht verwendet wird.
Jetzt gibt's aber auch oft in so einer IDE dann halt nicht mehr
die Möglichkeit, dass ich sage, ja die Funktion, die wird
vielleicht verwendet in der Funktion hast du aber irgendwo
so eine IF Else Abzweigung und da drin ist Code, der wurde seit
15 Jahren nicht mehr aufgerufen, weil das trackt man ganz ganz
oft irgendwie nicht in Produktion und dann auch dann
weiß man ja nicht ob der nicht vielleicht für diesen einen
Alarm Anwendungsfall ist, der vielleicht zum Glück 15 Jahre
lang nicht aufgerufen würde, aber trotzdem noch irgendwie
super sicher ist und. Das ist natürlich relativ
schwierig, dann solchen Code zu erkennen, viel einfacher zu
erkennen finde ich halt auch das Beispiel, was du gerade gemacht
hast. Auskommentierter Code, da bin
ich wirklich fast schon allergisch drauf, wenn man
irgendwo in einem in einem polyquest Review oder generell
irgendwo in einer Codebase große Stellen oder überhaupt Stellen
von auskommentiertem Code findet.
Ich finde aus Code auszukommentieren ist nur eine
Technik für lokale Entwicklung, wenn ich Code nicht in meinem
Reportory oder in meinem. Bei meinem Endprodukt haben
möchte, weil er nicht offenbar am Endprodukt nicht verwendet
wird, weil er ist ja auskommentiert und ich sag ja,
vielleicht brauch ich dann aber noch, vielleicht muss ich da
aber auch irgendwas mal wieder reverten oder ich hab hier schon
mal was angefangen, das ist aber noch nicht fertig, deswegen hab
ich es erstmal auskommentiert das gehört nicht in den Code.
Also reverton. Dafür gibt es git.
Wenn ich mir angucken möchte, wie war dieser Code vor
irgendwie in n paar Klassen wenn ich sage OK ich habe aber so
viel umgebaut, dass das in Git wahnsinnig umständlich ist,
gehört das auf nen separaten Branch, dann kann man einen
Branch machen wo man sagt OK das ist ja unsere Legacy Code
Version, den halten wir einfach ne Zeit lang am Lebenden muss
man natürlich auch irgendwann löschen, sonst wird auch der zu
Magma in diesem Lava in diesem Lavastrom.
Und wenn man Feature angefangen hat, das ist aber noch noch
nicht ganz fertig, gehört auch das auf einen Feature Brunch und
der wird dann erst reingemergt wenn das fertig ist.
Aber ich finde ne Codebasis aufzublähen, vor allem mit
auskommentiertem Code ist n riesen antipatter.
Ich glaube, da gehört halt vor allem Erfahrung zu.
Und du hattest ja auch vorhin schon mal gesagt, viele dieser
Dinge, die passieren, vor allen Dingen, wenn man relativ junior
ist und gerade das, was du gerade beschrieben hattest mit
dem auskommentierten Code, so gerade wenn man im Studium ist
oder gerade vielleicht aus der Ausbildung rauskommt, dann
verfällt man vielleicht viel leichter in so ein Pattern und
da von nehme ich mich selber auch nicht aus.
Ich habe dann auch irgendwelche Projekte gehabt, wo?
Viel auskommentierter Code ist, wo man mal was ausprobiert hat
und man dann vielleicht gar nicht entweder die Möglichkeiten
hat oder dieses Pattern gar nicht kennt.
Zum Beispiel Feature Flags zu verwenden, dass man sagt okay
ich aktiviere diese Funktion, die vielleicht noch nicht
hundertprozentig durchimplementiert ist,
vielleicht dann erst später, weil sie vielleicht noch in der
Beta Phase getestet werden muss und solche Themen lernt man
glaube ich im Laufe der Zeit und da ist es natürlich auch die
Verantwortung der Erfahreneren, die anderen zu coachen und auch
im Team einfach darüber. Darüber zu sprechen und diese
Good Practices im Unternehmen zu etablieren.
Ich muss natürlich auch dazu sagen, dass das, was wir von
professioneller Softwareentwicklung reden, wenn
ihr in eurem Hobbyprojekt mal Code eincheckt, dann werde ich
euch nicht nachts holen kommen, sondern das ist eher, das ist
natürlich immer für, wenn man in Teams arbeitet, wenn man
gemeinsam arbeitet. So, und ich habe es gerade ja
noch erwähnt, ein letztes Enterpattern den Boat Anker.
Was verbirgt sich dahinter? Ja, das ist eigentlich sehr,
sehr ähnlich zu diesem Lava Flow.
Nur weil das in diesem Lava Flow halt nicht mehr verwendeter Code
ist und ein Boat Anker nennt man Code, der zwar noch verwendet
wird, der aber keinen richtigen Nutzen mehr für das aktuelle
Projekt hat oder der eben noch aus einer alten Zeit kommt, aber
weiterhin Ressourcen bindet. Irgendwie klassisches Beispiel,
man hat man ist jetzt irgendwie hingegangen und hat.
Auf einmal angefangen, dass 90% des Codes eventbasiert ist und
dann hat man sich irgendwie so ein Message Bass oder so ein
Message Broker keine Ahnung, Rabbit MQ oder sowas angebunden
und dann gibt es aber noch hinten diese 10% vom Code die
das nicht sind die noch nie irgendjemand umgebaut hat und
für diese 10% müssen wir aber weiterhin irgendwie eine
Infrastruktur bereithalten oder müssen wir weiterhin irgendwas
machen oder es gibt immer noch irgendwo Code der vielleicht
auch einfach ein Feature ist was?
Niemanden mehr verwendet, der aber intern noch irgendwo
auftaucht oder wo zumindest in der UI noch irgendwie was ist.
Und wir haben durch unsere Analysen gemerkt, dass das aber
nie verwendet wird, dass es aber trotzdem immer wieder umgebaut
werden muss, wenn man auf ne neue Framework Version updatet
oder irgendwas. Und da muss man sich, weil wenn
es ein Feature ist, natürlich in Absprache mit Projektmanagement
mit den Product Ownern überlegen, ob er dieses Feature
nicht irgendwann rausnimmt, weil man sagt, das ist ein Teil des
Codes, der unverhältnismäßig viel.
Maintenance Aufwand mit sich zieht, mit sich schleppt, wieso
ein Anker halt. Daher kommt auch dieser Boot
Anker als als Name und das in keinem Verhältnis mehr da zu dem
steht ja was was für einen Nutzen das das bringt uns
eigentlich immer wieder irgendwie stoppt oder wir haben
hier oder wir können hier ein klassischer Boot Anker ist auch
wir können hier seit einem Jahr oder sowas nicht auf die neue
Version von ich sag jetzt mal Angular updaten weil wir diese
eine Library verwenden und die irgendwie schon.
Die so n bisschen verlassen scheint, die noch nicht die neue
Version unterstützt und die hält uns halt irgendwie mal auf und
dann kann man sich auch überlegen, können wir diese
Library nicht einfach rausschmeißen und ja bitte nicht
selber bauen, aber irgendwie nach einer nach einer
Alternative suchen oder wenn sie halt wirklich nicht viel macht,
vielleicht auch irgendwie. Wenn man das in wenigen
Zeilencode kann, irgendwie selber bauen oder irgendwie
schauen, brauchen wir das wirklich noch, weil es uns
einfach immer wieder aufhält, auf eine neue Version upzudaten
zum Beispiel oder sowas. Dann spricht man von so einem
Boot encount, die sollte man aus seinem Projekt entfernen, weil
es sonst eben natürlich auch Agilität und Geschwindigkeit
kostet. Viele der Themen, über die wir
gerade gesprochen haben, sind ja eher so Architektur,
Entscheidungen oder Fehlentscheidungen in der
Architektur. Es gibt aber noch ein paar
Sachen, die sich konkret auch auf.
Das Coding beziehen Du hast ein paar Beispiele rausgesucht,
sollen wir dann noch mal schnell durchgehen, bevor wir dann zu
unseren Learnings kommen? Ja, können wir gerne machen.
Es sind, glaube ich, auch mehr so typische so Beginner Sachen
die die ich viel sehe, aber das eine ist es nennt sich Magic
Numbers oder Magic Strings. Das sind vor allem hart gecodete
Strings oder Zahlen im Code, wo nachher keiner mehr weiß, wo die
herkommen. Ich bin bin immer in einem Code
Review, ich werde immer aufmerksam.
Eigentlich, wenn irgendwo ein String hart gecoded ist.
Also wenn ich irgendwo Anführungszeichen sehe, dann ist
das mit einem Code ist das meistens kein gutes Zeichen
warum weil entweder habe ich einen zum Beispiel eine Zahl
irgendwo die meinen die meinen Maximum.
Von irgendwas darstellt wird glaube ich recht komplizierter
Satz. Klassisches Beispiel.
Ich habe ein Upperlimit, wieviel Objekte man in meinem Shop in
den Einkaufswagen legen kann und irgendwo habe ich eine if
Abfrage wo ich sage wenn die Items höher als und dann habe
ich hier hart gecoatet die zahlen 99 sind, dann möchte ich
irgendwas machen und in 2 Jahren weiß keiner mehr warum 99.
Also man kann sich aus dem Code noch irgendwie erschließen.
Das scheint irgendwie nen Limit zu sein, aber ist das weil
unsere Datenbank da sonst nicht nicht nicht mehr kann oder warum
99 und nicht 98? Was heißt denn diese 99 und die
Lösung hier ist irgendwo entweder in der gleichen Klasse
oder irgendwo ganz zentral ne Konstante zu definieren.
Diese Konstante nennt man dann keine Ahnung, Shopping Card
Upper Limit. Und die setzt man auf 99 und im
Code sehe ich dann, wenn die Anzahl der Items größer ist als
Shopping Card Upperlimit ah OK, das ist das Maxlimit was unser
was was unser Einkaufswagen haben kann und das gleiche wie
mit irgendwelchen Strings, wenn irgendwelche, selbst wenn
irgendwelche Titel oder jetzt gerade in der KI Entwicklung
damit ich das Wort auch noch mal gesagt habe, irgendwelche
Prompts irgendwo halt gekotet werden, die gehören
wahrscheinlich irgendwo an eine zentrale Stelle damit ich weiß
wo habe ich die alle definiert, wo habe ich die angepasst also
hart gecodete zahlen oder Strings nennt man Regel Magic
Numbers idealerweise vermeiden, wenn man sie braucht irgendwo
eine Konstante definieren oder Sie zum Beispiel ohne
Environment Variable festlegen, dass man sie eben auch von außen
verändern kann. Ein zweites Coding Anti Pattern,
was ich oft sehe, ist, dass Objekte zu oft simplifiziert
werden, also man nennt das irgendwie primitive Obsession im
im Englischen was meint das? Dass primitive Datentypen wie
Strings und integer zu oft für was missbraucht werden, was sie
nicht sind. Also es gibt dieses klassische
Beispiel, dass ne Postleitzahl nie n integer ist, weil die auch
mit 0 zum Beispiel anfangen kann, aber.
Ganz eigentlich ist eine Postleitzahl auch kein String,
weil eine Postleitzahl, weil ein String halt einfach ist.
Ich bin eine Zeichenkette und eine Postleitzahl ist keine
Zeichenkette, die hat eine ganz bestimmte Begrenzung.
Die hat zum Beispiel darf zum Beispiel nur eine bestimmte
Anzahl von Zeichen lang sein oder auch eine Adresse ist
eigentlich nicht in einem String zu speichern, sondern Adresse
bricht sich runter auf Einestraße, auf eine Hausnummer,
die auch kein integer ist, weil sie auf 15 a sein kann.
Auf eine Postleitzahl, dann wieder auf einen, auf auf eine
Stadt oder einen Ort und so weiter und gerade wenn man
sieht, dass man irgendwie jetzt eine eine Klasse, um bei diesem
um bei diesem E Commerce Beispiel zu bleiben, Bestellung
hat. Und da hab ich in der in der
Bestellung einen String für Adresse, einen String für
Postleitzahl und so weiter dann ist das wahrscheinlich auch n
Zeichen, dass ich das mal in n eigenes Objekt runterbreche, was
ich dann auch wieder testen kann wo ich sagen kann ich hab nen
Test. Ich kann gucken ob man da eine
Adresse valide ist, weil es keine eigene Adressklasse gibt,
wo die Objekte eben drin sind. Also eine Adresse ist kein
String, eine Adresse ist wahrscheinlich ein komplexeres
Objekt. Und so ist es ganz oft so, dass
ich meine Anwendung wahrscheinlich komplexe Objekte
habe, die ich aber irgendwie in Integers oder vor allem in
Strings, Speicher und das, wenn man es ganz sauber programmiert,
gilt es wie alle anderen Anti Patterns auch, die wir hier
genannt haben, zu vermeiden. Dann lass uns kurz noch darüber
sprechen, wie kann ich diese Anti Patterns vermeiden
beziehungsweise wie kann ich sie identifizieren und dann letzten
Endes auch aus meiner Software rausbekommen.
Und ein Thema hatte ich gerade schon so am Rande erwähnt.
Man muss voneinander lernen, man muss gemeinsam lernen und auch
die erfahreneren müssen denen, die relativ neu im Unternehmen
sind oder relativ frisch in der Softwareentwicklung natürlich
etwas beibringen, und das erfolgt in der Regel über Code
Reviews oder per Programming. Wir haben über beides schon mal
in der Vergangenheit auch in verschiedenen Folgen gesprochen,
könnt ihr entsprechend nachhören.
Und da kommt es natürlich drauf an, auch mit einer Kultur zu
arbeiten, wo man jetzt keine Anschuldigungen in den Raum
wirft und den Leuten das Gefühl vermittelt, dass sie irgendwie
dumm sind und sich nicht auskennen, sondern wirklich
konstruktiv zusammenzuarbeiten und auch dann den Kolleginnen
und Kollegen zu erklären, welchem.
Vielleicht vermeintlich einfach ein Lösungsweg sie da gefolgt
sind, der aber nach hinten raus mehr Probleme als Lösungen
bietet. Und ich glaube da ist ganz
wichtig, dass man das auch in der entsprechenden Art und Weise
an die Kolleginnen und Kollegen kommuniziert da.
Darf man auch gar nicht böse sein, da muss man fast schon
dankbar sein, wenn da jemand einen Code Review von so einem
Pol Quest drauf hinweist. Ich finde das die Kultur muss
man schon irgendwie schaffen. Genauso wie man eine Kultur
schaffen muss, wo Refactorings an der Tagesordnung stehen oder
wo man sich auch immer mal wieder in einem Sprint Zeit
nimmt, Legacy Code zu refactern oder zu evaluieren, ob man
diesen Code noch braucht, um eben diese diese Lavaströme und
Boot Anker zu vermeiden und natürlich viel Kommunikation im
Team man nicht irgendwie davon ausgehen, dass alle alle Coding
Patterns und alle Anti Patterns kennen, sondern sich eben
gegenseitig. Freundlich darauf hinweisen und
dann gemeinsam lernen oder vielleicht auch gemeinsam mal
irgendwo definieren, was was, was man im Team verwendet oder
was man im Team präferiert, so ein bisschen ähnlich wie wir
hatten mal so eine Folge zu Coding Styles gemacht, wo wir
auch sagen am besten einheitlich eben.
Und wenn ihr jetzt das Gefühl habt, bei euch im Unternehmen
oder in euren Projekten kommt. Kommen wir immer wieder in
solche Anti Patterns, dann überlegt euch auch, ob ihr
vielleicht strukturierte Weiterbildung braucht in eurem
Team oder in eurem Unternehmen, wo ihr über positive Design
Patterns und Architekturprinzipien lernt und
wo dann auch diejenigen, die vielleicht noch nicht so viel
Erfahrung haben, auch mal strukturiert an solche Themen
herangeführt werden. Natürlich kann man viel per
Learning by doing und man kann sich von den Kolleginnen und
Kollegen was abschauen. Aber manchmal sind tatsächlich
auch Trainings nicht verkehrt. Das heißt, wenn ihr uns zuhört
und ihr seid irgendwie Development lead und habt das
Gefühl, sowas tritt bei mir im Unternehmen immer wieder auf,
besorgt euch vielleicht auch das Budget, wenn ihr intern das
wissen nicht habt, um auch mal externe Trainer reinzuholen und
da vielleicht auch mal einen Workshop zuzumachen.
Natürlich gibt es online unbegrenzt viel Material zu
diesen ganzen. Themen Software Design Patterns
und Architekturprinzipien Wir werden auch in den Show Notes
noch ein paar Bücher verlinken, gerade zu den Themen, die wir
heute besprochen haben, aber wenn ihr merkt, wir haben
wirklich immer wieder Probleme, scheut euch nicht davor, auch
externe Expertise mal reinzuholen, das zahlt sich am
Ende eigentlich immer aus. Ja, genau.
Also ich glaube diese ne, wir haben eben über Kultur
gesprochen, so eine Learning Kultur ist auch ganz wichtig,
die muss natürlich auch bis ins Management hoch unterstützt
sein, weil wie man gerade sagt Ne hier der Podcast ist umsonst.
Den könnt ihr natürlich auch hören, das ist natürlich
hoffentlich auch Teil von ein bisschen Weiterbildung,
vielleicht für den einen oder oder die andere, aber gerade so
Trainings wir kennen auch ein paar Trainer, also wenn ihr
irgendwie sagt Hey habe ich gar keine Ahnung, schreibt uns
einfach gerne mal. Es gibt eine E Mail Adresse und
in der Beschreibung dann. Sprechen wir gerne ein paar
Empfehlungen aus, gerade für so so Softwarearchitektur und Clean
Code beim Wort Clean Code muss ich aber natürlich auch immer an
das an das Buch von Robert C. Martin denken, das Clean Code
heißt und da wird glaube ich auf den ersten Seiten sogar, wenn
ich mich richtig erinnere, erstmal beschrieben, warum warum
denn überhaupt clean Code und was was kostet es vor allem das
nicht zu haben. Also das ist ein Buch was man
irgendwie in jedem Office mal ins Regal stellen kann, das.
Da geht es um, wie man sauberen Wartbaren Code schreibt und
typische Fehler vermeidet. Denn ganz viele Patterns lassen
sich allein schon dadurch vermeiden, dass man die
positiven, die guten Patterns, dass man denen folgt und ja, auf
die kommt man ja nicht einfach so, sondern da muss natürlich
entweder ein Budget oder eine Zeit oder so ein Learning Day
oder eine interne Weiterbildung oder man guckt sich irgendwelche
youtube Channels an oder hört natürlich Podcasts oder sowas
und wenn man sich diese Kultur hat und da alle auch für offen
sind. Auch sich dem eigenen Code
gegenüber kritisch mit auseinanderzusetzen.
Dann ist glaube ich, schon viel gewonnen.
Jetzt die Frage auch von unserer Seite.
Welche Antipattern seht ihr denn in der Praxis?
Schreibt uns gerne eine E Mail Robin Manuel hat es gerade
erwähnt, e Mail Adresse findet ihr in den Shownotes auf Spotify
könnt ihr auch direkt zu dieser Folge kommentieren, uns würde
interessieren was begegnet euch so, was sind eure Erfahrungen zu
diesem Thema und wie geht ihr damit um schreibt.
Schreibt uns auch gerne auf Social Media.
Wir hatten es am Anfang der Folge erwähnt, ihr findet uns
auf den üblichen Social Media Kanälen, dort könnt ihr
natürlich auch jederzeit unter den entsprechenden Shorts, die
wir da veröffentlichen oder auf Youtube unter der ganzen Folge
kommentieren und uns auch einen Einblick in euren Alltag geben.
Generell gilt, wenn euch die Folge gefallen hat und es war ne
lange Folge, wenn ich jetzt irgendwie auf die Uhr gucke, ich
glaub außergewöhnlich lang. Normalerweise versuchen wir uns
hier n bisschen girlzer zu fassen, aber wir haben auch viel
Content mitgebracht, wir haben auch irgendwie viel hier in
unserem in unserem Notion Board gehabt, dann gilt.
Lasst uns gerne gute Bewertungen da, wenn es euch gefällt.
Auf den gängigen Plattformen wie Apple Podcast und Spotify oder
wenn ihr sagt Ey, ich würde den Jungs gern einen Kaffee ausgeben
für den Podcast, dann freuen wir uns da auch immer wahnsinnig
drüber. Findet ihr einen Link unten in
der Beschreibung oder wenn ihr zu eurem eigenen Kaffee die
passende Fan Nerd Tasse haben wollt, haben wir auch einen
kleinen To do Shop, schaut da auch gerne vorbei.
Das war's auch schon wieder. Wir hören uns in 2 Wochen
wieder, denn der To do Cast erscheint jeden zweiten Montag
morgens früh frisch in eurer Podcast Inbox, wo auch immer ihr
uns hört, bis dahin hat eine tolle Zeit, schreibt viel Code
unter Beachtung der guten Patterns und unter Vermeidung
der Endlay Patterns, vielleicht habt ihr in der Folge ein oder 2
mitgenommen, die noch nicht kanntet und dann hören uns in 2
Wochen wieder, bis dahin macht's gut und bis ganz bald.
Bis dahin alles Gute.