Transcript
Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute reden wir über Architektur-Antipatterns und dazu habe ich eingeladen den Andreas, den Christian und den Felix. Andreas, sag doch mal, was du bei INNOQ machst, beziehungsweise was du jetzt machst.
Andreas Voigt: Ja, mittlerweile bei adesso. Ich bin laut meiner Visitenkarte Architekt, aber ich habe einen langen Entwicklungshintergrund, viel Java in dieser Richtung und habe aber auch mit Architektur-Reviews recht viel zu tun. Deshalb bin ich gerade auch in zwei Reviews tätig.
Sven Johann: Normalerweise haben wir immer nur aktuelle INNOQler, aber Andreas ist ja schon sozusagen lange dabei gewesen bei den Architecture Antipatterns und mittlerweile leider nicht mehr bei INNOQ. Okay, danke. Dann Christian.
Christian Jacobs: Hi, ich bin Consultant bei INNOQ und mache hauptsächlich Backendentwicklung mit Java und Node.js.
Sven Johann: Okay, danke. Felix. Ja, Felix, einer meiner Go-To-Guys für Security sozusagen.
Felix Schumacher Ja, ich bin Senior Consultant bei INNOQ. Ich bin speziell im Bereich Security unterwegs. Das ist so mein Steckenpferd. Habe aber auch gerne viel mit Legacy Software zu tun und Wartung. Das ist so ein Ding, was mich interessiert.
Sven Johann: Okay, ja, dann legen wir noch mal los. Architecture Antipatterns. Was ist das überhaupt? Felix, was sagst du?
Felix Schumacher Ich fang mal an. Ich glaube, ich bin mit am längsten an dem Ding beteiligt. Also, was ist das? Im Moment ist es wohl aktuell eine Microsite. Aber prinzipiell geht’s dabei um einen Gedanken. Wir haben ja irgendwie so Coding-Patterns, kennen wir alle irgendwie, Entwurfsmuster und so weiter. Und da gibt’s halt auch, ich sag mal, das Gegenteil von: Anti-Entwurfsmuster.
Felix Schumacher Und irgendwie ist mal die Idee in den Raum gefallen, dass es sowas auch auf Architekturebene gibt und nicht nur auf, “wie ich mein Code schreibe”-Ebene, sag ich mal. Und genau darum, um eine Sammlung von solchen Antipatterns auf Architekturebene, geht das Ganze und ist halt mittlerweile eine Website geworden, wo wir sowas beschreiben. Ganz grob gesagt.
Sven Johann: Also Pattern sind ja Lösungen zu wiederkehrenden Problemen. Und ein Antipattern wäre, was wäre eigentlich dann ein Antipattern? Das falsche Anwenden? Wie würde man das definieren? Christian?
Christian Jacobs: Also ich sehe das so, dass das immer auf den Kontext drauf ankommt und dass eine Architekturlösung, die in einem bestimmten Kontext/Anwendungsfall eine sehr gute Idee sein kann und eben zu dem gewünschten Ergebnis führt, in einem anderen Kontext, da eher die Nachteile überwiegen. Also dass man das mit einer guten Absicht ausgesucht hat, dieses Muster, und dann aber nachher am Ende feststellt, das hat irgendwie nicht gepasst.
Sven Johann: Okay, also falsche Anwendung von einem Muster. Andreas?
Andreas Voigt: Ja, vielleicht ist auch die Entwicklung eines Projekts, also ein Projekt hat ja einen bestimmten Startzeitpunkt, zu dem die Entscheidung fällt und da ändern sich ja auch die Anforderungen von außen. Also dann kann es sein, dass etwas, was positiv war, auch mal vielleicht dann zu negativen Effekten führt, wenn man da nicht darauf reagiert. Ich wollte auch zu dem Thema Antipattern ein bisschen so sagen, was uns ja ganz wesentlich ist, auch wir haben diesen Erzählcharakter. Gerade, wenn man so ein Review macht oder so, dann kriegt man so ein bisschen das Gefühl, das habe ich schon mal gehört, was der andere erzählt. Und das sind so die, könnte man so grob sagen, so die Muster. Und bei den negativen Sachen ist der Name Antipattern heute gängig. Und so könnte man das auch einordnen, wenn man sich um eine klare Definition drücken möchte.
Sven Johann: Ja, ja. Christian.
Christian Jacobs: Es wiederholt sich eben. Wir haben das jetzt in den Projekten, wo wir waren, beobachten können, dass wiederholt bestimmte Sachen eben in der Architektur vorkommen, die dann zu einem schlechten oder eben einem nicht gewünschten Ergebnis führen. Also wir unterscheiden es ein bisschen zwischen zwei Arten von Antipatterns. Das eine ist irgendwie ein Verhalten im Entwicklungsprozess. Also wie werden irgendwie Entscheidungen getroffen. Und das andere ist Struktur. Wie wird Software geschnitten? Wie werden irgendwie Module definiert?
Sven Johann: Was wären denn so Beispiele für Antipattern? Also wir gehen ja nachher noch mal ein bisschen ins Detail, aber was wären so Beispiele, die ihr gut findet? Also einfach Namen. Felix.
Felix Schumacher Ja, ich würde mal sagen, ein klassisches Beispiel ist so Infrastructure Ignorance, das haben wir zum Beispiel auf einer Seite, wäre ein Beispiel, dass ich mit einer bestimmten Infrastruktur unterwegs bin, für diese Infrastruktur entwickle, aber die komplett ignoriere, also keine Ahnung, ich bin, das ist jetzt ein ganz blödes Beispiel, aus der Luft gegriffen, ich bin eigentlich auf einem Micro-Controller-Environment unterwegs und möchte aber unbedingt in einer hohen Programmiersprache mit VM entwickeln, und muss mir denn irgendwelche Cross-Compiler-Ketten zusammenbasteln, um dann irgendwann noch lauffähig zu sein auf meinem Mikro-Controller und hab da totale Performance-Probleme, weil ich einfach komplett ignoriert habe, dass es vielleicht sinnvoll gewesen wäre, einfach einen nativen C zu programmieren oder sowas. So ganz blöd gesagt.
Sven Johann: Ja, also sozusagen das Gegenteil von, jetzt habe ich es vergessen, Mechanical Sympathy. Also Mechanical Sympathy bedeutet ja, man muss sich mit seiner Hardware auseinandersetzen. Andreas, du hast auch noch ein paar Beispiele.
Andreas Voigt: Ja, also auch vielleicht ganz klassisch, was eigentlich jeder kennt, Emotional Attachment, dass man seine Lösung ganz toll findet, was ja eigentlich gut ist, aber es kann ja dazu führen, dass man auch blind wird dafür, dass vielleicht diese Lösung nicht mehr angemessen ist mit der Zeit oder dass es vielleicht auch irgendeine Standardsoftware gibt, die das viel besser erledigt, vielleicht auch mittlerweile und dass man das vergisst und das kann zu ernsthaften Problemen führen.
Sven Johann: Ja, Felix, du hast auch noch eins?
Felix Schumacher Ich wollte noch zu Andreas sagen, mit dem Emotional Attachment. Was mit ein bisschen darunter fällt, ist dieses Thema Sunk Cost Fallacy, dass man jetzt schon so und so viel Geld oder Arbeit da rein investiert hat und jetzt möchte man das deswegen nicht wegtun, auch wenn es vielleicht eine bessere Idee wäre, das Ganze nochmal neu aufzuziehen. Das gehört da auch mit rein.
Sven Johann: Christian, du hast auch noch ein Beispiel.
Christian Jacobs: Ja, also ich meine, wir haben ja noch mehr. Ich glaube, wir schaffen es jetzt nicht, irgendwie alle durchzugehen, aber ich wollte noch Overengineering nennen, weil das ist auch nicht nur einmal vorgekommen, bis jetzt in meiner Vergangenheit, dass man beobachtet, wie im Prinzip eigentlich nicht die minimale Lösung gewählt wird, um irgendwie eine Aufgabe zu erfüllen, sondern ein neues Framework, eine neue Programmiersprache genutzt wird, komplizierte Abstraktionen geschaffen werden, wo vielleicht am Ende eine Seite PHP oder ein Skript ausgereicht hätte.
Sven Johann: Ja, ja, du hast schon recht. Also es gibt ja relativ viele Patterns, und auch Fallstudien, also sozusagen Real-World-Examples zu diesen Patterns auf der Seite. Die Seite verlinken wir natürlich in den Show Notes, also architecture-antipatterns.tech. Na und wir können nicht auf alles eingehen, aber da findet ihr die Arbeit der letzten drei Jahre. Drei Jahre, ja, ist schon ein bisschen was. So ganz am Anfang war ich ja auch dabei, aber ich hab mich trotzdem gefragt, also Felix war auch von ganz Anfang an dabei. Ich hab mich jetzt aber trotzdem gefragt, wie kam es überhaupt dazu? Felix, weißt du noch ein bisschen mehr? Plötzlich haben wir da zusammengesessen, aber wie kam das dazu?
Felix Schumacher Ja, also, wie kam es da ursprünglich zu? Ist eigentlich ganz schön, unser leider verstorbener Chef, der Stefan, hatte mal einen Vortrag gehalten, der schon dieses Themengebiet ziemlich weit angeschnitten hat. Es gibt auch auf einer Konferenz auf YouTube einen Link, wo man sich den Vortrag, den ursprünglichen, quasi auf dem das ganze Thema aufsetzt, mal angucken kann. Den können wir auch gerne in die Show Notes packen. Ist auch immer noch ein toller und aktueller Vortrag. Und dann hatte Stefan auf einem internen Firmenevent mal diesen Vortrag gehalten und dann danach noch ein Open Space als Diskussionsrunde gemacht, weil er dachte, Mensch, das ist ein Thema, wir sind alle irgendwie in Projekten unterwegs, sehen immer wieder Probleme im Architekturumfeld, die sind oft ähnlich. Da könnte man noch mehr draus machen. Lass uns mal ein Buch schreiben oder eine Website bauen. Lass uns irgendwie mehr draus machen. Und dann gab es halt diesen Open Space. Da warst du dann wahrscheinlich, glaube ich, auch dabei. Weiß ich nicht mehr genau. Andreas war dabei. Genau, siehste. Ja. Und damit sind wir dann gestartet. Am Anfang hatten ganz viele Lust, da was zu machen und viel zu schreiben und dann sind wir alle mit viel Motivation losgelaufen. Und wie das dann immer so ist, irgendwann haben dann aber alle noch Kundenprojekte und auch noch andere Nebenher-Projekte, an denen sie arbeiten müssen und dann bleibt halt noch so ein Kernteam übrig, sag ich mal. Wir haben dann aber seit drei Jahren jetzt daran weitergearbeitet und mittlerweile halt diese Webseite zumindest mal veröffentlicht.
Sven Johann: Hm, also muss man vielleicht noch mal sagen, zum Kernteam, also Kernteam seid ihr drei und dann der Theo, der hat heute keine Zeit. Ihr vier sozusagen, ja.
Felix Schumacher Leider ja, also wir würden uns natürlich immer freuen, wenn noch mehr Leute wieder dazustoßen würden, Sven, wenn du mal wieder ein bisschen Zeit über hast. Also wir freuen uns natürlich über jeden, der gerne mitarbeiten möchte.
Sven Johann: Ja, ich habe mir neulich, also in der Vorbereitung habe ich auch gedacht, ich hätte eigentlich auf jeden Fall noch mal ein paar Beispiele, ein paar Case Studies. Ja, man muss auch sagen, ist jetzt nichts INNOQ-internes. Also wir sehen ja, der Andreas ist ja, ist bei adesso und der macht auch mit. Also ist ja gewissermaßen auch so vielleicht so ein Community Aufruf.
Sven Johann: Wer was beisteuern will, der kann es machen. Also die Seite ist praktisch auf GitHub. Wie würde man beisteuern? Also wenn ich jetzt für irgendeine Firma außerhalb von INNOQ arbeite, wie würde man sich mit euch in Verbindung setzen? Was wäre zu tun? Felix?
Felix Schumacher Ja, antworte ich mal kurz drauf. Also geht auf unsere Seite architecture-antipatterns.tech und dann findet ihr oben einen großen Knopf, wo drauf steht Contribute on GitHub. Und wenn man da draufklickt, landet man dann auf unserem GitHub-Repo. Es ist halt eine GitHub-Page. Und in GitHub findet man in unserer README auch eine ausführliche Contribution-Guideline, wie man denn mitarbeiten kann, was man machen kann und wie das Ganze ablaufen soll.
Felix Schumacher Genau, Christian, vielleicht kannst du mal einmal so grob sagen, wie wir uns den Prozess vorstellen, wie Leute mitarbeiten können, wenn du magst.
Christian Jacobs: Ja, also gerne. Die Idee kommt eben auf die Seite und wenn ihr eine Idee für ein neues Antipattern, für eine Case Study habt, dann folgt unser GitHub-Projekt und stellt ein Pull-Request und wir gucken uns das zeitnah an. Also wir treffen uns alle 14 Tage und würden dann eben die Pull-Requests bearbeiten.
Christian Jacobs: Und wenn wir Fragen haben oder Anmerkungen, dann melden wir uns wieder bei euch. Ihr werdet namentlich erwähnt in der Case Study oder in dem Antipattern. Genau.
Sven Johann: Ja, sehr schön, sehr schön. Also ich denke, so irgendwann kam mal dieses Pattern Movement vor, keine Ahnung, fast 30 Jahren oder über 30 Jahren, als die ersten Bücher dazu rauskamen. Aber mittlerweile gibt es auch Antipattern Bücher. Also ich hatte neulich tatsächlich so einen Podcast gemacht, also Case Podcast mit Aino Corry, die hat so ein Retrospectives Antipattern Buch geschrieben. Auch der der Michael Nygard, der hat in seinem Release-It Buch, hat er auch immer so, so eine Sektion Patterns und dann auch Antipatterns. Das find ich eigentlich immer ganz, gut, weil ja, Dinge können halt auch schiefgehen, selbst bei bestem Wissen und Gewissen beim Vorgehen.
Felix Schumacher Da würde ich aber nochmal ganz kurz, ganz dringend nochmal das betonen, was der Christian vorhin gesagt hat zu den Antipatterns. Nämlich, dass es ganz stark kontextabhängig ist. Wir sagen nicht, das was da steht ist immer falsch, in jeder Situation. Das ist wichtig, das müssen wir immer betonen. Weil es kann natürlich sein, dass für dich in deinem Projekt genau das, was wir hier als Antipattern beschreiben, eine total gute und funktionierende Lösung sein kann. Und wir sind nur der Meinung, wir haben es in der Mehrzahl unserer Kundenprojekte, wo wir waren oder wo wir es miterlebt haben in den Projekten, wo wir unterwegs waren, als eher unpraktisch, unhandlich, negativ erlebt. Aber es kann natürlich sein, dass es nach Kontext halt doch eine gute Idee ist. Das müssen wir immer betonen. Es ist nicht immer schlecht und wir würden uns auch natürlich mal über Feedback oder Input freuen, wo jemand sagt, das ist doch kein Antipattern bei uns, hat das ganz toll funktioniert. Das ist ja auch spannend zu wissen.
Sven Johann: Ja, ich habe mal so einen Vortrag gehalten, da habe ich irgendwie in die Menge posaunt: Jeder, der ein Big Rewrite macht, ist ein Vollidiot. Ja, also so ungefähr. Also vielleicht Vollidiot habe ich nicht gesagt, aber habe ich gedacht. Und da gab es aber interessante Diskussionen danach. Wann, also grundsätzlich ist so ein Big Rewrite wirklich keine gute Idee. Dann kamen dann doch irgendwie Vorschläge, wann es doch eine gute Idee sein kann. Andreas.
Andreas Voigt: Ja, ich würde auch sagen, das ist ja auch so, dass bestimmte Pattern und gute Architekturideen durch Änderungen der Technologie, also Cloud oder solche Dinge, dass die plötzlich gar nicht mehr so gut sind. Das kann sein, dass es eine ganz tolle, super Architektur war und zu der Zeit angemessen, aber wenn man jetzt das Ding in die Cloud bringen will, vielleicht dann nicht mehr so hilfreich ist. Da gibt es also ganz viele Gründe, warum über die Evolution eines vor allen Dingen erfolgreich lang laufenden Projekts sich die Wahrnehmung dahin ankommt. Das wollen wir auch respektieren.
Felix Schumacher Stefan hatte auch in seinem Vortrag immer dieses sehr schöne Beispiel mit Netflix. Netflix hat halt total viele coole Patterns im Architekturbereich gebaut und ganz viele Leute haben dann angefangen diese Patterns bei sich zu übernehmen. Und Stefan meinte halt, das ist total cool und er findet Netflix halt auch super, aber ist halt kontextabhängig und die meisten Leute, die diese Patterns einfach übernommen haben, sind halt nicht Netflix und haben damit dann halt Probleme versucht zu lösen, die sie im Zweifelsfall gar nicht hatten oder so. Das ist immer ein super Beispiel dafür gewesen, finde ich.
Sven Johann: Ja klar, also kopiere nie die Idee oder die Lösung, sondern den Weg, der zu Lösungen geführt hat. Also dass man sozusagen seine eigene Lösung zu seinem Problem findet.
Christian Jacobs: Ich wollte noch sagen, dass Ideen von anderen kopieren, ist in meisten Fällen eine Praxis in der Softwareentwicklung sehr gut. Aber man muss eben immer auch verstehen, wieso man das macht. Also wieso hat Netflix irgendwie alles in kleine Microservices aufgeteilt? Und was ist der Benefit? Und muss ich das jetzt auch machen oder mache ich das jetzt gerade einfach nur, weil es irgendwie hip ist, irgendwie alles in kleine Microservices zu schneiden? Also das Kopieren ist nicht das Problem, sondern das Gucken, ob es eben auch eine Lösung für das aktuelle Problem bei einem selber ist.
Felix Schumacher Ja, vielleicht genau dazu haben wir auf jeden Fall schon ein halbwegs fertig beschriebenes Antipattern auf der Seite, was so ein Themenbereich ziemlich genau anspricht. Aus verschiedenen Gründen ist es vielleicht nicht ganz so einfach, aber Cargo Culting spricht halt dieses Thema an. Der Name ist so ein bisschen umstritten von Cargo Culting, wissen wir auch. Wir haben das versucht, so neutral wie möglich zu beschreiben, aber es ist halt unter dem Begriff bekannt, wenn man Sachen einfach nachmacht, ohne sie zu versuchen zu verstehen. Genau das, was Christian eben sagte.
Sven Johann: Ja, also Cargo Culting, ah, jetzt sehe ich es auch gerade. Also ich bin gerade auf der Seite und Cargo culting ist das erste, dann Domain Allergy, Emotional Attachment, Infrastructure Ignorance, Malignant Growth, Misapplied Genericity, Never change a running system, Over-Engineering, Over-Modularization, Under-Modularization. Ich würde mal gern in so einen Pattern reinzoomen. Also wir wollen ja nicht, wir haben ja nicht die Zeit für alle Patterns zu diskutieren. Aber jetzt habe ich es schon wieder vergessen. Ihr habt euch eins ausgesucht. Was war das denn nochmal?
Felix Schumacher Misapplied Genericity würden wir gern mit dir besprechen. Unter anderem, weil es ursprünglich auch mal auf dein Mist mitgewachsen ist.
Sven Johann: Ach so, genau. Stimmt, so war es, so war es. Also ich glaube, es kam, also wenn ich mich versuche zurück zu erinnern, also ich habe den Vorschlag nicht gemacht, der kam, also der kam irgendwo andersher. Genau, wer möchte denn mal was zu Misapplied Genericity sagen? Also um was geht’s denn da? Christian.
Christian Jacobs: Ja, ich kann gerne versuchen, das mal kurz zusammenzufassen. Also es geht quasi, das Antipattern ist, ich versuche eine allgemeingültige Lösung zu implementieren, die für viele verschiedene Anwendungsfälle in derselben Problemdomäne funktioniert, aber ich implementiere nicht speziell für meinen Anwendungsfall. Also ich beginne viel zu früh irgendwie über allgemeine Lösungen nachzudenken, irgendwie über einen Framework, über irgendwie einen Plug-in-Mechanismus, Erweiterbarkeit für zukünftige Aufgaben, die ich aber im Moment gar nicht bearbeite. Und das birgt eben jede Menge Nachteile. Also es dauert zum einen länger. Es kann sein, dass ich das Problem, was ich eigentlich ursprünglich lösen sollte, nicht gut löse. Es ist schwerer zu verstehen, aufwändiger zu warten. Das sind nur einige Beispiele.
Sven Johann: Genau, also ich denke, das finde ich schon immer ganz gut, dass ihr nicht einfach darüber ablästert, sondern dass es wirklich so eine gute Analyse gibt, was eigentlich das Problem ist, wie kamen wir dahin, wie kommen wir nochmal raus. Felix, du wolltest noch was dazu sagen?
Felix Schumacher Wenn wir jetzt über die Gliederung sprechen, dann ist für uns wichtig, dass wir möglichst immer ein bis zwei Beispiele zu jedem Pattern haben aus der echten Welt. Denn es gibt, das wissen wir auch, durchaus auch andere Seiten im Internet und Bücher, die Antipatterns auf Architekturebene beschreiben. Der Mehrwert, den wir halt aus meiner Sicht bieten, ist halt, wir sind viel in Kundenprojekten gerade auf Architekturebene unterwegs und haben diese Patterns halt in der echten Welt erkannt und haben dann quasi diese Problemsituationen versucht zu generalisieren und zu beschreiben, wie sie halt in echt aufgetreten sind und nicht irgendwie, wie wir uns überlegt haben, wie das Ganze schief laufen kann. Und dann kommt daher natürlich dann auch die Gliederung mit, wie kommt es überhaupt dazu oder wie ist es denn dazu gekommen, was immer ganz interessant ist, um halt zu versuchen, diese Probleme im Vorfeld für die Zukunft zu umgehen und zu vermeiden. Und halt wichtig auch immer: Wie kommt man aus dem Sumpf raus, wenn man schon drin steckt? Da müssen wir zugeben, ist aber ab und zu auch einfach nur der Kommentar, wissen wir nicht, hat bei unserer Projektfahrung nicht stattgefunden und/oder es ist einfach alles weggeschmissen worden und es wurde neu gemacht und das kann aber auch eine Lösung sein. Was dann der Big Rewrite wäre, den du meintest, der nicht so gut ist, aber ja gut.
Sven Johann: Ja, ja, manchmal okay. Fand ich wirklich sehr schwer zu sagen, warum passiert das? Also warum hat jemand gedacht, dass das eine gute Idee ist, das so zu tun? Weil ja, keiner, keiner steht morgens auf und sagt, also heute will ich mal alle so richtig in die Scheiße reiten, so ungefähr. Also es gibt immer, es gibt immer eine gute Idee dahinter. Ja, Felix.
Felix Schumacher Ja genau, also da gehst du jetzt schon darauf ein, wie wir quasi unsere Beispiele, unsere Case Studies gegliedert haben, weil genau den Gedanken, den du gerade beschrieben hast, den hatten wir halt auch, da warst du ja auch dabei, wie wir uns damals über diese Gliederungen unterhalten haben und haben wir halt gesagt, jede dieser Problemsituationen, in denen wir denn da unterwegs waren, hatte aber ursprünglich mal eine gute Idee dahinter. Das ist auch einfach schön, sowas zu beschreiben, weil zum einen bist du dann in einer wertschätzenden Situation, in einem wertschätzenden Umgang mit dem ganzen Projekt unterwegs, denn wie du eben schon sagtest, niemand setzt sich morgens hin und sagt, heute baue ich mal ein Projekt, richtig schlecht, so mistig, wie ich nur kann. Das ist ja Quatsch. Und oft ist es halt einfach so, dass über die Zeit die Leute, die die guten Ideen hatten, weggegangen sind. Die anderen Leute, die denn da waren oder neu dazugekommen sind, haben sie im Zweifelsfall nicht verstanden oder nicht gewusst, warum es diese Ideen gab, weil sie vielleicht nicht dokumentiert waren und so weiter und so fort. Und es gab aber meistens immer eine gute Idee. Ob die noch bekannt ist im Projektumfeld ist halt immer die Frage.
Sven Johann: Ja, ich wollte eigentlich gar nicht so weit abdriften vom Beispiel, ist mir jetzt nicht gelungen, sorry. Also wir würden auch wieder zum Beispiel zu den Pattern zurückkommen. Aber Andreas, du wolltest noch was sagen.
Andreas Voigt: Ja, ich wollte nur gerade sagen, weil wir gesagt haben, manchmal haben wir auch keine Lösung gefunden in diesem Bereich. Das Thema ist, wir leben sehr stark von real existierenden Projekten, also wir denken uns nichts aus und Architektur ist halt auch eine Sache, die etwas langsamer vergeht, im Gegensatz zum coden, das kann man häufig schneller machen und deswegen leben wir eigentlich auch davon, dass möglichst viele Leute mitmachen und ihre Ideen mit reinbringen und auch ihre möglichen Lösungen, die wir gar nicht gesehen haben. Deswegen wäre es super, wenn wir den Kreis etwas vergrößern könnten, von vielen Ideen leben. Gerade Case Studies sind uns extrem wichtig, dass wir auch im Beispiel möglichst mehr als eine Case Study haben, möglichst drei oder vier oder so. Traum, aber gucken, ob wir da hinkommen. Und auch die überlagern sich diese Pattern. Das ist ja auch so, dass an der Case Study sicherlich mehrere Antipattern auftreten oder in der gleichen Ausprägung auftreten. Und diesen Spektrum abzubilden, ist natürlich super, wenn wir da mehr Fundus hätten.
Sven Johann: Genau, also hier unser Misapplied Genericity. Da haben wir schon locker mal fünf Beispiele. Da gehen wir auf eins ja mal nachher noch ein.
Andreas Voigt: Okay, ich wollte auch nicht so weit abdriften.
Sven Johann: Wir sind ein bisschen abgedriftet, aber das Problem ist halt, man baut irgendwie so eine übergenerische Lösung. Das ist die Frage, warum passiert das überhaupt? Warum kommen Leute eigentlich auf die Idee, solche generischen Lösungen zu bauen? Und da habt ihr halt im Prinzip auch versucht, das zu beschreiben, Christian.
Christian Jacobs: Ja, also ich habe das auch selber erlebt und die Devise ist dann von einigen Beteiligten oder eben vom Auftraggebenden, wenn wir das jetzt schon entwickeln, dann machen wir das gleich so, dass wir dann in der Zukunft noch dieses und jenes Problemen damit lösen können. Baut das bitte irgendwie möglichst generisch, möglichst erweiterbar, sodass wir das nachher irgendwie selber irgendwie pflegen können, dass wir dann das alles einstellen können, alles konfigurieren können und genau, dass nachher keiner mehr das entwickeln muss, sondern dass wir das alles irgendwie über ein großes Konfigurationsfile irgendwie einstellen können.
Sven Johann: Ja, der ewige Traum einmal gemacht und dann reicht’s für die Zukunft.
Felix Schumacher Ja, ich weiß nicht, immer wenn ich über dieses Pattern rüber gucke, dann sagt mein Kopf so auf Coding-Ebene, haben wir alle irgendwann mal YAGNI gehört, ne, you ain’t gonna need it, weil das ist nämlich auch oft so ein Problem, in das man nämlich reinläuft, wenn man diese generische Lösung baut, weil es kann nämlich genauso gut sein, dass man schon am Anfang sagt, ja, wir bauen das und dann brauchen wir für die Zukunft, sparen uns ganz viel Aufwand und dann kommen diese Projekte oder diese Erweiterungen des Projekts in der Zukunft, für die man schon ganz viel vorbereitet hat, einfach gar nicht zustande. Das habe ich auch schon erlebt. Wir haben dieses total tolle Modulsystem gebaut, mit dem wir, wenn dann neue Produkte dazukommen, die ganz einfach aufnehmen können. Und dann stellte sich aber raus, wir laufen in Produktionen in Performance-Probleme, lasst uns mal keine neuen Produkte aufnehmen, das können wir uns gar nicht erlauben, so nach dem Motto. Und dann wurde das ganze Ding doch weggeschmissen deswegen. Und man hat sehr viel Aufwand in die Entwicklung von diesem Modulsystem gesteckt, bevor man überhaupt Module integriert hatte. Ist halt genau das gleiche auf Coding-Ebene wie YAGNI, finde ich.
Sven Johann: Ich bin, als ich noch mal so drüber nachgedacht habe, klar, manchmal kommt man irgendwie auf die Idee, lass uns das generisch machen und dann lösen wir es für die gesamte Firma oder für die gesamte Welt oder wie auch immer. Aber man könnte denken, da kommen ja nur Idioten drauf so ungefähr. Aber einer der schlausten Typen, mit denen ich jemals zusammengearbeitet habe, der hat uns auch mal sozusagen in so ein Unglück gestürzt. Der Typ, der war super. Es gibt niemanden, mit dem ich jemals gearbeitet habe, der besser ist. Der ist Faktor 10 besser als ich. Und selbst der ist irgendwie, der hat gesagt, ja, wir machen da so ein Produkt draus. Und dann habe ich gemeint, nee, ich glaube, das ist keine gute Idee. Und die Frage, die ich, also die Antwort, die ich noch hatte war, als ich Student war, die höchste Form der Wiederverwertung ist ja, sind ja Software-Produktlinien. Und da versucht man ja immer so einen generischen Kern, so ein Domain-Engineering zu machen und dann so ein Variabilitäten-Engineering. Und das war damals halt unheimlich schwer. Und dann hab ich mal so einen von damals noch mal getroffen, der mittlerweile Prof ist, und der meinte: Also, das macht niemand mehr. Also, so wie wir damals versucht haben, generisch eine Lösung von Anfang an zu bauen, funktioniert eh nicht. Also, wir bauen jetzt immer nur konkrete Lösungen. Und wenn wir mal fünf konkrete Lösungen haben, da machen wir mal eine Produktlinie draus. Aber ich konnte mir damit den Mund fusselig reden. Mein Kollege, der hat gedacht, nee, so alles ganz einfach. Wir machen das jetzt. Needless to say, das ist gescheitert.
Felix Schumacher Ja, ich muss auch immer so ein bisschen dran denken. Also ich glaube, wenn du das schaffst, als generisches Produkt weltweit so weit zu etablieren, dass da ganz viele drauf setzen, dann hast du vielleicht die Möglichkeit, dass das klappt. Ich denke halt immer so an SAP auch so ein bisschen. Das ist eine generische Lösung für ganz viele Unternehmen und hat aber einfach die Durchsetzungskraft entwickelt. Aber andererseits gibt es halt auch echt viele Leute, die komplett nichts anderes machen als Customizing für SAP in irgendwelchen Firmen. Also ich möchte es nicht machen müssen, wenn ich darauf verzichten kann. Aber seien wir ehrlich, das ist ein großer Industriezweig, oder?
Sven Johann: Ja, ich denke, so Standard Software. Klar, also ich will jetzt auch nichts gegen generische Software sagen, aber ich wollte nur sagen, das ist halt unheimlich schwer. Also jetzt, wo du es so sagst, denke ich so, also SAP, die machen das wahrscheinlich schon ganz gut.
Christian Jacobs: Es spricht ja auch nichts dagegen, irgendwie für einen Kunden generische Software einzukaufen und die dann eben genau auf die Bedürfnisse des Kunden irgendwie zuzuschneiden. Aber was eben dieses Antipattern beschreibt, ist, dass man nach einer spezifischen Lösung gefragt wird und dann erstmal anfängt, eine generische Lösung zu programmieren. Also niemand würde auf die Idee kommen, wenn jemand jetzt irgendwie eigentlich SAP braucht, dann erstmal SAP selber zu programmieren, um es anschließend irgendwie zu konfigurieren.
Sven Johann: Ja, das stimmt. Wir sind ja hier nicht in, ich sag mal, commercial off the shelf unterwegs. Wir machen alle Individualsoftware Entwicklung und dann wirst du nach einer individuellen Lösung gefragt und du kommst mit der generischen Lösung. Das ist vielleicht auch das, was ihr am Anfang gemeint habt. So ein Pattern ist nicht per se schlecht, je nach Kontext. Aber generische Programmierung ist bei Individualsoftware vielleicht nicht das beste Muster.
Felix Schumacher Ich mein, wie wir über das Pattern gesprochen haben, hatte Christian noch mal irgendwie sowas erwähnt. Ich weiß nicht, ob wir es mit in den Text hatten, aber irgendwie Regel der drei oder so. Christian, weißt du noch, was ich meine? Mit, dass du irgendwie erst nach so und so viel anfängst generisch zu werden. Kannst du es noch mal erzählen?
Christian Jacobs: Ja, aber ich glaube, das war irgendwie, das gibt es auch quasi eine Ebene tiefer auf der Coding-Ebene, dass du eben dann anfängst, wenn du quasi den, ich glaube, das hat Theo erwähnt, wenn du merkst, du kopierst immer den gleichen Abschnitt, in deiner Funktion immer wieder, also du machst copy and paste in deinem Code, dass du quasi, wenn du das dritte Mal kopierst, dass du dann darüber nachdenken solltest, das in eine eigene Funktion auszulagern. Und das kann man natürlich auch auf die Architektur-Ebene irgendwo übertragen, dass wenn du implementierst irgendwie eine spezifische Lösung und dann implementierst du irgendwie noch eine spezifische Lösung. Und du merkst, du kopierst immer wieder den gleichen Code oder das Projekt irgendwie mit anderen Parametern oder so, dass du dann anfängst, wenn du das irgendwie jetzt das dritte Mal kopierst, dass du dann über eine generische Lösung nachdenken solltest und nicht vorher.
Sven Johann: Ja, das passt irgendwie auch so zu der Idee von den Produktlinien, dass die Firmen halt, ja, die ähnliche Systeme halt immer from scratch bauen und dann vielleicht das alte System kopieren und dann sehen, ah, also irgendwann kommen so die Patterns raus und man sagt, ah, hier gibt es vielleicht einen generischen Kern. Und dass man dann irgendwie zu so einer Produktlinie kommt. Also nicht, dass ich Produktlinien-Experte bin, das ist alles Hörensagen. Aber die, wenn wir jetzt so eine super generische Lösung haben, die uns, also wir riechen ja meistens, dass es dazu kommt. Also ich habe jetzt auch wieder so ein Projekt, da ist leider wieder zu spät. Da gibt es wieder so ein Framework benutzen, das passt uns nicht. Es heißt aber ja, sorry, können wir jetzt nicht ändern, weil das gilt für die ganze Firma. Und dann denke ich so, okay, aber können wir eigentlich verhindern, dass wir in so eine Situation kommen? Wie würdet ihr es hier verhindern können? Wie können wir dagegenhalten?
Felix Schumacher Ja, also es kommt natürlich ein bisschen drauf an, aus welcher Richtung der Drive zur generischen Lösung kommt. Der kann natürlich von den Entwicklern kommen, weil die immer, weil wir Entwickler nun mal gerne von Haus aus immer gleich eine Lösung bauen, die die komplette Problemkategorie löst und nicht nur das spezifische Problem. Da wäre es dann so, ich sag mal, gut, wenn uns dann, keine Ahnung, ein Scrum Master/Product Owner uns Entwicklern dann ein bisschen in Zaum hält und das mitbekommt. Das Ganze kann aber auch noch von der anderen Seite kommen, das haben wir auch beschrieben. Das ist halt, wenn es direkt von der Anforderungsseite kommt und da ist es dann unser Job als Entwickler zu sagen, hey, vielleicht ist es gar nicht so sinnvoll, direkt die generische Lösung zu bauen, sondern lass uns erstmal eine Lösung implementieren, damit wir vielleicht Erfahrung auch gesammelt haben, wie man überhaupt eine Lösung implementiert, bevor wir es gleich direkt generalisieren.
Christian Jacobs: Ja, genau. Ich wollte in die gleiche Richtung wie Felix. Und zwar ich als Entwickler:in, ich kenne ja am Anfang gar nicht die Problemdomäne in- und auswendig, sondern ich komme rein in das Projekt und lerne die Fachlichkeit erst Stück für Stück kennen. Und ich bin im Prinzip am Anfang gar nicht in der Lage, eine gute generische Lösung zu entwickeln, weil ich die Fachlichkeit ja gar nicht kenne. Und also mir geht es so, dass wenn ich jetzt eben eine spezifische Lösung entwickle, Stück für Stück die Fachlichkeit immer weiter irgendwie durch Fragen und Antworten verstehe. Und ich kann im Prinzip erst, nachdem ich eben die spezifische Lösung entwickelt habe, erst anfangen mit einer generischen Lösung. Weil also in den Beispielen, die wir jetzt irgendwie kennen, da hat sich dann später herausgestellt, dass die generische Lösung, die man am Anfang irgendwie erdacht hat, das war eben nur Theorie. Da fehlte die Praxis von einer spezifischen Lösung. Es ist dann eben auch wahrscheinlich schwieriger zu dem Zeitpunkt, so eine generische Lösung nochmal umzuschreiben, weil man ja schon so weit irgendwie fortgeschritten ist im Entwicklungsprozess. Also von daher ist unsere Empfehlung, erstmal immer mit einer spezifischen Lösung für das eine Problem anzufangen und generische Lösungen erst später darüber nachzudenken.
Sven Johann: Ja, es ist verführerisch, denke ich, für viele, aber wir sollten, ich gebe dir Recht, also es ist wirklich wichtig, erstmal das konkrete Problem zu lösen. Okay, der letzte Punkt bei jedem Pattern ist dann, jetzt sind wir in den Brunnen gefallen, wie kommen wir wieder raus? Wie würden wir hier wieder rauskommen?
Andreas Voigt: Soll ich mal anfangen? Naja, das Problem ist natürlich, jetzt haben wir eine sehr generische Lösung, müssen wir irgendwie spezifischer machen. Es gibt da einen Ansatz, Big Bang, wir machen alles neu, schmeißen alles weg. Das ist natürlich extrem teuer und wahrscheinlich sprengt man jeden Zeitplan und gefährdet das Projekt. Da gibt es ja auch ein schönes Beispiel, das du da angeführt hast, was man jetzt nicht machen sollte. Ich glaube, Netscape war das gewesen. Dann, deshalb wäre die Idee, dass inkrementell langsam mehr herauszufinden, wie die wirklich spezifischen Anforderungen sind und die auch spezifisch umzusetzen und also im Prinzip klassisch Architekturarbeit zu machen. Da langsam wieder rückbauen und Schritt für Schritt auch mit Prototypen vorzugehen, dass man das wieder zu einem normalen Projekt bekommt. Und genau, da gibt es keine Magie, glaube ich. Das ist einfach harte Arbeit.
Sven Johann: Ja, also ich muss sagen, ich glaube bei den Beispielen, die ich beigesteuert habe, da musste man tatsächlich alles wegwerfen. Also obwohl ich nicht der Freund bin von wegwerfen, aber da war alles hoffnungslos. Am Ende sagt ihr “in other words do classic architecture work”. Also ich denke auch. Also einfach. Versuchen, inkrementell dann zu verbessern.
Christian Jacobs: Ja, also die Idee ist da eben, wenn man eben generische Abläufe dann wieder zu spezifischen Abläufen macht, also dass man jetzt Sachen, die irgendwie aus einer Konfiguration geladen werden, dass man die wieder hardcoded, dass man irgendwie Sachen, die irgendwie lose gekoppelt sind, dann zusammen irgendwie in einem Modul implementiert. Stück für Stück eben Dynamik wieder rausnimmt, um zu einer spezifischen Lösung zu kommen.
Sven Johann: Ja, also ich bin immer noch für die Case Study, die wir jetzt noch gleich besprechen. Die ist zwar schon 15 Jahre alt, aber immer wenn ich drüber nachdenke, dann kriege ich Bauchweh und wir nähern uns der Case Study.
Andreas Voigt: Ich würde sagen, ein wichtiger Punkt ist auch, dass man diese Fachlichkeit wieder gewinnt. Häufig, wenn man so abstrakte Lösungen hat, geht ja total verloren, damit dann irgendwie irgendwas Object genannt wird oder sonst was. Und eigentlich muss man auch die Business-Sprache da wieder reinkriegen, dass man wieder die Domäne versteht. Was mache ich da eigentlich? Aber teilweise hat man so Abstraktionen dann in den Klassen drin, dass man in den Tabellen und so weiter, überall, dass man gar nicht mehr versteht, was man eigentlich da getan hat. Total schwierig ist damit zu entwickeln. Das muss man wieder ein bisschen zurückschrauben.
Sven Johann: Ja, ist auch so ein anderes Antipattern, was ihr habt. Domain Allergy, also man ignoriert irgendwie die Domäne, alles ist generisch konfigurierbar und man versteht eigentlich gar nicht, was ist das überhaupt für ein System. Felix, du wolltest auch noch was sagen?
Felix Schumacher Ja, ich wollte eigentlich sagen, dass wir dafür einen Antipattern auch haben, was genau die Situation beschreibt. Aber hastest du schon jetzt mit auf dem Schirm. Alles gut.
Sven Johann: Okay, genau so viel zu den Pattern. Ich würde mal gerade zu einer Case Study gehen. Also ihr habt ja, wenn ich hier so gucke, Case Studies gibt es auch. Drei, vier, fünf, sechs, sieben, acht, neun, zehn, elf. Also auf jeden Fall schon eine Menge und ich denke auch Aufrufe an alle: mehr Case Studies. Ich glaube, das ist eigentlich auch eine gute Referenz, oder? Also wenn, wenn jetzt ein Kunde, kommt mir gerade so, wenn ein Kunde sagt, ah, hier machen wir eine generische Lösung oder wie auch immer, dann kann ich mal sagen, hier, da ist das Pattern. Guck mal nach, ja. Und da haben wir einen Haufen, also wir und die Community, wir haben einen Haufen Beispiele gesammelt, wie es schiefgehen kann.
Andreas Voigt: Ich hab gerade anekdotisch: gerade vor kurzem hat ein Kollege von mir das gemacht. Der hat an unsere Webseite verwiesen und hat gesagt, schau mal da, das ist keine gute Idee. Also, scheint zu funktionieren.
Sven Johann: Ah, ok. Sehr gut.
Sven Johann: Genau, dann also die Case Study, ich würde sie jetzt gar nicht mehr so unbedingt im Detail durchgehen. Ihr habt ja auch eine, ihr habt eine rausgepickt. Aber vielleicht können wir so im ganz Groben drüber reden, wie diese Case Studies aufgebaut sind, weil jede Case Study, also alle Case Studies haben so ein gewisses Format. Hat mir eben kurz angerissen. Wer möchte das Format gerade erklären? Felix, dann legen wir los.
Felix Schumacher Ja, genau, also auch da haben wir uns wieder auf ein möglichst einheitliches Format versucht zu einigen. Wir geben dem der ganzen Case da die möglichst gut beschriebenen Namen oder versuchen es zumindest. Klar, wir nennen keine Kundennamen oder konkreten Projektnamen, auch wenn das bleibt anonym. Wir versuchen das so ein bisschen abstrakt zu beschreiben, was eigentlich das Problem war. Wir wollen ja nicht auf irgend wem rumhacken und sagen Mensch, wie schlecht war das? Sondern wir wollen halt wertschätzend damit umgehen und versuchen daraus zu lernen. Das ist ja der Sinn unseres ganzen Projekts.
Sven Johann: Sorry, dass ich gerade so rein grätsche. Ich denke immer so, ein ehemaliger Kollege von mir hat immer gesagt, wer fehlerlos ist, soll den ersten Stein werfen. Wir machen alle Dinge falsch.
Felix Schumacher Klar, ja. Aber deswegen, wir beschreiben halt immer erst mal den Systemhintergrund, also die technische Situation, auch die Situation in der Firma, die Teamsituation, wie war das ganze Projekt halt aufgestellt. Den Hintergrund, der wichtig ist, um zu verstehen, warum diese Case Study jetzt problematisch war. Aber danach kommt direkt halt die gute Idee, hatten wir vorhin schon mal angeschnitten. Irgendwann war das ganze, weswegen man in die Richtung, in die man losgelaufen ist, war eine gute Idee und es gab einen sinnvollen Grund, das zu tun. Und das wollen wir da auch beschreiben und darauf eingehen. Und dann gibt es halt immer irgendwie so ein Problempunkt. Manchmal gibt es tatsächlich so einen konkreten Wendepunkt, der dann auch beschrieben wird. Aber in der Regel läuft es dann irgendwann schief. Und dann versuchen wir mit dem nächsten Punkt, immer mit dem nächsten Kapitel zu erklären, warum, halt was schief gegangen ist. Das Ganze matchen wir dann im Kapitel anschließend auf unsere Antipatterns. Soll heißen, da gibt’s immer mehrere. Also, ich hab eigentlich noch nicht erlebt, dass wir eine Case Study, die nicht gleich mehrere Antipatterns gematcht hat, sozusagen. Meistens sind’s immer gleich ein, zwei, drei oder mehrere, wie auch immer. Und am Ende wollen wir dann halt auch noch besprechen, wie das ganze denn hoffentlich gelöst wurde, wenn es denn gelöst wurde, weil es gibt nicht immer die Situation, dass man dann lange genug im Projekt war und das begleitet hat, dass das ganze auch gelöst wurde. Oder wie gesagt, es kommt auch ab und zu vor, dass die Lösung gewesen ist, es wurde alles weggeschmissen und neu gemacht oder anderweitige Lösung. Naja.
Sven Johann: Also ich muss immer so innerlich ein bisschen weinen, wenn ich höre, wurde alles weggeworfen, das schöne Geld. Aber ja. Ja, das ist schon interessant. Also, so wie du sagst, wenn sowas schief geht, dann gehen halt direkt mehrere Dinge schief. Also, das ist nicht immer nur ein Antipattern, sondern ein Antipattern kommt selten allein vielleicht. Kommt immer im Team. Viele Sachen gehen schief. Ja, wenn du sagst, ich denke auch, was war die gute Idee? Also da bin ich wirklich großer, großer Freund. Ich wiederhole mich, ich weiß. Aber ich denke auch, irgendwas hört sich immer verführerisch an. Mit irgendwas fängt man immer gut an. Und da finde ich auch schön, hier was du gesagt hast, dass irgendwann so ein Kipppunkt kommt.
Sven Johann: Ich glaube, das kennen wir alle. Wir fangen an. Die Idee hört sich gut an. Wir laufen los. Am Anfang ist vielleicht noch alles toll. Das läuft so, wie wir es uns vorstellen. Und dann wird es so graduell, wird es schlechter. Und irgendwann, dann fangen die ersten Leute an, sich zu beschweren. Die Stimmen werden lauter. Und irgendwann ist klar … Jetzt geht es nicht mehr weiter. Jetzt ist auch dem Letzten klar, dass es nicht mehr weitergeht. Ja, vielleicht ist es auch ein Problem eigentlich. War das bei allen Cases nicht so? Ich hab nicht den Überblick. Oder gab es auch Cases, wo es direkt von Anfang an irgendwie ein Riesenproblem gab?
Felix Schumacher Also, wo es von Anfang an ein Riesenproblem gab, wüsste ich jetzt nicht. Aber wir haben durchaus nicht immer den Fall, dass es so einen Turning Point gab, so einen konkreten, der sich benennen ließ, sondern sehr oft, dass es so ein schleichender Prozess ist. Ich sag mal, dann verlassen Leute, die die Firma oder das Projekt, die halt entscheidend mit an der Architektur mitgearbeitet haben, und die Leute, die dann danach folgend sind, haben das ursprünglich gute Konzept vielleicht nicht ganz verstanden. Wie gesagt, oft hat man auch das Problem, dass es zu den Entscheidungen nicht die passenden ADRs gibt, um nachzuvollziehen, warum diese Entscheidungen getroffen worden sind. Oder diese Entscheidungen auch zu revidieren, falls der Kontext sich geändert hat. Wenn das nicht dokumentiert ist, sind die Entscheidungen vielleicht auch gar nicht mehr so gut. Kann man aber dann nicht mehr nachvollziehen. Sowas ist dann öfters das Problem. Oder wie gesagt, Fluktuation. Also, was wir halt oft festgestellt haben, hatte Christian auch gesagt, dass wir entweder immer so ein Problem auf so einer, ich sag mal, strukturellen Ebene des Codes öfters haben. Wie haben wir unsere Architektur strukturiert? Oder halt, wie wird im Team zusammengearbeitet? Das sind oft so die beiden Kategorien, die wir unterschieden haben. Wobei, was heißt unterschieden haben? Also wir haben da jetzt nicht die Patterns markiert als das hier ist eher so Teamproblem und das hier ist eher so Strukturproblem, sondern das ist uns einfach nur aufgefallen, dass das eine oder das andere öfters mal das Problem ist. Korrigiert mich gerne Christian Andreas, wenn ich Quatsch erzähle.
Christian Jacobs: Nö, das passt so.
Sven Johann: Ja, jetzt seid ihr schon seit drei Jahren dran, habt ja einen Haufen Case Studies, einen Haufen Patterns ausgearbeitet, einige sind noch sozusagen in the making. Inwieweit hat sich eigentlich euer Blick auf Architektur verändert, also innerhalb der letzten drei Jahre? Also ihr könnt auch sagen, ist alles gleich geblieben. Aber ich denke, also hat es irgendwas mit euch gemacht, wo ihr jetzt anders in die Projekte reingeht, anders Architektur macht?
Felix Schumacher Ja, also was ich auf jeden Fall sehr wertgeschätzt oder sehr gelernt habe wertzuschätzen ist, wenn ich in ein Projekt reinkomme und ich habe dann, es gibt erstmal schon mal eine Architekturdokumentation. Da freue ich mich das erste Mal. Die Architekturdokumentation hat eine Struktur, mit der ich was anfangen kann. Gerne zum Beispiel arc42, da freue ich mich nochmal. Und dann finde ich auch noch verlinkt irgendwo zu den ganzen Entscheidungen, die getroffen sind, ADRs. Die haben auch den Kontext beschrieben und erklären mir, warum diese Entscheidung getroffen ist. Wenn ich das vorfinde, dann freue ich mich schon immer mal, weil dann habe ich eine Möglichkeit für mich als neuer Mensch in dem Projekt nachzuvollziehen, genau was zum Beispiel die ursprünglich gute Idee war, das ist nämlich immer schon mal gut, weil dann man guckt ja oft dann irgendwie auf was rauf und denkt sich, ich habe jetzt hier nicht die schöne grüne Wiese, ich bin in einem Projekt mit Software, die es schon länger gibt, das ist ja alles ganz schlimm und furchtbar und wenn man dann aber verstehen kann, ah nee, also als damals das hier die grüne Wiese war, sind die mit den und den Ideen losgelaufen und die finde ich dann auch wieder in dem Code, den ich zum Beispiel lese und finde die guten Ideen wieder und denke ja eigentlich ist das eine ganz gute Idee und eigentlich ganz cool was die hier gebaut haben, dann habe ich eine höhere Wertschätzung im Projekt, eine höhere Wertschätzung den Leuten gegenüber und ich verstehe auch, warum die das gemacht haben und habe dann auch vielleicht mehr Bock genau daran weiter zu arbeiten und diese Ideen wieder hervorzubringen. Sollten sie ein bisschen untergegangen sein. Das ist so, was ich für mich mitgenommen habe aus dem Ganzen.
Sven Johann: Also würde es dann auch, also wenn du jetzt selbst auf der grünen Wiese anfängst, also höre ich natürlich jetzt so raus, also ganz klar, du würdest auch arc42 oder irgendwas, also kann ja auch C4 oder wie auch immer sein, aber große Entscheidungen, die von großer Architekturrelevanz immer mit ADR, immer in großer Runde diskutieren.
Felix Schumacher Ja, wenn es irgendwie geht, ja. Ich habe es auch mal gehabt, noch beim alten Arbeitgeber, wo ich in einem Projekt war, wo das schon sehr lange lief. Das ist auch mal mit sehr guten Ideen gestartet, aber die Leute waren nicht mehr da. Und die Leute, die noch da waren, konnten mir nicht ganz erklären, weil die auch nicht am Anfang des Projektes da waren, was die gute Idee war. Und die waren nicht dokumentiert. Und irgendwann habe ich die Leute mal getroffen, die waren schon nicht mehr in der Firma, die die gute Idee ursprünglich mal hatten, und die haben die mir dann erklärt, das war eine völlig andere Idee, als überhaupt da noch vorhanden war in dem Projekt. Und hätte ich diese Idee gewusst, dann hätte ich diese Idee verstanden, und dann hätte man mit dieser Idee weiterarbeiten können, dann wäre das Ganze auch nicht so aus dem Ruder gelaufen. Am Ende ist das Projekt leider eingestellt worden, aus verschiedenen Gründen. Aber da fehlte einfach die Dokumentation, warum haben wir das gemacht? Und wie gesagt, das andere Ding, warum ich da großen Wert drauf lege, ist, dass man seinen Kontext beschreibt, die Umstände, unter denen man diese Entscheidung getroffen hat, weil die sich ja ändern können. Und wenn man dann sieht, aha, das waren die Gründe, weil die und die Umstände haben dazu geführt, dass wir diese Entscheidung getroffen haben, und ich bin jetzt in einer komplett anderen Situation, weil sich Umstand A komplett geändert hat, dann kann man ja aus dem Grund auch sagen, jetzt müssen wir diese Entscheidung nochmal uns angucken und revidieren oder anders entscheiden. Und das finde ich auch sehr wertvoll. Weil dadurch sind Entscheidungen nicht zwingend in Stein gemeißelt.
Sven Johann: Ja, finde ich eigentlich immer ganz gut, bei ADRs auch noch mal reinzuschreiben, wann wollen wir den eigentlich noch mal angucken, um zu… in einem Jahr oder so, um zu gucken, sind unsere Annahmen, ist das alles noch richtig? Andreas, du wolltest auch noch was sagen?
Andreas Voigt: Ja, eigentlich hat Felix schon was Gutes gesagt, finde ich. Persönlich ist es für mich auch so, man kriegt ein bisschen einen anderen Blick auf die Projekte, auf die Historie. Und persönlich ist es auch bei den Besprechungen, wenn wir so Antipattern besprechen, ist es immer cool, dass man das nochmal diskutieren kann, wenn man solche Sachen reflektiert, wie man das einordnet und auch mit anderen zusammen einordnet. Ich finde das wahnsinnig hilfreich. Man kriegt so eine gewisse Distanz dazu. Man betrachtet das manchmal so ein bisschen von 10.000 Fuß. Und es ist unheimlich hilfreich. Ich glaube, das kann jedem helfen. Also es geht auch darum, dass man Projekt-Erfahrungen auch verarbeitet, irgendwie. Also dass man nicht nur sagt, das war irgendwie doof oder so, sondern dass man auch fragt, warum war das so? Wie ist die Historie dazu? Wie konnten wir es besser machen? Und genauso diese Abstraktion, die wir durch unsere Arbeit hier so kriegen, die finde ich unheimlich hilfreich. Mir persönlich hat das hier geholfen von Perspektiven, die man so ein bisschen wechselt.
Sven Johann: Okay, kommen wir so langsam mal zum Ende. Eine Frage hätte ich noch und zwar, an welchen weiteren Patterns arbeitet ihr denn gerade? Worauf können wir uns freuen, was demnächst publiziert wird?
Christian Jacobs: Also wir haben jetzt leider keinen Pattern, was irgendwie kurz vor der Fertigstellung steht. Aber ja, es ist auch so ein bisschen, dass wir haben uns vorgenommen, dass wir kein neues Antipattern irgendwie auf die Seite nehmen, ohne dazu mindestens eine Case Study zu haben. Und genau, dafür müssten wir uns erstmal irgendwie eine neue Case Study finden oder jemand trägt uns eine neue Case Study zu. Und also, mich persönlich würde zum Beispiel das Antipattern mit dem Namen Horizontalism interessieren. Es wird auch irgendwie Layerism genannt, ist irgendwie damit verwandt. Da geht es darum, dass ich mein System in mehrere horizontale Layer unterteile und dass vor allem auch, dass die von getrennten Teams entwickelt werden. Also ich habe zum Beispiel mein Frontend-Team, mein Middleware-Team, mein Backend-Team und mein Data Storage-Team. Und ich muss, um ein Feature zu entwickeln, im Prinzip erstmal fünf Tickets schreiben und das dann irgendwie synchronisieren, dass jedes Team irgendwie seinen Teil umsetzt. Und genau, dann würden wir eben auch beschreiben, wieso das vielleicht keine gute Idee ist.
Sven Johann: Also ich hatte neulich in der Schulung tatsächlich jemanden, der hat genau das beschrieben. Ich kann mich leider nicht mehr genau erinnern, wer das war, aber ich suche es mal raus. Vielleicht kriege ich den motiviert, eine Case Study zu schreiben.
Felix Schumacher Allgemein gesagt haben wir auf jeden Fall noch eine riesige Liste mit potentiellen Antipatterns, die es zu beschreiben gilt. Und wenn jemand Interesse hat daran mitzuarbeiten, wir werden an Antipatterns keinen Mangel haben, aber wie Christian eben schon sagte, halten wir es halt für sinnvoll, diese Antipatterns nur dann auf die Seite zu heben, wenn wir auch eine Case Study dazu haben, weil wir halt glauben, dass erst mit einer Case Study sich so ein bisschen der wahre Wert des ganzen Antipatterns so ein bisschen. Ich habe noch ein Thema, das ich gerne mal ansprechen möchte. Ich weiß nicht, wie wir es genau nennen werden, weil Namen dieser Antipatterns sind auch immer schwer zu finden. Da kann man schon sehr lange diskutieren. Emotional Attachment war zum Beispiel so ein Antipattern. Da haben wir sehr lange diskutiert weil nennen wir es jetzt emotional attachment nennen wir es misattachment wie auch immer weiß ich gar nicht mehr ja und ich möchte gern über sowas diskutieren das nenne ich mal golf course compliance oder so ähnlich wenn man in einem Unternehmen unterwegs ist und auf einmal kommt eine Führungskraft vom Golfplatz wieder, wo alle anderen Führungskräfte erzählt haben, ja wir machen jetzt auch hier beliebiges neues Hype-Thema einfügen und dann muss man das auch umsetzen, obwohl es überhaupt für nichts gebraucht wird, kein Use-Case gibt, aber nur damit beim nächsten Mal auch quasi gesagt werden kann, ja, machen wir jetzt auch. So ganz, ganz doof gesagt. Das muss man natürlich detaillierter beschreiben. Das war jetzt auch sehr flapsig formuliert, aber ich sag mal, man hat eine Vorstellung von dem, was ich meine und vielleicht habt ihr es auch schon mal erlebt. Also ich kenne das auf jeden Fall.
Sven Johann: Ich frage mich gerade, ist es so Henne-Ei-Problem, weil jetzt hast du dieses Golfkurs-Thema genannt, zack, habe ich direkt ein Beispiel, kommt mir direkt was im Kopf. Als Christian da Horizontalism genannt hat, zack, also jetzt ist es kein Beispiel, das ich direkt erlebt habe, aber wovon ich zumindest mal gehört habe. Aber ich, ich könnte mir halt auch vorstellen, wenn ich zumindest mal die Namen, die Namen von den Patterns kennen würde, ohne dass sie beschrieben sind. Also einfach so kann man das nachschlagen. Also habt ihr irgendwo so öffentlich so eine Liste, wo die, wo die Namen stehen, mit vielleicht ein, zwei Sätzen Beschreibung? Ich glaube, das wird schon ziemlich viel triggern bei einigen Leuten.
Andreas Voigt: Ja, auf der GitHub-Seite, wenn man schaut, haben wir unter Pattern-Ideas ein paar aufgeführt. Wir haben noch ein paar mehr, aber die haben wir nicht aus sich beschrieben, aber da haben wir zum Beispiel auch Centralization-Bottleneck, das finde ich zum Beispiel auch ein schönes Pattern. Das ist eine spezielle Person im Projekt, über die alles fließen muss und wenn die mal krank ist oder in Urlaub ist, dann hängt das Ganze im Projekt. Oder so ähnliche, es gibt da so viele so Bottlenecks, die organisatorische Art sind gar nicht technische Art unbedingt.
Sven Johann: Könnte ich das wahrscheinlich auch wieder drei Beispiele nennen. Ich glaube, das geht jedem so. Also wenn man das so hört.
Andreas Voigt: Genau. Da haben wir mal ein paar drin auf jeden Fall. Da könnt ihr mal gucken.
Felix Schumacher Ja genau, ich würde nur mal ganz deutlich sagen, also geht auf unsere Seite, dann findet ihr den Link auf das Git Repo und da gibt es einen Folder in dem Repo, der heißt Pattern Ideas. Und da könnt ihr Ideen finden, wollte ich nur noch mal extra nochmal sagen, weil Andreas hat es schon gesagt, aber wenn ihr danach sucht, ihr findet da was und wie gesagt, das ist auch keine Liste mit Vollständigkeit, wir haben noch irgendwo anders eine Liste und da stehen auch noch zweistellig viele Patternideen drin. Also Ideen haben wir ohne Ende, aber wie gesagt, wir glauben halt, ohne echtes Beispiel stehen die Ideen im leeren Raum. Und ich sag mal, so ein Beispiel, so eine Case Study ist halt auch immer der Proof, dass das Problem auch nicht einfach nur ausgedacht ist. Deswegen wollen wir die gern dazu haben.
Sven Johann: Okay. Gibt es noch etwas, was ich nicht gefragt habe, was euch wichtig wäre zu erwähnen? Okay.
Christian Jacobs: Fällt mir jetzt nichts ein.
Sven Johann: Ja, also dazu vielleicht, da hätte ich jetzt noch eine Frage zum Mitmachen. Also so eine, ich sag mal, bis ich so eine Case Study rund hab, das dauert natürlich eine Weile. Aber ich gehe mal davon aus, dass es völlig okay ist, einfach mal so eine Idee in groben Zügen zu präsentieren und dann, dass man dann über einen längeren Zeitraum mit euch diskutieren kann oder über einen kurzen Zeitraum je nachdem. Ja, also ich kann liefern, zumindestens mal.
Felix Schumacher Ja, also gerne. Wir freuen uns über jede Contribution. Wenn ihr, ich sag mal, mit einem groben Entwurf um die Ecke kommt, im Zweifelsfall, macht einen PR auf, denn notfalls machen wir uns mal einen Call auf und unterhalten uns mal mit euch darüber. Wir werden schon irgendwie was Gutes zusammenkriegen und wie gesagt, wir freuen uns über jede Beteiligung.
Sven Johann: Okay, super. Dann bedanke ich mich bei euch und auch bei den Zuhörern natürlich und würde mal sagen, bis zum nächsten Mal. Tschüss.
Christian Jacobs: Tschüss.
Andreas Voigt: Tschüss.
Felix Schumacher Tschüss!