Immer wieder herrlich. Du wärst der Lieblingslehrer aller Schüler, denn durch die lebendige und anschauliche Erklärung muss man einfach aufmerksam zuhören und kann alles verstehen.
@@FilmfanOliver1992 Nein, bloß nicht. Weil die wenigsten Professoren wirklich wissen wovon sie reden. Sie haben jede Menge Bücher studiert, sie wissen allen möglichen Scheiß auswendig und sind in der Theorie sattelfest, haben aber von der Praxis absolut keinen Dunst. Es mag Ausnahmen geben, die habe ich bisher aber noch nicht erlebt oder von ihnen gehört. Und so ziehen die meisten wieder nur Theoretiker heran ohne jeglichen praktischen Bezug.
@@FilmfanOliver1992 wie ich sagte, es sind nicht alle professoren so. aber ich hatte erwartet das mindenstens einer kommen wird der mir das gegenteil beweisen möchte.
Sehr gutes Video. Ihr seid eine der wenigen deutschsprachigen Formate, die kritisch "alte" Herangehensweisen hinterfragen und auf moderne Prinzipien setzen. Und dabei die Komplexität nicht scheuen! Wenn viel mehr solche Sichtweise verinnerlichen, hätte man als Entwickler/Architekt viel weniger dieser Diskussionen über unverständlichen Code.
Ich kann deine Kritik an der Verwendung von CRUD auf (RESTful) API-Ebene absolut nachvollziehen. CRUD gehört in die Datenbank und nicht in die API oder ins UI. Die API sollte bestimmte Use-Cases (bzw. Geschäftsprozesse) abbilden, damit auch klar ist, was damit eigentlich bezweckt wird. Dann kann man auch je nach Endpoint (bzw. UseCase / Context) erst richtig validieren und zugleich die Datenmenge auf das Nötigste reduzieren. Auch der HTTP-Response kann dann individuell angepasst und vom Client verarbeitet werden. Mit der richtigen Namensgebung für die Endpoints und HTTP-Verben lassen sich zum Glück auch mittels REST(ful) anständige APIs implementieren. Ebenso sollten UI's die Geschäftsprozesse abbilden und NICHT als eine Art "Excel fürs Web" verstanden werden.
Wie immer ein sehr gutes Video. Die Erklärung ist top. Ich hätte mir am Ende noch ein, zwei Beispiele gewünscht, wie / was anstatt eines Grids verwendet / modelliert wrden kann. Bspw. was statt einem CreateOrder zu programmieren wäre.
Du sprichst mir aus der Seele! Es gibt viel zu viele Fachanwendungen, die diese Bezeichnung nicht verdienen, weil sie vom Aufbau her nur ein Datenbank-Frontend sind. Unser Schulverwaltungsprogramm ist so ein Beispiel. Ursprünglich als MS Access-Anwendung konzipiert (suche den Fehler...), inzwischen mit SQL-Server im Hintergrund, aber immer noch verstehen die Anwender die Logik nicht, weil sie die dahinter liegende Datenbank nicht kennen.
Ich glaube das eigentliche Problem ist einfach das einige Entwickler der Meinung sind einfach 1:1 ohne "Zwischenschichten" von Ihrem REST Controller / Endpoint direkt an das SQL gehen. Dabei wird kein Mapping von DTO in DAO vorgenommen. Dabei wird keine Fachlichkeit abgebildet. Einfach eine Art DB-Mapper - was natürlich nichts bringt. Mittlerweile habe ich es mir angewohnt in meiner / unserer Software ein "CRUD Repository" zu erstellen, worüber die Fachlogik liegt - und hier drüber noch die "Access Schicht" (REST, GraphQL, SOAP ...).
Kleine Anmerkung vor dem Lob: "Mindset" ist das CRUD der Coaches, das inflationär für viele Angelegenheiten oder Umstände benutzt wird, sei es Haltung, Geisteshaltung, Herangehensweise, Sicht, Beobachtung, … 😉 Danke dafür, das du das thematisiert hast, denn Code anderer Leute ist dadurch immer so schwer verstehbar. Lesen kann man es, aber im fachlichen Sinne verstehen?
[gr] Vielen Dank für das tolle Feedback 😊 Wenn Du möchtest - schlag es bei TED doch mal vor … wer weiß, was daraus wird: www.ted.com/participate/nominate
Zunächst Danke für das großartige Video, es bringt mich zum Nachdenken. ABER... Ich hätte wirklich gerne ein Praxisbeispiel an dieser Stelle, wäre das möglich? Ich würde gerne den typischen Weg sehen, den die meisten mit CRUD gehen und dann den optimierten Ansatz. Ich glaube es würde vielen Helfen besser zu begreifen, was Sie zu vermitteln versuchen. PS: Der Link für den englischen Blog-Post fehlt in der Beschreibung.
Ich denke man kann nicht pauschal einen Ansatz vorstellen. Da treffen diverse Problem aufeinander. Es geht hier eher darum das Problem ins Bewusstsein zu holen und auf dieses Problem (was ich selbst täglich bei den Reviews erlebe) aufmerksam zu machen. Es geht hier nicht darum "Mach nicht so, mach so". Wenn man z.b. im Code für das Laden einer Liste von Airports einfach einen endpunkt hat der "read" heißt, er sprach hier von "get" dann ist das wenig hilfreich. da wäre in einer Klasse Airport ein "loadList", ein "loadAirports" oder ein "index" (meist in Controllern das synonym für eine "Landingpage") sinnvoll. Es kommt aber, deswegen helfen Beispiele da wenig, immer auch auf die Klasse an, die Parameter, den Rückgabewert und den Rumpf der Funktion. Das zusammen (außer dem Rumpf) ist inkl. dem Namen die Signatur der Funktion. Sie bildet sich eben über mehrere Faktoren. Daher, wie gesagt, gibt es da keine Daumenregel und ich bin dankbar dass hier keine vorgestellt wird. Das problem wäre dann nämlich, dass genau die, die aktuell nur mit "get" oder "set" alle möglichen funktionen prefixen, ab sofort dann meint wegen "load" oder "search" als prefix benutzen. Das wäre vom Regen in die Traufe und würde die nächsten prefixe unsäglich machen. Wichtig ist lediglich, sich des Problems bewusst zu werden und dem entsprechend die Auswahl seiner Funktions-und Klassennamen einfallsreicher zu sein.
Ich wäre schon glücklich, wenn Leute aufhören würden jedes Software Projekt direkt mit einer Datenbank zu starten. Auch wenn die fachlichen Anforderungen noch nicht klar sind, steht es meistens schon fest: "wir brauchen eine Datenbank". Ein Drittel aller Softwareprojekte, die ich gesehen habe, könnten wunderbar ohne Datenbanken auskommen. Stattdessen entscheidet man sich für eine Datenbank -- diese diktiert/limitiert dann die Implementierung und nicht zu vergessen, produziert auch beachtliche Kosten.
Nicht zu vergessen: es muss eine relationale Datenbank sein. Und bevor man nicht ewig und 3 Tage über Schema und Constraints gestritten hat, darf keine Zeile Code geschrieben werden 🤣
Jede Anwendersoftware mit Authentifizierung und Kunden-/Mitarbeiterverwaltung wird wohl nicht ohne DB auskommen, ansonsten bin gerne für die ultimative DB-freie-Lösung offen. Man lernt ja nie aus.
@@schneider.mariane Das eine ist, die fachliche Notwendigkeit einer Datenbank per se in Zweifel zu ziehen- vermutlich gibt es mehr Software mit einer Datenbank als ohne - und das andere ist der Zeitpunkt an welchem eine Datenbank in Erwägung gezogen wird zur Disposition zu stellen. Ich denke es ist durchaus eine Überlegung wert, ob man von Anfang an eine Datenbank mit einbezieht oder wenn es e.g. eine relationale DB sein sollte, sich schon im Vorfeld ein Schema überlegen muss (gut, dass es JSON Datentypen in relationalen DBs gibt ^^). Je nach dem, wie der Kontext des Projektes aussieht, ändern sich die Anforderungen im Laufe der Entwicklung so rasch, dass eine relationale Datenbank in einer frühen Projektphase mehr hindert als nützt. Damit ist nicht gesagt, dass eine relationale Datenbank per se Schwierigkeiten macht, sondern, dass sie nicht in jeder Projektphase das geeignete Werkzeug der Wahl ist, um die konkreten Projektbedürfnisse zu befriedigen. Und ich kenne es aus einigener Erfahrung, dass es manchmal Projekts klüger ist, die Entscheidung zunächst zu vertagen.
Das stimmt absolut, allerdings sehe ich in letzter Zeit sehr viele Projekte bzw. Architekturen die vollständig (und auch manchmal zu intensiv) auf Domain Driven Design setzen und ein ganz eigenes Vokabular für ihre Fachlichkeit entwickeln, bevor die Implementierung beginnt. "Zu intensiv" heißt dass auch zuviel Zeit für die DSL aufgewendet werden kann, bevor Piloten oder MVPs entwickelt werden, da ist die Abwägung der Iterationen wichtig, bzw. darf man die agilen Prozesse dabei nicht vergessen.
Hi Golo, total gut gemacht! Ich finde das ist ein richtig spannender Ansatz! Allerdings bekomme ich es nicht in meine Programmierung transferiert. Angenommen wir programmieren TH-cam, und du lädst ein Video hoch, dann würde ich sicherlich Funktionen und Variablen schreiben, die Wörter enthalten wie: hochladen, Fortschritt, Speicherort, Auflösung ermitteln, Datenrate berechnen,… Okay, das sind jetzt schon Verben und Substantive. Habe ich hiermit die Mission bereits erfüllt? Zielst du nur darauf ab, dass man den Upload mit Create beschreibt? Oder habe ich den Kern der Umsetzung in der Praxis noch nicht begriffen?
Ich denke du hast den Kern nicht begriffen. Es geht um die ständig wiederholende Benamung von Funktionen in meinen Augen. Das ist nämlich tatsächlich ein großes Problem. Viele Entwickler haben ein sehr beschränktes repertoire von prefixen und nutzen die, egal ob es passt im kontext oder nicht. Selbst wenn es halbwegs passt, sagt es nichts groß aus. Dabei kann man das in meinen Augen aber nicht so pauschalisieren. Wenn ich einen Controller habe (das ist eh der einzige ort wo endpunkte bereit gestellt werden sollten) und der Controller z.b. Airport heißt, dann mache ich mit create deutlich dass diese endpunkt für das erstellen eines airports verantwortlich ist. Problematischer ist es, wenn ich z.b. eine funktion habe die einen service instanziert und in dem service dann bussineslogik ausführt. diese dann mit z.b. getService zu benamen macht den code extrem unleserlich. weil get suggeriert dass hier nur ein service zurück gegeben wird. ein member. oft versteckt sich dahinter aber weitaus mehr. Ich bin der Meinung dass der titel hier zu drastisch bzw. zu eingeschränkt gewählt ist, denn das sinnvolle benennen von funktionen und klassen sowie das sinnvolle trennen von zuständigkeiten läßt sich nicht auf einfache CRUD operationen beschränken. Das problem ist täglich und in vielen teams immer wieder vorhanden. Und es ist oft eine sehr ermüdende diskussion diesen entwicklern zu verdeutlichen dass ihre benamung sehr unglücklich ist. das liegt aber auch oft an der eitelkeit des jeweiligen entwicklers.
Bin mir nicht sicher, ob du REST und HATEOAS richtig verstanden hast. Denn leider ist die Aussage Unsinn. Allerdings, was Entwickler aus REST gemacht haben, das istbin 90+% gruselig und beschreibt, was du sagst. Das hat aber eben nichts mit REST von Fielding zu tun.
Ich stimme Dir da weitestgehend zu, möchte aber noch etwas ergänzen. Man muss sich natürlich bei einem HTTP-API Gedanken darüber machen, ob man einen Call mit GET, POST, PUT, PATCH, DELETE usw. umsetzt aber die Anzahl der fachlichen Funktionen ist natürlich wesentlich größer als diese Anzahl von HTTP-Verben. Ich finde, ein schönes Beispiel ist das Buchen eines Fluges. Da kann man für einen gebuchten Flug, den man per findBookedFlight() über einen GET-Request in das UI geladen hat, z.B. mittels modifyAddress() über einen PUT-Request einen Tippfehler in der Adresse korrigieren oder mittels cancelFlight() über einen PUT-Request den Flug stornieren. Und wenn man dann im Richardson-Maturity-Model noch weiter ist, kann man die URLs und HTTP-Verben als Links in das Ergebnis von findBookedFlight() einbauen und schon kann der Anwender einen Flug nur noch stornieren, wenn dieser Link vorhanden ist, die Adresse kann aber dann evtl. weiterhin geändert werden, weil der entsprechende Link enthalten ist. Damit wird klar, dass sich mit HATEOAS und vielen fachlichen Verben über wenige HTTP-Verben ganz unterschiedliche Funktionalitäten sehr verständlich umsetzen lassen.
Ja stimmt, die Fachlichkeit sollte immer führend sein! Jedoch gerade aus der Fachlichkeit wird häufig sinnvollerweise Kernfachlichkeit und Randfachlichkeit unterschieden. Die Implementation von Kernfachlichkeit oder Kerngeschäftsprozesse sollten sehr stringend funktional über APIs gestaltet werden, um notwendige Kontrollen zu gewährleisten und auch keinen Missbrauch Vorschub zu leisten. In Bereichen der Randfachlichkeit stellt sich häufig jedoch eine ganz andere Herausforderung dar, wo häufig "digital payload" bzw. elektronische Dokumente zu bearbeiten sind, die eine sehr hohe Fachkomplexität im Datenschema besitzen (zum Beispiel über 1.000 eDoc Business Message Types aus externer Vorgabe). Die Fachkollegen sind nicht in der Lage in einem realistischen Zeitraum für 1.000 Business Message Types eine schöne fachliche Story zu erzählen, geschweige die Entwickler zu programmieren. Aber auch hier stimme ich dir zu, auch die Story zu Business Messages in einer hohen Komplexität kann man auf einer anderen Sprachebene erzählen, als auf einer zu sehr technischen Ebene. Es ist ggf. nur sehr anspruchsvoll auf einer allgemeinen Zwischenebene eine ansprechende Geschichte erzählen zu wollen, die in meinem Beispiel für alle 1.000 Business Messanges plausibel erscheint, was auch insbesondere die technische Lösung hierzu betrifft. Daher wird aus Vereinfachungsgründen auf CRUD basierende Ansätze bis zur Benutzeroberfläche hin wohl weiter zurückgegriffen.
Der Verleich mit den REST APIs hat mich schwer beeindruckt, es war mir gar nicht bewusst. Wobei ich REST als logische Konsequenz aus den vorherrschenden Datenbanksystemen sehe. Ob schlimm oder nicht, ist fraglich, praktisch in jedem Fall. Die Auswirkung auf (meinen eigenen) Code sehe ich da in jedem Fall, da man Tasks von einer Webseite/Runtime automatisch nach den Fähigkeiten einer API ausrichtet. Schöner Denkansatz im Ganzen, Dankeschön! :-)
Mein Reden seit 20 Jahren. CRUD ist ja nur ein Beispiel für den Hang, zu früh in technische Dimensionen abzutauchen. Es gibt noch unglaublich viele weitere Beispiele, die das Pferd von hinten aufzäumen. Als Anforderungsanalyst kämpfe ich an mehreren Fronten gegen diese Haltung. Einerseits werde ich mit Fachleuten konfrontiert, die sich bereits eine naive Vorstellung ihrer Anforderungen gemacht haben. Allerdings treffe ich dabei zunächst IMMER auf eine unsäglich gefährliche Mischung aus Fachlichkeit und semitechnischem Verständnis. Die Fachleute beschreiben nicht ihr Problem, sondern ihre Vorstellung einer Lösung. Ich muss sie mühsam erst zu ihrem Problem führen, um von da aus eine sachgerechte Analyse des selbigen zu beginnen. Dazu kommen Informatiker-Kollegen, die den Unterschied zwischen einer fachlich und technisch gedachten Anforderung nicht kennen und sich regelrecht wehren, zuerst technologieagnostisch zu denken. Ich bin in die Informatik gegangen, weil mich die Lösung von Problemen im Allgemeinen interessiert - nicht die IT alleine. Informatik ist nur ein Werkzeug von vielen. Weitere sind Psychologie, Organisationswissenschaften, Design, Betriebswirtschaft, Soziologie, Sprachwissenschaften, Philosophie etc. Ich schaue mir also zunächst das Problem an und entwickle daraus eine Lösung, die in den seltensten Fällen alleine mit den Mitteln der Informatik zu lösen ist. Ich hatte schon Fälle, in denen ich Kunden davon abgeraten habe, das Problem mittels Software zu lösen. Für mich ist dieses Denken der Schlüssel der Digitalisierung. Und es erklärt, warum das "Ingenieursland" Deutschland sich so schwer mit "der Digitalisierung" tut. Alleine der Begriff "Requirements Engineer" zeigt das ganze Dilemma - es ist für mich nahezu eine Tautologie mit einer gefährlichen Bestärkung weg vom Problem. Für mich persönlich ist er sogar eine Beleidigung ;)
Indviduelle Commands, die die Fachlichkeit abbilden, können eine Alternative sein. Auch ohne Eventsourcing geht das. Ggf. ist die Datenbank in der Persistenzschicht immer noch CRUD aber die API der Anwendung bietet dann z. B. "Melde Fehler", "Ziehe Anfrage zurück", "Eskaliere Anfrage", "Löse Anfrage", etc... Siehe z. B. Hexagonale Architektur
Ich bin etwas verwirrt. Ich bin völlig bei dir, wenn es darum geht die funktionen entsprechend ordentlich mit einem prefix zu versehen. Ich verbiete bei uns z.b. das inflationäre verwenden von get und set, außer es wird ein member gesetzt oder geholt. sobald dort eine zeile logik in der funktion enthalten ist, lehne ich den merge request ab. was mich aber verwirrt: was hat das falsche benamen von funktionen mit CRUD zu tun? das passiert täglich innerhalb aller möglichen funktionen? ich habe nicht so richtig verstanden warum du das problem auf CRUD minimierst bzw. warum du den Titel des videos so gewählt hast. Das benamen von funktionen ist zum lesen und verstehen des quellcodes in meinen augen essenziell, daher lege ich da sehr viel wert drauf. Auch auf die korrekte benamung von klassen und deren zuständigkeiten. würde mich freuen, wenn du da ein wenig licht in meine verwirrung bringen könntest. nichts desto trotz: vielen dank von herzen für deine / eure beiträge. sie sind oft eine gute erinnerung um dinge wieder ins bewusstsein zu holen und auf der andren seite stellt ihr oft techniken vor die mir so noch nicht geläufig waren, was mir einen enormen mehrwert bietet. danke dafür.
Man könnte einwenden, dass, wenn man die fachlichen Vorgänge mit der technischen "CRUD"-Brille sieht, Gefahr läuft, eine verkürzte Sicht, bzw. eine zu wenig reichhaltige Modellierung zu entwickeln und gegebenenfalls vorhandenes Potenzial für e. g. Analytics brach liegen zu lassen. Zumindest habe ich das Warenkorb-Beispiel so verstanden. Das heißt die "technische Benennung" wird als Indikator für fehlendes fachliches Verständnis hergenommen. Kann man so sehen. Finde ich jetzt aber etwas an den Haaren herbeigezogen. Allerdings sehe ich mit der DDD-Brille auch, dass die Benennung nicht nur zum Verständnis des Codes dient, sondern auch die Fachlichkeit irgendwo widerspiegeln sollte. Allerdings gilt das IMHO nicht für jeden Layer. Im Repo ist "getOrderById" schon okay.
@@ThomasJunkOS Danke für deinen Kommentar. Ich würde gern zu erst deinen letzten Gedanken aufgreifen: Du sagst im Repo wäre "getOrderById" schon ok. Das sehe ich nicht so. Get ist für mich das zurück geben eines einfachen wertes, dem inhalt einer variable. Repos dürfen bei uns nicht mit get oder set geprefixt werden. Im Grunde darf man das nur bei den Funktionen für Member machen, was in der Regel sich ziemlich genau auf Entities beschränkt. In Repos sollten funktionen wie find, fetch oder search genommen werden, weil es genau das ist. In einer Kiste, ich würde das als Beispiel bringen, greift man nur mit viel Glück hinein und bekommt genau das was man sucht, mit der gewünschten Größe, Farbe, Form und Gewicht. Außer natürlich es ist eine Kiste wo alle Elemente gleich sind ;) So sehe ich auch Repos. Sie sind Anbindungen an Datenmengen, daher ist ein get unzureichend. Man muss es an Hand von Parametern suchen, in deinem Beispiel die ID. Ich habe mich mit meinem Team darüber unterhalten, weil mir das unter den Nägeln brannte und hier keine Antwort kam. Die Essenz daraus war, dass es im Grunde gar nicht so um die getter und setter geht, auch nicht um die CRUD benamung, es ist eher das Problem dass die Entities oft direkt an eine Zeile in der Datenbank gebunden sind und da viele Frameworks über diese Entities die Forms erstellen hat man das Problem dass man über die Struktur der Datenbank zum Teil bescheid wissen muss um die Form richtig zu füllen. Es können, wenn man die Technik so einsetzt und das Frontend direkt mit der Datenbank über das ORM im Backend verknüpft keine kundenspezifischen bzw. bedienbaren API gebaut werden, da die Anfragen und Antworten immer 1:1 der Datenbankstruktur entsprechen (müssen). Hier würde ich z.b. für PHP Entwickler Symfony und die Art wie dort die Forms für das Frontend gebaut, populated und validiert werden ins Feld bringen. Oder die API-Platform, die in der aktuellen Version sogar gänzlich ohne Controller und Zwischenschichten auskommt und direkt im Model die Felder definiert, die ans Frontend geliefert werden. Man kann das Verhalten über Dekoratoren beeinflussen, aber am Ende ist es ein Krampf.
Beschränken sich diese DDD-Themen eigentlich immer auf so einfache Fälle, wie das Hinzufügen eines Artikels in einen Warenkorb? Sehe das nämlich etwas differenzierter. Natürlich sollte einem klar sein, welche fachlichen Themen man versucht mit der Software abzubilden. Aber das kann man alles mit einem sauberen REST-API abbilden. Bei REST-APIs übernimmt m.M.n. der CRUD-Teil der Applikation Authorisierung, Validierung, Transformation, etc. Also das Fachliche. Ein DELETE auf eine Artikel-ID im Warenkorb kann auch ein Update in der DB zur Folge haben. Muss ja keine Löschung des DB-Eintrags auslösen. Wenn man sein REST-API direkt in die DB schreiben lässt, kann man auch gleich sowas wie Postgrest oder Supabase verwenden und sich ein eigenes API komplett sparen. Die fachliche Geschichte wird vom GUI erzählt, nicht vom API. Der Endbenutzer sieht i.d.R. keine HTTP-Methoden. Das GUI hat oft die Kontext-Informationen zum aktuellen Benutzer (OS, Plattform, Ort, etc.), die als extra Header-Informationen oder Meta-Informationen im Body (je nach HTTP-Methode) mitgeschickt werden können, um eine Geschichte erzählen bzw. Analysen daraus ziehen zu können. Integratoren des APIs sind dann froh, wenn sie nur die CRUD-Methoden zur Verfügung haben um Daten zwiwchen den Systeme ihres Unternehmens zu synchronisieren. Denen will man doch nicht die ganze Domäne erklären. Sie haben auch keine Zeit jede einzelne zu verinnerlichen.
An sich kann ich die Kritik schon verstehen und ein großer Programmierer unserer Zeit meinte mal, dass sich gut, verständlicher Code wie ein Essay lesen sollte. Aber stellen wir uns mal eine Eventagentur vor, die ihre Veranstaltungen per Web verwaltet. Wenn ein Mitarbeiter mehr Infos über bereits angelegte Veranstaltung einsehen will, würde ich sicherlich im Backend eine Methode implementieren, die "GetEventById ( ) " oder so heißen würde. Nach Gollos Empfehlung sollte die Methode eher "ShowAllEventInformation" heißen. Ich muss ehrlich gestehen, ich würde mich bei Zweiteren eher fragen, was sich macht als bei der "Standardvariante". Aber evtl. ist man nur in der Microsoft Bubble an solchen Standard-Methodennamen gewohnt...
Bei solchen Prinzipien muss man sich klar machen, dass es erstmal nur zum Nachdenken anregen soll, dass man bewusster Entscheidungen treffen soll wobei man Vor- und Nachteile besser abwägen kann als „einfach drauf los“ zu machen. In dem Fall kennt halt jeder das Rest-Pattern, d.h. wenn man einfach drauf los macht kommt vermutlich CRUD in Form von Rest in die API, was in vielen Fällen mehr Nachteile haben kann als Vorteile. Es geht darum diese Entscheidung bewusst für seinen Anwendungsfall zu treffen. Und in deinem Beispiel macht es auf einer bestimmten Ebene vllt auch Sinn eine Methode „getEventById“ zu nennen statt „Show…“ denn zeigt diese Methode dem Nutzer tatsächlich was an (also mehr eine Methode die ich im UI vermuten würde als im Backend) oder holt, also „get“ sie die Information anhand der Id? Das kommt ganz auf den Kontext an. Es könnte aber zum Beispiel bei einer Event Suche Sinn machen, einen Endpunkt im Backend „searchEvent“ zu nennen, damit klarer wird es gibt eine Suche und die hat bestimmte Funktionen wie z.b. Filter oder so, und das zu trennen von z.b. einer kategorischen Auflistung, oder einer Auflistung von Events die eine Person sich zugeordnet hat, weil das vielleicht unterschiedliche fachliche Sachen sein können. Ob das im Projekt Sinn macht oder ob man das am Ende doch über den gleichen „searchEvent“ Endpunkt macht, kommt drauf an. Was man vielleicht vermeiden möchte ist so eine „get“ Methode als eierlegende Wollmilchsau mit 30 optionalen Parametern für alle erdenklichen Fälle. Es geht nicht darum zu sagen, das Prinzip ist in Stein gemeißelt, ist in jedem erdenklichen Fall immer die richtige Lösung, usw., es sind keine Gesetze sondern mehr Wegweiser.
@@MoonShadeStuff Wie du richtig sagst, kommt es immer darauf an und der entscheidende Punkt ist das "Bewusst werden". Je länger ich programmiere, desto mehr und mehr wird mir bewusst, dass es kein "Richtig" und "Falsch" im klassischen Sinne gibt und mich die Programmierung immer öfter an Kunst erinnert xD
Wogeghen das erste eine "Id" und das zweite eine "Info" Sind schon zwei verschieden Dinge "GetId" ist technisch, "ShowEventinformation" schon eher die "View" der Daten
Bin absolut deiner Meinung und ist auch der Grund, warum ich lieber smarte, performante Web Apps mit CodeIgniter entwickle anstatt mit Laravel, wo man so oft dazu animiert wird in CRUD Logik zu denken.
Was ist mit dem klassiker: Ich erstelle ein Produkt oder oder bearbeite ein Produkt. Wie soll man sowas sonst bennenen? Mir fällt da nichts sinnvolleres als CRUD ein :/
[gr] Ich kenne den konkreten Kontext nicht, "Produkt" ist halt sehr allgemein, aber ich versuche mal, ein paar Beispiele zu nennen, wie man es alternativ machen könnte: Angenommen, Du bist ein Verlag, und Deine Produkte sind Bücher, und Deine Software dient dazu, die Bücher zu verwalten, die Du im Sortiment hast. Dann wird ein Buch zum Beispiel "geplant", "veröffentlicht", "redigiert", "umbenannt", … Oder, wenn Du ein Online-Shop bist, dann wird ein Produkt "ins Sortiment aufgenommen", "eingekauft", "gelagert", "verkauft", "verschickt", "retourniert", … Oder, wenn Du ein IT-Beratungsunternehmen bist, dann sind Deine Produkte zum Beispiel verschiedene Workshops. Die werden "angelegt", "geplant", "veröffentlicht", "verschoben", "abgesagt", "durchgeführt", … Und so weiter … Was konkret die Wörter sind, hängt von der jeweiligen Domäne ab, aber niemand aus der Fachabteilung würde sagen, dass ein "Buch created", ein "Artikel created" oder ein "Workshop created" wird. Die Frage ist: Was sagen sie stattdessen?
Für mich klang dein Vortrag danach, dass REST wegen der beschränken Anzahl an Verben falsch für APIs ist, auch wenn du das nicht explizit gesagt hast. Umbenennen müsste bspw. so umgesetzt werden: Put /books/2346 oder Put /books/2346/name Oder Workshops würden so geplant bzw. abgesagt/durchgeführt werden: Post /workshops bzw. Put /workshops/38489/status Die Verwendung von Verben in der URL wird ja bei REST nicht empfohlen. D.h. Folgendes ist aus Gründen nachteilig: Post /workshopAbsagen oder Post /workshops/7554/absagen oder Put /workshops/8654/abgesagt Was ich mir noch vorstellen könnte, wäre Folgendes, auch um die Möglichkeiten für den Aufrufer zu beschränken: Put /workshops/97533/status-abgesagt So lässt man den Aufrufer gar nicht in jedem Workshopzustand alle Zustände als Auswahl. Macht ja bspw. keinen Sinn, den Workshop abzusagen, wenn er bereits durchgeführt wurde. Wie sollten APIs denn deiner Meinung stattdessen umgesetzt werden? Oder geht es dir um die Begriffe auf der GUI?
Das video tut echt weh. Bin seit fast 10 jahren Entwickler und baue fast ausschließlich Excel-artige Oberflächen. Problem ist allerdings dass wir meist bestehende Prozesse "digitalisieren" die auf 15 Jahren Excel basieren. Das heißt eine UI die zu weit weg von Excel ist, ist vom Kunden nicht erwünscht.
"CRUD-Käppchen und der böse Wolf" :D Ich persönlich bin aber noch nicht ganz überzeugt. Vielleicht interpretiere ich CRUD aber auch nur ein bisschen liberaler. DB: CRUD auf DB-Tabellen Models: zusätzlich CRUD auf "virtuellen Ressourcen", die nicht 1:1 so in der DB existieren müssen API: ggf. zusätzliche Routes für manche Ressourcen nach Bedarf UI: so wie es der Kunde haben will Damit ist man schon ziemlich flexibel. Wüsste nicht, was man damit nicht bauen kann.
Grundsätzlich interessanter Punkt, welcher aber den vermtlich wichtigsten Aspekt der IT, nämlich die Abstraktion aussen vor lässt. Das ist eben gerade die Stärke von CRUD: man kann dieses Konzept auf sehr viel Use Cases anwenden. Es eine wichtige Aufgabe von Softare Engineering, zu abstrahieren und damit Unnötiges von Nötigem trennen. Z. B. macht es sehr viel Sinn, Zugriffsrechte eben aufgrund von CRUD zu steuern und nicht aufgrund von iregendwelchen anderen Verben. Das heisst aber nicht, dass man den Enduser damit belästigen muss. Und es gibt noch einen Haufen anderer wichtiger Wortarten, welche eine Geschichte interessant machen, aber in einem Computerprogramm nicht viel Sinn machen (z. B. Adjektive oder Adverben).
Mit deiner Grundidee bin ich einverstanden, Daten-operation nicht als User Funktionen in der Gui zu sehen. Doch die Meisten sehen es anders. Die meisten Unternehmensdoftware sind gute Beispiele, wie man nicht machen muss.
Das ist der Grund, warum es so viel wirklich schlechte Unternehmenssoftware gibt. Vor allem, wenn man sich den Code von so einer Software anschaut, kommt einem meist das blanke Grausen! Und dann wundert man sich auch nicht mehr, warum neue Features und Bug-Fixes nur sehr schleppend implementiert werden...
@@matthiasendler7268 absolut korrekt. Das Problem kennt glaub ich jeder. Nur ist es eine extreme Mühe das denen klar zu machen die ständig nur auf das Geld sehen. Man kann den Zeitgewinn durch Refactoring nicht in Zahlen ausdrücken, gemessen an der verbrannten Zeit durch Bugfixing. Man kann auch die langwierige Einarbeitung in schlechte und undurchsichtige Software nicht in Zahlen ausdrücken. Das ist aber das einzige, was Manager verstehen. Wir haben uns angewöhnt einfach notwendige Dinge zu machen, weil die Verantwortlichkeit bei uns, den Entwicklern liegt. Das Management muss damit leben. Ganz einfach. Nur haben viel zu wenig Team den Schneid sich schützend vor die Software zu stellen und damit den Wert des Unternehmens langfristig im Auge zu haben.
@@AndreasKempe ich kann dich verstehen, jedoch denen klar zu machen - funktioniert nur in der Theorie. In der Praxis ist das jedoch fast immer anders.. Die mit dem Geld bestimmen Rahmenbedingungen, Umfang, Qualität, Zeit und viel mehr. Und sie lassen sich nicht ändern.
@@valeridause Das ist nicht wahr. Wir haben jede Mengen Kunden mit sehr viel Geld. Sie machen mit euch, weil ihr es zulasst, nicht weil sie das Geld haben. Das ist ein völliger Trugschluß den ich ständig als Ausrede höre. Wenn man nicht genug Verantwortung seiner Arbeit gegenüber hat, läßt man sich treiben und schiebt sie immer wieder anderen in die Schuhe um irgendwann das Schiff zu verlassen, weil der Kunde mit der Software zu viel Ping-Pong gespielt hat. Es ist die Verantwortung der Entwickler, die Software zu schützen und best möglich zu betreuen. Nicht die des Kunden. Es lassen sich immer Kompromisse finden. Man muss es nur auch wirklich wollen. Wir haben täglich x Diskussionen darüber mit diversen Kunden. Sie wollen Qualität also müssen sie damit leben. So einfach ist das. Ich kenne genug Projekte die durch so eine schulterzuckende "Ja was soll ich denn machen" Einstellung an die Wand gefahren wurden. Aber leider ist es in immer mehr Opportun die Verantwortungen anderen in die Schuhe zu schieben.
@@AndreasKempe Was für eine schlechte Angewohnheit, Menschen persönlich zu beurteilen, ohne sie zu kennen. "..Wenn man nicht genug Verantwortung seiner Arbeit gegenüber hat.." "..Es ist die Verantwortung der Entwickler, die Software zu schützen und best möglich zu betreuen.." Ich kenne sehr viele Entwickler, die Blut, Geld, Nächte und ihre gesamte Leidenschaft in die Entwicklung stecken. Doch sie können keine Verantwortung für die Software tragen, wenn in Projekten nicht das gemacht wird, was sie vorschlagen, sondern das, was von anderen gewollt wird - und meistens sind es die, die eine Entscheidungs-Kraft haben. Zu beschreiben, wer diese Kraft hat, ist zu komplex. Meistens sind es die mit dem Geld, auch mit Macht. Oder Nähe zu Personen, die dieses haben. Daher ist es link zu glauben, dass Entwickler für die Software verantwortlich ist, wenn z.B. die Architektur-Entscheidungen von einem Möchtegern-Architekt oder einer Firma gemacht werden, der/die keine Ahnung davon haben. Ein Entwickler verantwortet nur das, was ein Entwickler machen kann. Nicht weniger. Aber auch nicht mehr. "...So einfach ist das.." - das ist in der Theorie. In der Wirklichkeit ist es in fast allen Firmen genug an Projekten, die Geld-artig schon eine Mondlandung bezahlt haben, jedoch kein Ende in Sicht ist oder die Qualität so miserabel ist, dass keine oder schlecht Architektur- oder Datenbank-Modell-Beschreibung das ist, ohne Namenskonventionen, ohne Prozess-Dokumentation usw. Doch ich vergesse immer - wir leben doch in einer agilen Welt, wo nach dem Agilem Manifest - ein laufendes Produkt über Dokumentation steht. Doch wenn man ein Ende jemals bekommt, dann hat man weder laufendes Produkt noch eine Dokumentation. Aber der Entwickler muss laut ihrer Aussage verantworten. Super! Nehmen Sie bitte mit, dass Menschen zu beurteilen, ohne sie zu kennen - ein so-la-la Stil ist.
CRUD und REST haben eig nix miteinander zu tun, außer dass viele Leute denken, es wäre dasselbe, weil viele Einsteigerbeispiele es suggerieren. Bei REST geht es in Wirklichkeit darum, die Zustandsbehaftung eines APIs aufzulösen, um den Dienst serverseitig besser skalierbar zu machen. Man nimmt jeglichen Zustand auf Dienst-Level weg und gestaltet die Anfragen entsprechend, dass alle für die Bearbeitung notwendigen Infos immer explizit mitgeschickt werden. Zudem macht man alle von der Ressource aus navigierbaren, verwandten Ressourcen über Hyperlinks in den Antworten verfügbar (kein lästiges Zusammenbauen von URLs im Client). Dadurch dass der komplette Zustand nun vom Client verwaltet wird und explizit in jeder Anfrage steckt, ist es praktisch egal, welche konkrete Dienstinstanz die Anfrage serverseitig abarbeitet. Man kann also den Dienst auf ganz vielen Servern gleichzeitig laufen lassen und ist nicht länger durch die Kapazität einer einzelnen Maschine limitiert. Zudem wird durch die Resource-Links auch clientseitig die Navigation des APIs einfacher, weil man kein Wissen über das Zusammenbauen der URLs benötigt. Das alles hat recht wenig mit CRUD zu tun. Die REST APIs sollen - wie richtig gesagt wurde - die Use Cases der Anwendung widerspiegeln und beschreiben, wie man vom einen Systemzustand in den nächsten kommt. Wenn man es anders macht, ist es halt einfach nicht mehr RESTful, sondern ein x-beliebiger HTTP Server. Mir tut Roy Fielding (Erfinder von REST) wirklich leid, dass ihn die halbe Welt missverstehen will, nur weil die Leute zu faul sind, seine Doktorarbeit zu durchdringen.
Die von dir beklagten Einsteigerbeispiele sind so, weil ReST auf HTTP basiert, und die Hauptverben sind nun mal POST, GET, PUT und DELETE, also CRUD. ReST fügt dem im Wesentlichen zwar die Zustandslosigkeit hinzu, es bleibt aber bei dem Grundprinzip. Wir haben also ganz eingeschränkte Ausdrucksmöglichkeiten, jedenfalls, wenn man die Verben so interpretiert, wie ihre Bezeichnung nahelegt. Der Geburtsfehler ist, wenn man so will, HTTP für alles zu verwenden. Dafür war es nie gedacht, das ist aufgepfropft.
Der Rant ist angebracht, leider ist das oft anzutreffen bei Projekten. Vor Jahren hat nach einem halben Jahr Entwicklungszeit der PO mal ketzerisch das das Projektteam gefragt: "So, jetzt habt ihr mir also ein Frontend für die Datenbank geschrieben. Aber das ist doch absolut Commodity. Kann man das nicht auch automatisch generieren lassen?". Und die Kritik war richtig. Und dann wird vorne dran noch eine UI gebaut, die aussieht wie eine Excel-Tabelle.
Da trägt doch der PO die primäre Verantwortung wenn er das ein halbes Jahr so entwickeln lässt. Wer, wenn nicht er koordiniert requirements und regelmäßige abnahmen für das Frontend?
Gute Software erzählt eine Geschichte in einer Programmiersprache und daraus sollte sich für jeden, der dieser Sprache mächtig ist, die Fachlichkeit herauslesen lassen können und zu einem Domänenexperten machen. Eine gut modellierte Domäne sollte nur sehr wenige, im Idealfall keinerlei externe Abhängigkeiten haben. Leider ist das in der Realität oft nicht der Fall und die Systeme sind dann überkomplex, weil man z.B. in einer Update-Funktion alle fachlichen Fälle berücksichtigen muß. Das führt zu riesig großen Funktionen, die kaum mehr durchschaubar sind. CRUD hat seine Berechtigung und gehört in den Data Access Layer, aber um Gotteswillen nicht in eine fachliche Domäne. Geht es in einer Software nur darum Daten ohne große Fachlogik zu erfassen, zu verwalten und/oder sichtbar zu machen, dann kann es sinnvoll sein das komplette System mit CRUD aufbauen. In diesem Fall sollte man allerdings die Grenzen kennen. Edit: Damn Typos! :P
Ich dachte zunächst das ich das Thema verstanden habe. Zum Schluss hätte ich mir doch schon etwas Code gewünscht um das ganze Bildhaft auch darzustellen. Bei der Geschichte mit dem Shop und Warenkorb habe ich nämlich eher an Logging als Lösung gedacht. Ich setze gern CRUD ein, aber mein Entwicklungsstil hat sich momentan dahin geändert das ich das Fachliche in Domänen übertrage. So sehe ich in meinen Geschichten immer einen Sinn.
Die Gegenüberstellung Substantive vs. Verben ist meiner Meinung nicht zielführend. Noch weniger die Abstufungen von Substantiven. Wenn man Prinzessin mit ein Schaff austauschen wird, dann wird die Heirat eines Prinzen mit einem Schaff alles andere als erfreuliches Erreignis im Königshaus. Sorry, aber zu sehr abstrakt, obwohl als Idee für die Erklärung eine sehr gute Wahl.
![โรงเรียนห้ามรัก โดนจับได้ตาย...!! [เอิร์นไดเม่]](http://i.ytimg.com/vi/4u02Sbr556Q/mqdefault.jpg)
Immer wieder herrlich. Du wärst der Lieblingslehrer aller Schüler, denn durch die lebendige und anschauliche Erklärung muss man einfach aufmerksam zuhören und kann alles verstehen.
oder auch ein Prof. ;-)
@@FilmfanOliver1992 Nein, bloß nicht. Weil die wenigsten Professoren wirklich wissen wovon sie reden. Sie haben jede Menge Bücher studiert, sie wissen allen möglichen Scheiß auswendig und sind in der Theorie sattelfest, haben aber von der Praxis absolut keinen Dunst. Es mag Ausnahmen geben, die habe ich bisher aber noch nicht erlebt oder von ihnen gehört. Und so ziehen die meisten wieder nur Theoretiker heran ohne jeglichen praktischen Bezug.
@@AndreasKempe Naja es kommt darauf an an einer HTW Findet man auch mal einen Praktiker ;-)
@@FilmfanOliver1992 wie ich sagte, es sind nicht alle professoren so. aber ich hatte erwartet das mindenstens einer kommen wird der mir das gegenteil beweisen möchte.
Sehr gutes Video. Ihr seid eine der wenigen deutschsprachigen Formate, die kritisch "alte" Herangehensweisen hinterfragen und auf moderne Prinzipien setzen. Und dabei die Komplexität nicht scheuen!
Wenn viel mehr solche Sichtweise verinnerlichen, hätte man als Entwickler/Architekt viel weniger dieser Diskussionen über unverständlichen Code.
Ich kann deine Kritik an der Verwendung von CRUD auf (RESTful) API-Ebene absolut nachvollziehen. CRUD gehört in die Datenbank und nicht in die API oder ins UI. Die API sollte bestimmte Use-Cases (bzw. Geschäftsprozesse) abbilden, damit auch klar ist, was damit eigentlich bezweckt wird. Dann kann man auch je nach Endpoint (bzw. UseCase / Context) erst richtig validieren und zugleich die Datenmenge auf das Nötigste reduzieren. Auch der HTTP-Response kann dann individuell angepasst und vom Client verarbeitet werden. Mit der richtigen Namensgebung für die Endpoints und HTTP-Verben lassen sich zum Glück auch mittels REST(ful) anständige APIs implementieren.
Ebenso sollten UI's die Geschäftsprozesse abbilden und NICHT als eine Art "Excel fürs Web" verstanden werden.
Endlich habe ich als Anwender und Gelegenheits-Entwickler ein Wort dafür, wie und warum die meiste Firmensoftware so grässlich ist ❤
Wie immer ein sehr gutes Video. Die Erklärung ist top. Ich hätte mir am Ende noch ein, zwei Beispiele gewünscht, wie / was anstatt eines Grids verwendet / modelliert wrden kann. Bspw. was statt einem CreateOrder zu programmieren wäre.
Du sprichst mir aus der Seele! Es gibt viel zu viele Fachanwendungen, die diese Bezeichnung nicht verdienen, weil sie vom Aufbau her nur ein Datenbank-Frontend sind. Unser Schulverwaltungsprogramm ist so ein Beispiel. Ursprünglich als MS Access-Anwendung konzipiert (suche den Fehler...), inzwischen mit SQL-Server im Hintergrund, aber immer noch verstehen die Anwender die Logik nicht, weil sie die dahinter liegende Datenbank nicht kennen.
Ich glaube das eigentliche Problem ist einfach das einige Entwickler der Meinung sind einfach 1:1 ohne "Zwischenschichten" von Ihrem REST Controller / Endpoint direkt an das SQL gehen.
Dabei wird kein Mapping von DTO in DAO vorgenommen. Dabei wird keine Fachlichkeit abgebildet. Einfach eine Art DB-Mapper - was natürlich nichts bringt.
Mittlerweile habe ich es mir angewohnt in meiner / unserer Software ein "CRUD Repository" zu erstellen, worüber die Fachlogik liegt - und hier drüber noch die "Access Schicht" (REST, GraphQL, SOAP ...).
Kleine Anmerkung vor dem Lob: "Mindset" ist das CRUD der Coaches, das inflationär für viele Angelegenheiten oder Umstände benutzt wird, sei es Haltung, Geisteshaltung, Herangehensweise, Sicht, Beobachtung, … 😉
Danke dafür, das du das thematisiert hast, denn Code anderer Leute ist dadurch immer so schwer verstehbar. Lesen kann man es, aber im fachlichen Sinne verstehen?
Geisteskrank guter Talk! Das könnte man echt mal auf TED bringen. Werde mein Wording in Zukunft überdenken.
[gr] Vielen Dank für das tolle Feedback 😊
Wenn Du möchtest - schlag es bei TED doch mal vor … wer weiß, was daraus wird: www.ted.com/participate/nominate
Zunächst Danke für das großartige Video, es bringt mich zum Nachdenken. ABER...
Ich hätte wirklich gerne ein Praxisbeispiel an dieser Stelle, wäre das möglich? Ich würde gerne den typischen Weg sehen, den die meisten mit CRUD gehen und dann den optimierten Ansatz.
Ich glaube es würde vielen Helfen besser zu begreifen, was Sie zu vermitteln versuchen.
PS: Der Link für den englischen Blog-Post fehlt in der Beschreibung.
Ich denke man kann nicht pauschal einen Ansatz vorstellen. Da treffen diverse Problem aufeinander. Es geht hier eher darum das Problem ins Bewusstsein zu holen und auf dieses Problem (was ich selbst täglich bei den Reviews erlebe) aufmerksam zu machen. Es geht hier nicht darum "Mach nicht so, mach so". Wenn man z.b. im Code für das Laden einer Liste von Airports einfach einen endpunkt hat der "read" heißt, er sprach hier von "get" dann ist das wenig hilfreich. da wäre in einer Klasse Airport ein "loadList", ein "loadAirports" oder ein "index" (meist in Controllern das synonym für eine "Landingpage") sinnvoll. Es kommt aber, deswegen helfen Beispiele da wenig, immer auch auf die Klasse an, die Parameter, den Rückgabewert und den Rumpf der Funktion. Das zusammen (außer dem Rumpf) ist inkl. dem Namen die Signatur der Funktion. Sie bildet sich eben über mehrere Faktoren. Daher, wie gesagt, gibt es da keine Daumenregel und ich bin dankbar dass hier keine vorgestellt wird. Das problem wäre dann nämlich, dass genau die, die aktuell nur mit "get" oder "set" alle möglichen funktionen prefixen, ab sofort dann meint wegen "load" oder "search" als prefix benutzen. Das wäre vom Regen in die Traufe und würde die nächsten prefixe unsäglich machen.
Wichtig ist lediglich, sich des Problems bewusst zu werden und dem entsprechend die Auswahl seiner Funktions-und Klassennamen einfallsreicher zu sein.
Ich wäre schon glücklich, wenn Leute aufhören würden jedes Software Projekt direkt mit einer Datenbank zu starten. Auch wenn die fachlichen Anforderungen noch nicht klar sind, steht es meistens schon fest: "wir brauchen eine Datenbank". Ein Drittel aller Softwareprojekte, die ich gesehen habe, könnten wunderbar ohne Datenbanken auskommen. Stattdessen entscheidet man sich für eine Datenbank -- diese diktiert/limitiert dann die Implementierung und nicht zu vergessen, produziert auch beachtliche Kosten.
Nicht zu vergessen: es muss eine relationale Datenbank sein. Und bevor man nicht ewig und 3 Tage über Schema und Constraints gestritten hat, darf keine Zeile Code geschrieben werden 🤣
Jede Anwendersoftware mit Authentifizierung und Kunden-/Mitarbeiterverwaltung wird wohl nicht ohne DB auskommen, ansonsten bin gerne für die ultimative DB-freie-Lösung offen. Man lernt ja nie aus.
@@schneider.mariane Das eine ist, die fachliche Notwendigkeit einer Datenbank per se in Zweifel zu ziehen- vermutlich gibt es mehr Software mit einer Datenbank als ohne - und das andere ist der Zeitpunkt an welchem eine Datenbank in Erwägung gezogen wird zur Disposition zu stellen. Ich denke es ist durchaus eine Überlegung wert, ob man von Anfang an eine Datenbank mit einbezieht oder wenn es e.g. eine relationale DB sein sollte, sich schon im Vorfeld ein Schema überlegen muss (gut, dass es JSON Datentypen in relationalen DBs gibt ^^). Je nach dem, wie der Kontext des Projektes aussieht, ändern sich die Anforderungen im Laufe der Entwicklung so rasch, dass eine relationale Datenbank in einer frühen Projektphase mehr hindert als nützt. Damit ist nicht gesagt, dass eine relationale Datenbank per se Schwierigkeiten macht, sondern, dass sie nicht in jeder Projektphase das geeignete Werkzeug der Wahl ist, um die konkreten Projektbedürfnisse zu befriedigen. Und ich kenne es aus einigener Erfahrung, dass es manchmal Projekts klüger ist, die Entscheidung zunächst zu vertagen.
Das stimmt absolut, allerdings sehe ich in letzter Zeit sehr viele Projekte bzw. Architekturen die vollständig (und auch manchmal zu intensiv) auf Domain Driven Design setzen und ein ganz eigenes Vokabular für ihre Fachlichkeit entwickeln, bevor die Implementierung beginnt. "Zu intensiv" heißt dass auch zuviel Zeit für die DSL aufgewendet werden kann, bevor Piloten oder MVPs entwickelt werden, da ist die Abwägung der Iterationen wichtig, bzw. darf man die agilen Prozesse dabei nicht vergessen.
Hi Golo, total gut gemacht! Ich finde das ist ein richtig spannender Ansatz!
Allerdings bekomme ich es nicht in meine Programmierung transferiert. Angenommen wir programmieren TH-cam, und du lädst ein Video hoch, dann würde ich sicherlich Funktionen und Variablen schreiben, die Wörter enthalten wie: hochladen, Fortschritt, Speicherort, Auflösung ermitteln, Datenrate berechnen,…
Okay, das sind jetzt schon Verben und Substantive. Habe ich hiermit die Mission bereits erfüllt? Zielst du nur darauf ab, dass man den Upload mit Create beschreibt? Oder habe ich den Kern der Umsetzung in der Praxis noch nicht begriffen?
Ich denke du hast den Kern nicht begriffen. Es geht um die ständig wiederholende Benamung von Funktionen in meinen Augen. Das ist nämlich tatsächlich ein großes Problem. Viele Entwickler haben ein sehr beschränktes repertoire von prefixen und nutzen die, egal ob es passt im kontext oder nicht. Selbst wenn es halbwegs passt, sagt es nichts groß aus. Dabei kann man das in meinen Augen aber nicht so pauschalisieren. Wenn ich einen Controller habe (das ist eh der einzige ort wo endpunkte bereit gestellt werden sollten) und der Controller z.b. Airport heißt, dann mache ich mit create deutlich dass diese endpunkt für das erstellen eines airports verantwortlich ist. Problematischer ist es, wenn ich z.b. eine funktion habe die einen service instanziert und in dem service dann bussineslogik ausführt. diese dann mit z.b. getService zu benamen macht den code extrem unleserlich. weil get suggeriert dass hier nur ein service zurück gegeben wird. ein member. oft versteckt sich dahinter aber weitaus mehr.
Ich bin der Meinung dass der titel hier zu drastisch bzw. zu eingeschränkt gewählt ist, denn das sinnvolle benennen von funktionen und klassen sowie das sinnvolle trennen von zuständigkeiten läßt sich nicht auf einfache CRUD operationen beschränken. Das problem ist täglich und in vielen teams immer wieder vorhanden. Und es ist oft eine sehr ermüdende diskussion diesen entwicklern zu verdeutlichen dass ihre benamung sehr unglücklich ist. das liegt aber auch oft an der eitelkeit des jeweiligen entwicklers.
Das Märchen von CRUD werde ich irgendwann mal meinen Kindern erzählen.
Die Brüder Grimm können einpacken 😂
Die Brüder Grimm können deleted werden?
@@christianbaer2897 Updated
Bin mir nicht sicher, ob du REST und HATEOAS richtig verstanden hast. Denn leider ist die Aussage Unsinn. Allerdings, was Entwickler aus REST gemacht haben, das istbin 90+% gruselig und beschreibt, was du sagst. Das hat aber eben nichts mit REST von Fielding zu tun.
Super Beispiel mit dem Märchen. Ich mag es trotzdem.
Danke schön 😊
Alle waren froh? Haben nicht alle ihren Status auf "froh" geupdated? :-P
[gr] Haha 🤣
Ich stimme Dir da weitestgehend zu, möchte aber noch etwas ergänzen. Man muss sich natürlich bei einem HTTP-API Gedanken darüber machen, ob man einen Call mit GET, POST, PUT, PATCH, DELETE usw. umsetzt aber die Anzahl der fachlichen Funktionen ist natürlich wesentlich größer als diese Anzahl von HTTP-Verben. Ich finde, ein schönes Beispiel ist das Buchen eines Fluges. Da kann man für einen gebuchten Flug, den man per findBookedFlight() über einen GET-Request in das UI geladen hat, z.B. mittels modifyAddress() über einen PUT-Request einen Tippfehler in der Adresse korrigieren oder mittels cancelFlight() über einen PUT-Request den Flug stornieren. Und wenn man dann im Richardson-Maturity-Model noch weiter ist, kann man die URLs und HTTP-Verben als Links in das Ergebnis von findBookedFlight() einbauen und schon kann der Anwender einen Flug nur noch stornieren, wenn dieser Link vorhanden ist, die Adresse kann aber dann evtl. weiterhin geändert werden, weil der entsprechende Link enthalten ist. Damit wird klar, dass sich mit HATEOAS und vielen fachlichen Verben über wenige HTTP-Verben ganz unterschiedliche Funktionalitäten sehr verständlich umsetzen lassen.
geil, bester maerchen erzaehler!!
Ja stimmt, die Fachlichkeit sollte immer führend sein! Jedoch gerade aus der Fachlichkeit wird häufig sinnvollerweise Kernfachlichkeit und Randfachlichkeit unterschieden. Die Implementation von Kernfachlichkeit oder Kerngeschäftsprozesse sollten sehr stringend funktional über APIs gestaltet werden, um notwendige Kontrollen zu gewährleisten und auch keinen Missbrauch Vorschub zu leisten. In Bereichen der Randfachlichkeit stellt sich häufig jedoch eine ganz andere Herausforderung dar, wo häufig "digital payload" bzw. elektronische Dokumente zu bearbeiten sind, die eine sehr hohe Fachkomplexität im Datenschema besitzen (zum Beispiel über 1.000 eDoc Business Message Types aus externer Vorgabe). Die Fachkollegen sind nicht in der Lage in einem realistischen Zeitraum für 1.000 Business Message Types eine schöne fachliche Story zu erzählen, geschweige die Entwickler zu programmieren. Aber auch hier stimme ich dir zu, auch die Story zu Business Messages in einer hohen Komplexität kann man auf einer anderen Sprachebene erzählen, als auf einer zu sehr technischen Ebene. Es ist ggf. nur sehr anspruchsvoll auf einer allgemeinen Zwischenebene eine ansprechende Geschichte erzählen zu wollen, die in meinem Beispiel für alle 1.000 Business Messanges plausibel erscheint, was auch insbesondere die technische Lösung hierzu betrifft. Daher wird aus Vereinfachungsgründen auf CRUD basierende Ansätze bis zur Benutzeroberfläche hin wohl weiter zurückgegriffen.
Der Verleich mit den REST APIs hat mich schwer beeindruckt, es war mir gar nicht bewusst. Wobei ich REST als logische Konsequenz aus den vorherrschenden Datenbanksystemen sehe. Ob schlimm oder nicht, ist fraglich, praktisch in jedem Fall.
Die Auswirkung auf (meinen eigenen) Code sehe ich da in jedem Fall, da man Tasks von einer Webseite/Runtime automatisch nach den Fähigkeiten einer API ausrichtet.
Schöner Denkansatz im Ganzen, Dankeschön! :-)
"Was hat sie/er sich dabei gedacht, als dieser Code geschrieben wurde?"
GAR NIX!
(ganz häufig)
Mein Reden seit 20 Jahren. CRUD ist ja nur ein Beispiel für den Hang, zu früh in technische Dimensionen abzutauchen. Es gibt noch unglaublich viele weitere Beispiele, die das Pferd von hinten aufzäumen.
Als Anforderungsanalyst kämpfe ich an mehreren Fronten gegen diese Haltung.
Einerseits werde ich mit Fachleuten konfrontiert, die sich bereits eine naive Vorstellung ihrer Anforderungen gemacht haben. Allerdings treffe ich dabei zunächst IMMER auf eine unsäglich gefährliche Mischung aus Fachlichkeit und semitechnischem Verständnis. Die Fachleute beschreiben nicht ihr Problem, sondern ihre Vorstellung einer Lösung. Ich muss sie mühsam erst zu ihrem Problem führen, um von da aus eine sachgerechte Analyse des selbigen zu beginnen.
Dazu kommen Informatiker-Kollegen, die den Unterschied zwischen einer fachlich und technisch gedachten Anforderung nicht kennen und sich regelrecht wehren, zuerst technologieagnostisch zu denken.
Ich bin in die Informatik gegangen, weil mich die Lösung von Problemen im Allgemeinen interessiert - nicht die IT alleine. Informatik ist nur ein Werkzeug von vielen. Weitere sind Psychologie, Organisationswissenschaften, Design, Betriebswirtschaft, Soziologie, Sprachwissenschaften, Philosophie etc.
Ich schaue mir also zunächst das Problem an und entwickle daraus eine Lösung, die in den seltensten Fällen alleine mit den Mitteln der Informatik zu lösen ist. Ich hatte schon Fälle, in denen ich Kunden davon abgeraten habe, das Problem mittels Software zu lösen.
Für mich ist dieses Denken der Schlüssel der Digitalisierung. Und es erklärt, warum das "Ingenieursland" Deutschland sich so schwer mit "der Digitalisierung" tut.
Alleine der Begriff "Requirements Engineer" zeigt das ganze Dilemma - es ist für mich nahezu eine Tautologie mit einer gefährlichen Bestärkung weg vom Problem.
Für mich persönlich ist er sogar eine Beleidigung ;)
Sehr Interessante Gedanken.
Ich stelle mir die Frage was ist die Alternative? Evtl. Eventsourcing?
.. da gibt es sogar ne Folge zu :-)
Indviduelle Commands, die die Fachlichkeit abbilden, können eine Alternative sein. Auch ohne Eventsourcing geht das. Ggf. ist die Datenbank in der Persistenzschicht immer noch CRUD aber die API der Anwendung bietet dann z. B. "Melde Fehler", "Ziehe Anfrage zurück", "Eskaliere Anfrage", "Löse Anfrage", etc...
Siehe z. B. Hexagonale Architektur
@@nitrovent danke, werde ich machen
Die Argumentation geht stark in Richtung Domain-Driven Design
Eventsourcing hat auch seine Härten, z.B. Revisionssicherheit, welcher Datenstand war zum gegebenen Zeitpunkt gültig usw.
Ich bin etwas verwirrt. Ich bin völlig bei dir, wenn es darum geht die funktionen entsprechend ordentlich mit einem prefix zu versehen. Ich verbiete bei uns z.b. das inflationäre verwenden von get und set, außer es wird ein member gesetzt oder geholt. sobald dort eine zeile logik in der funktion enthalten ist, lehne ich den merge request ab.
was mich aber verwirrt: was hat das falsche benamen von funktionen mit CRUD zu tun? das passiert täglich innerhalb aller möglichen funktionen? ich habe nicht so richtig verstanden warum du das problem auf CRUD minimierst bzw. warum du den Titel des videos so gewählt hast. Das benamen von funktionen ist zum lesen und verstehen des quellcodes in meinen augen essenziell, daher lege ich da sehr viel wert drauf. Auch auf die korrekte benamung von klassen und deren zuständigkeiten.
würde mich freuen, wenn du da ein wenig licht in meine verwirrung bringen könntest.
nichts desto trotz: vielen dank von herzen für deine / eure beiträge. sie sind oft eine gute erinnerung um dinge wieder ins bewusstsein zu holen und auf der andren seite stellt ihr oft techniken vor die mir so noch nicht geläufig waren, was mir einen enormen mehrwert bietet. danke dafür.
Man könnte einwenden, dass, wenn man die fachlichen Vorgänge mit der technischen "CRUD"-Brille sieht, Gefahr läuft, eine verkürzte Sicht, bzw. eine zu wenig reichhaltige Modellierung zu entwickeln und gegebenenfalls vorhandenes Potenzial für e. g. Analytics brach liegen zu lassen. Zumindest habe ich das Warenkorb-Beispiel so verstanden. Das heißt die "technische Benennung" wird als Indikator für fehlendes fachliches Verständnis hergenommen. Kann man so sehen. Finde ich jetzt aber etwas an den Haaren herbeigezogen. Allerdings sehe ich mit der DDD-Brille auch, dass die Benennung nicht nur zum Verständnis des Codes dient, sondern auch die Fachlichkeit irgendwo widerspiegeln sollte. Allerdings gilt das IMHO nicht für jeden Layer. Im Repo ist "getOrderById" schon okay.
@@ThomasJunkOS Danke für deinen Kommentar. Ich würde gern zu erst deinen letzten Gedanken aufgreifen:
Du sagst im Repo wäre "getOrderById" schon ok. Das sehe ich nicht so. Get ist für mich das zurück geben eines einfachen wertes, dem inhalt einer variable. Repos dürfen bei uns nicht mit get oder set geprefixt werden. Im Grunde darf man das nur bei den Funktionen für Member machen, was in der Regel sich ziemlich genau auf Entities beschränkt. In Repos sollten funktionen wie find, fetch oder search genommen werden, weil es genau das ist. In einer Kiste, ich würde das als Beispiel bringen, greift man nur mit viel Glück hinein und bekommt genau das was man sucht, mit der gewünschten Größe, Farbe, Form und Gewicht. Außer natürlich es ist eine Kiste wo alle Elemente gleich sind ;) So sehe ich auch Repos. Sie sind Anbindungen an Datenmengen, daher ist ein get unzureichend. Man muss es an Hand von Parametern suchen, in deinem Beispiel die ID.
Ich habe mich mit meinem Team darüber unterhalten, weil mir das unter den Nägeln brannte und hier keine Antwort kam. Die Essenz daraus war, dass es im Grunde gar nicht so um die getter und setter geht, auch nicht um die CRUD benamung, es ist eher das Problem dass die Entities oft direkt an eine Zeile in der Datenbank gebunden sind und da viele Frameworks über diese Entities die Forms erstellen hat man das Problem dass man über die Struktur der Datenbank zum Teil bescheid wissen muss um die Form richtig zu füllen. Es können, wenn man die Technik so einsetzt und das Frontend direkt mit der Datenbank über das ORM im Backend verknüpft keine kundenspezifischen bzw. bedienbaren API gebaut werden, da die Anfragen und Antworten immer 1:1 der Datenbankstruktur entsprechen (müssen).
Hier würde ich z.b. für PHP Entwickler Symfony und die Art wie dort die Forms für das Frontend gebaut, populated und validiert werden ins Feld bringen. Oder die API-Platform, die in der aktuellen Version sogar gänzlich ohne Controller und Zwischenschichten auskommt und direkt im Model die Felder definiert, die ans Frontend geliefert werden. Man kann das Verhalten über Dekoratoren beeinflussen, aber am Ende ist es ein Krampf.
Beschränken sich diese DDD-Themen eigentlich immer auf so einfache Fälle, wie das Hinzufügen eines Artikels in einen Warenkorb? Sehe das nämlich etwas differenzierter. Natürlich sollte einem klar sein, welche fachlichen Themen man versucht mit der Software abzubilden. Aber das kann man alles mit einem sauberen REST-API abbilden.
Bei REST-APIs übernimmt m.M.n. der CRUD-Teil der Applikation Authorisierung, Validierung, Transformation, etc. Also das Fachliche. Ein DELETE auf eine Artikel-ID im Warenkorb kann auch ein Update in der DB zur Folge haben. Muss ja keine Löschung des DB-Eintrags auslösen. Wenn man sein REST-API direkt in die DB schreiben lässt, kann man auch gleich sowas wie Postgrest oder Supabase verwenden und sich ein eigenes API komplett sparen.
Die fachliche Geschichte wird vom GUI erzählt, nicht vom API. Der Endbenutzer sieht i.d.R. keine HTTP-Methoden. Das GUI hat oft die Kontext-Informationen zum aktuellen Benutzer (OS, Plattform, Ort, etc.), die als extra Header-Informationen oder Meta-Informationen im Body (je nach HTTP-Methode) mitgeschickt werden können, um eine Geschichte erzählen bzw. Analysen daraus ziehen zu können.
Integratoren des APIs sind dann froh, wenn sie nur die CRUD-Methoden zur Verfügung haben um Daten zwiwchen den Systeme ihres Unternehmens zu synchronisieren. Denen will man doch nicht die ganze Domäne erklären. Sie haben auch keine Zeit jede einzelne zu verinnerlichen.
Wieso erinnert mich das Märchen an Julien Bams Interpretation von Rotkäppchen 🤣
[gr] Das weiß ich nicht, aber … Bruder muss los 🤪
An sich kann ich die Kritik schon verstehen und ein großer Programmierer unserer Zeit meinte mal, dass sich gut, verständlicher Code wie ein Essay lesen sollte. Aber stellen wir uns mal eine Eventagentur vor, die ihre Veranstaltungen per Web verwaltet. Wenn ein Mitarbeiter mehr Infos über bereits angelegte Veranstaltung einsehen will, würde ich sicherlich im Backend eine Methode implementieren, die "GetEventById ( ) " oder so heißen würde. Nach Gollos Empfehlung sollte die Methode eher "ShowAllEventInformation" heißen. Ich muss ehrlich gestehen, ich würde mich bei Zweiteren eher fragen, was sich macht als bei der "Standardvariante". Aber evtl. ist man nur in der Microsoft Bubble an solchen Standard-Methodennamen gewohnt...
Bei solchen Prinzipien muss man sich klar machen, dass es erstmal nur zum Nachdenken anregen soll, dass man bewusster Entscheidungen treffen soll wobei man Vor- und Nachteile besser abwägen kann als „einfach drauf los“ zu machen.
In dem Fall kennt halt jeder das Rest-Pattern, d.h. wenn man einfach drauf los macht kommt vermutlich CRUD in Form von Rest in die API, was in vielen Fällen mehr Nachteile haben kann als Vorteile. Es geht darum diese Entscheidung bewusst für seinen Anwendungsfall zu treffen.
Und in deinem Beispiel macht es auf einer bestimmten Ebene vllt auch Sinn eine Methode „getEventById“ zu nennen statt „Show…“ denn zeigt diese Methode dem Nutzer tatsächlich was an (also mehr eine Methode die ich im UI vermuten würde als im Backend) oder holt, also „get“ sie die Information anhand der Id? Das kommt ganz auf den Kontext an.
Es könnte aber zum Beispiel bei einer Event Suche Sinn machen, einen Endpunkt im Backend „searchEvent“ zu nennen, damit klarer wird es gibt eine Suche und die hat bestimmte Funktionen wie z.b. Filter oder so, und das zu trennen von z.b. einer kategorischen Auflistung, oder einer Auflistung von Events die eine Person sich zugeordnet hat, weil das vielleicht unterschiedliche fachliche Sachen sein können. Ob das im Projekt Sinn macht oder ob man das am Ende doch über den gleichen „searchEvent“ Endpunkt macht, kommt drauf an. Was man vielleicht vermeiden möchte ist so eine „get“ Methode als eierlegende Wollmilchsau mit 30 optionalen Parametern für alle erdenklichen Fälle.
Es geht nicht darum zu sagen, das Prinzip ist in Stein gemeißelt, ist in jedem erdenklichen Fall immer die richtige Lösung, usw., es sind keine Gesetze sondern mehr Wegweiser.
@@MoonShadeStuff Wie du richtig sagst, kommt es immer darauf an und der entscheidende Punkt ist das "Bewusst werden". Je länger ich programmiere, desto mehr und mehr wird mir bewusst, dass es kein "Richtig" und "Falsch" im klassischen Sinne gibt und mich die Programmierung immer öfter an Kunst erinnert xD
Wogeghen das erste eine "Id" und das zweite eine "Info" Sind schon zwei verschieden Dinge "GetId" ist technisch, "ShowEventinformation" schon eher die "View" der Daten
Bin absolut deiner Meinung und ist auch der Grund, warum ich lieber smarte, performante Web Apps mit CodeIgniter entwickle anstatt mit Laravel, wo man so oft dazu animiert wird in CRUD Logik zu denken.
Was ist mit dem klassiker: Ich erstelle ein Produkt oder oder bearbeite ein Produkt. Wie soll man sowas sonst bennenen? Mir fällt da nichts sinnvolleres als CRUD ein :/
[gr] Ich kenne den konkreten Kontext nicht, "Produkt" ist halt sehr allgemein, aber ich versuche mal, ein paar Beispiele zu nennen, wie man es alternativ machen könnte:
Angenommen, Du bist ein Verlag, und Deine Produkte sind Bücher, und Deine Software dient dazu, die Bücher zu verwalten, die Du im Sortiment hast. Dann wird ein Buch zum Beispiel "geplant", "veröffentlicht", "redigiert", "umbenannt", …
Oder, wenn Du ein Online-Shop bist, dann wird ein Produkt "ins Sortiment aufgenommen", "eingekauft", "gelagert", "verkauft", "verschickt", "retourniert", …
Oder, wenn Du ein IT-Beratungsunternehmen bist, dann sind Deine Produkte zum Beispiel verschiedene Workshops. Die werden "angelegt", "geplant", "veröffentlicht", "verschoben", "abgesagt", "durchgeführt", …
Und so weiter …
Was konkret die Wörter sind, hängt von der jeweiligen Domäne ab, aber niemand aus der Fachabteilung würde sagen, dass ein "Buch created", ein "Artikel created" oder ein "Workshop created" wird. Die Frage ist: Was sagen sie stattdessen?
Für mich klang dein Vortrag danach, dass REST wegen der beschränken Anzahl an Verben falsch für APIs ist, auch wenn du das nicht explizit gesagt hast.
Umbenennen müsste bspw. so umgesetzt werden:
Put /books/2346 oder Put /books/2346/name
Oder Workshops würden so geplant bzw. abgesagt/durchgeführt werden:
Post /workshops bzw. Put /workshops/38489/status
Die Verwendung von Verben in der URL wird ja bei REST nicht empfohlen. D.h. Folgendes ist aus Gründen nachteilig:
Post /workshopAbsagen oder Post /workshops/7554/absagen oder Put /workshops/8654/abgesagt
Was ich mir noch vorstellen könnte, wäre Folgendes, auch um die Möglichkeiten für den Aufrufer zu beschränken:
Put /workshops/97533/status-abgesagt
So lässt man den Aufrufer gar nicht in jedem Workshopzustand alle Zustände als Auswahl. Macht ja bspw. keinen Sinn, den Workshop abzusagen, wenn er bereits durchgeführt wurde.
Wie sollten APIs denn deiner Meinung stattdessen umgesetzt werden? Oder geht es dir um die Begriffe auf der GUI?
Das video tut echt weh. Bin seit fast 10 jahren Entwickler und baue fast ausschließlich Excel-artige Oberflächen. Problem ist allerdings dass wir meist bestehende Prozesse "digitalisieren" die auf 15 Jahren Excel basieren. Das heißt eine UI die zu weit weg von Excel ist, ist vom Kunden nicht erwünscht.
Eine kleine Bitte noch: Die Farbe im Hintergrund bitte beim Videodreh auf eine festlegen. Ein sanftes Orange wäre schön😀
"CRUD-Käppchen und der böse Wolf" :D
Ich persönlich bin aber noch nicht ganz überzeugt. Vielleicht interpretiere ich CRUD aber auch nur ein bisschen liberaler.
DB: CRUD auf DB-Tabellen
Models: zusätzlich CRUD auf "virtuellen Ressourcen", die nicht 1:1 so in der DB existieren müssen
API: ggf. zusätzliche Routes für manche Ressourcen nach Bedarf
UI: so wie es der Kunde haben will
Damit ist man schon ziemlich flexibel. Wüsste nicht, was man damit nicht bauen kann.
Grundsätzlich interessanter Punkt, welcher aber den vermtlich wichtigsten Aspekt der IT, nämlich die Abstraktion aussen vor lässt. Das ist eben gerade die Stärke von CRUD: man kann dieses Konzept auf sehr viel Use Cases anwenden. Es eine wichtige Aufgabe von Softare Engineering, zu abstrahieren und damit Unnötiges von Nötigem trennen. Z. B. macht es sehr viel Sinn, Zugriffsrechte eben aufgrund von CRUD zu steuern und nicht aufgrund von iregendwelchen anderen Verben. Das heisst aber nicht, dass man den Enduser damit belästigen muss.
Und es gibt noch einen Haufen anderer wichtiger Wortarten, welche eine Geschichte interessant machen, aber in einem Computerprogramm nicht viel Sinn machen (z. B. Adjektive oder Adverben).
Mit deiner Grundidee bin ich einverstanden, Daten-operation nicht als User Funktionen in der Gui zu sehen. Doch die Meisten sehen es anders. Die meisten Unternehmensdoftware sind gute Beispiele, wie man nicht machen muss.
Das ist der Grund, warum es so viel wirklich schlechte Unternehmenssoftware gibt. Vor allem, wenn man sich den Code von so einer Software anschaut, kommt einem meist das blanke Grausen! Und dann wundert man sich auch nicht mehr, warum neue Features und Bug-Fixes nur sehr schleppend implementiert werden...
@@matthiasendler7268 absolut korrekt. Das Problem kennt glaub ich jeder. Nur ist es eine extreme Mühe das denen klar zu machen die ständig nur auf das Geld sehen. Man kann den Zeitgewinn durch Refactoring nicht in Zahlen ausdrücken, gemessen an der verbrannten Zeit durch Bugfixing. Man kann auch die langwierige Einarbeitung in schlechte und undurchsichtige Software nicht in Zahlen ausdrücken. Das ist aber das einzige, was Manager verstehen. Wir haben uns angewöhnt einfach notwendige Dinge zu machen, weil die Verantwortlichkeit bei uns, den Entwicklern liegt. Das Management muss damit leben. Ganz einfach. Nur haben viel zu wenig Team den Schneid sich schützend vor die Software zu stellen und damit den Wert des Unternehmens langfristig im Auge zu haben.
@@AndreasKempe ich kann dich verstehen, jedoch denen klar zu machen - funktioniert nur in der Theorie. In der Praxis ist das jedoch fast immer anders.. Die mit dem Geld bestimmen Rahmenbedingungen, Umfang, Qualität, Zeit und viel mehr. Und sie lassen sich nicht ändern.
@@valeridause Das ist nicht wahr. Wir haben jede Mengen Kunden mit sehr viel Geld. Sie machen mit euch, weil ihr es zulasst, nicht weil sie das Geld haben. Das ist ein völliger Trugschluß den ich ständig als Ausrede höre. Wenn man nicht genug Verantwortung seiner Arbeit gegenüber hat, läßt man sich treiben und schiebt sie immer wieder anderen in die Schuhe um irgendwann das Schiff zu verlassen, weil der Kunde mit der Software zu viel Ping-Pong gespielt hat. Es ist die Verantwortung der Entwickler, die Software zu schützen und best möglich zu betreuen. Nicht die des Kunden. Es lassen sich immer Kompromisse finden. Man muss es nur auch wirklich wollen. Wir haben täglich x Diskussionen darüber mit diversen Kunden. Sie wollen Qualität also müssen sie damit leben. So einfach ist das. Ich kenne genug Projekte die durch so eine schulterzuckende "Ja was soll ich denn machen" Einstellung an die Wand gefahren wurden.
Aber leider ist es in immer mehr Opportun die Verantwortungen anderen in die Schuhe zu schieben.
@@AndreasKempe Was für eine schlechte Angewohnheit, Menschen persönlich zu beurteilen, ohne sie zu kennen.
"..Wenn man nicht genug Verantwortung seiner Arbeit gegenüber hat.."
"..Es ist die Verantwortung der Entwickler, die Software zu schützen und best möglich zu betreuen.."
Ich kenne sehr viele Entwickler, die Blut, Geld, Nächte und ihre gesamte Leidenschaft in die Entwicklung stecken. Doch sie können keine Verantwortung für die Software tragen, wenn in Projekten nicht das gemacht wird, was sie vorschlagen, sondern das, was von anderen gewollt wird - und meistens sind es die, die eine Entscheidungs-Kraft haben. Zu beschreiben, wer diese Kraft hat, ist zu komplex. Meistens sind es die mit dem Geld, auch mit Macht. Oder Nähe zu Personen, die dieses haben. Daher ist es link zu glauben, dass Entwickler für die Software verantwortlich ist, wenn z.B. die Architektur-Entscheidungen von einem Möchtegern-Architekt oder einer Firma gemacht werden, der/die keine Ahnung davon haben. Ein Entwickler verantwortet nur das, was ein Entwickler machen kann. Nicht weniger. Aber auch nicht mehr.
"...So einfach ist das.." - das ist in der Theorie. In der Wirklichkeit ist es in fast allen Firmen genug an Projekten, die Geld-artig schon eine Mondlandung bezahlt haben, jedoch kein Ende in Sicht ist oder die Qualität so miserabel ist, dass keine oder schlecht Architektur- oder Datenbank-Modell-Beschreibung das ist, ohne Namenskonventionen, ohne Prozess-Dokumentation usw. Doch ich vergesse immer - wir leben doch in einer agilen Welt, wo nach dem Agilem Manifest - ein laufendes Produkt über Dokumentation steht. Doch wenn man ein Ende jemals bekommt, dann hat man weder laufendes Produkt noch eine Dokumentation. Aber der Entwickler muss laut ihrer Aussage verantworten. Super!
Nehmen Sie bitte mit, dass Menschen zu beurteilen, ohne sie zu kennen - ein so-la-la Stil ist.
CRUD und REST haben eig nix miteinander zu tun, außer dass viele Leute denken, es wäre dasselbe, weil viele Einsteigerbeispiele es suggerieren.
Bei REST geht es in Wirklichkeit darum, die Zustandsbehaftung eines APIs aufzulösen, um den Dienst serverseitig besser skalierbar zu machen. Man nimmt jeglichen Zustand auf Dienst-Level weg und gestaltet die Anfragen entsprechend, dass alle für die Bearbeitung notwendigen Infos immer explizit mitgeschickt werden. Zudem macht man alle von der Ressource aus navigierbaren, verwandten Ressourcen über Hyperlinks in den Antworten verfügbar (kein lästiges Zusammenbauen von URLs im Client).
Dadurch dass der komplette Zustand nun vom Client verwaltet wird und explizit in jeder Anfrage steckt, ist es praktisch egal, welche konkrete Dienstinstanz die Anfrage serverseitig abarbeitet. Man kann also den Dienst auf ganz vielen Servern gleichzeitig laufen lassen und ist nicht länger durch die Kapazität einer einzelnen Maschine limitiert. Zudem wird durch die Resource-Links auch clientseitig die Navigation des APIs einfacher, weil man kein Wissen über das Zusammenbauen der URLs benötigt.
Das alles hat recht wenig mit CRUD zu tun. Die REST APIs sollen - wie richtig gesagt wurde - die Use Cases der Anwendung widerspiegeln und beschreiben, wie man vom einen Systemzustand in den nächsten kommt. Wenn man es anders macht, ist es halt einfach nicht mehr RESTful, sondern ein x-beliebiger HTTP Server.
Mir tut Roy Fielding (Erfinder von REST) wirklich leid, dass ihn die halbe Welt missverstehen will, nur weil die Leute zu faul sind, seine Doktorarbeit zu durchdringen.
Die von dir beklagten Einsteigerbeispiele sind so, weil ReST auf HTTP basiert, und die Hauptverben sind nun mal POST, GET, PUT und DELETE, also CRUD.
ReST fügt dem im Wesentlichen zwar die Zustandslosigkeit hinzu, es bleibt aber bei dem Grundprinzip.
Wir haben also ganz eingeschränkte Ausdrucksmöglichkeiten, jedenfalls, wenn man die Verben so interpretiert, wie ihre Bezeichnung nahelegt.
Der Geburtsfehler ist, wenn man so will, HTTP für alles zu verwenden. Dafür war es nie gedacht, das ist aufgepfropft.
Danke!
Der Rant ist angebracht, leider ist das oft anzutreffen bei Projekten. Vor Jahren hat nach einem halben Jahr Entwicklungszeit der PO mal ketzerisch das das Projektteam gefragt: "So, jetzt habt ihr mir also ein Frontend für die Datenbank geschrieben. Aber das ist doch absolut Commodity. Kann man das nicht auch automatisch generieren lassen?". Und die Kritik war richtig. Und dann wird vorne dran noch eine UI gebaut, die aussieht wie eine Excel-Tabelle.
Da trägt doch der PO die primäre Verantwortung wenn er das ein halbes Jahr so entwickeln lässt. Wer, wenn nicht er koordiniert requirements und regelmäßige abnahmen für das Frontend?
Gute Software erzählt eine Geschichte in einer Programmiersprache und daraus sollte sich für jeden, der dieser Sprache mächtig ist, die Fachlichkeit herauslesen lassen können und zu einem Domänenexperten machen. Eine gut modellierte Domäne sollte nur sehr wenige, im Idealfall keinerlei externe Abhängigkeiten haben. Leider ist das in der Realität oft nicht der Fall und die Systeme sind dann überkomplex, weil man z.B. in einer Update-Funktion alle fachlichen Fälle berücksichtigen muß. Das führt zu riesig großen Funktionen, die kaum mehr durchschaubar sind. CRUD hat seine Berechtigung und gehört in den Data Access Layer, aber um Gotteswillen nicht in eine fachliche Domäne. Geht es in einer Software nur darum Daten ohne große Fachlogik zu erfassen, zu verwalten und/oder sichtbar zu machen, dann kann es sinnvoll sein das komplette System mit CRUD aufbauen. In diesem Fall sollte man allerdings die Grenzen kennen.
Edit: Damn Typos! :P
Oh mein Gott 🤯 ich hatte zuerst Angst dass crud nicht mehr angewendet wird - macht mir doch keine Angst 😂
Ich dachte zunächst das ich das Thema verstanden habe. Zum Schluss hätte ich mir doch schon etwas Code gewünscht um das ganze Bildhaft auch darzustellen. Bei der Geschichte mit dem Shop und Warenkorb habe ich nämlich eher an Logging als Lösung gedacht. Ich setze gern CRUD ein, aber mein Entwicklungsstil hat sich momentan dahin geändert das ich das Fachliche in Domänen übertrage. So sehe ich in meinen Geschichten immer einen Sinn.
Es ist einfach ein Vergnügen dir zuzuhören 😸
Die Gegenüberstellung Substantive vs. Verben ist meiner Meinung nicht zielführend. Noch weniger die Abstufungen von Substantiven. Wenn man Prinzessin mit ein Schaff austauschen wird, dann wird die Heirat eines Prinzen mit einem Schaff alles andere als erfreuliches Erreignis im Königshaus. Sorry, aber zu sehr abstrakt, obwohl als Idee für die Erklärung eine sehr gute Wahl.
Full Ack! 👍
lustige Geschichte 🤣🤣🤣
DDD! 😁
"Ich als Entwicklerin oder Entwickler" ist schon Gendern am Nullpunkt. 😅
Warum soll man nicht schreiben warenkorb.add( artikel ) oder warenkorb.delete( artikel ) oder warenkorb.updateQuantity(artikel, 7) o.ä ?