Principles of Design in Software Systemen
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32333 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareFreewareOpen sourceTwitterXMLComputer animationLecture/Conference
00:29
SoftwareSystem programmingSolid geometrySingle-precision floating-point formatOpen setClosed setIntelInversion (music)View (database)Online helpRAIDSurvival analysisPlane (geometry)Royal NavyMathematical analysisStack (abstract data type)Open sourceEntire functionSoftwareMathematicianInferenceSoftware architecturePILOT <Programmiersprache>Royal NavyHand fanSocial classWiener filterMusical ensembleCodeSet (mathematics)RobotValue-added networkInferenceOpen sourceGoogleComputer animation
08:29
Sample (statistics)Mathematical analysisDecision theoryPareto distributionRule of inferenceMandelbrot setNichtlineares GleichungssystemMathematicsFocus (optics)System identificationProduct (business)Component-based software engineeringPoint cloudTwitterElement (mathematics)Mathematical optimizationMetreZusammenhang <Mathematik>Similarity (geometry)SoftwaresystemSoftwareStatisticsWeb-AnwendungComponent-based software engineeringApple <Marke>Decision theoryRuby on RailsiPodProduct (category theory)MP3-PlayerMetreWord processorComputerMathematicianWordFINANZ <Programm>Web applicationFlagiPadPoint of saleMandelbrot setArmQuery languageTime zoneTrail
16:28
Stability theoryProof theoryComputer programEmailPressureComputing platformBroadcast programmingSample (statistics)Fixpunkt <Datensicherung>Stress (mechanics)IndexSoftwareGrand Unified TheoryComputer programMobile appTkOpen sourcePhysical lawFRAMEWORK <Programm>Computer animation
20:40
Complex (psychology)Natural languageCoding theoryOrthogonalityHypothesisFunction (mathematics)Form (programming)MathematicsLISPGoogleRoute of administrationSoftware developerPIK <Programm>SpacetimeTheoryVolumetric flow rateUser profilePropositional formulaOrthogonality
26:29
Function (mathematics)Form (programming)Focus (optics)ArchitectureSoftwarePhysical systemSoftware frameworkPublic domainIterationFRAMEWORK <Programm>DatabaseWritingExpressionSoftwarePublic domainSchaleComputer animation
29:55
Bus (computing)Lecture/Conference
32:05
Computer animation
Transcript: German(auto-generated)
00:08
Ich schaue mal, mein Name ist Lorian Weilner und ich bin auf Twitter aktiv gelegentlich als Ed Weilner, früher mehr, heute weniger und ich bin verkappter Modernist in den nächsten 50 Minuten.
00:21
Ich möchte euch über die Principles of Design, also Design-Prinzipien in Softwaresystemen erzählen. Ich arbeite bei der Ferrent Solutions GmbH, wir haben einen Stand irgendwie vorne. Einige von euch waren schon da. Fangen wir mit dem Design-Prinzipien an. Die Frage ist, was sind Design-Prinzipien und was hat das mit Software zu tun, wenn man nach Design-Prinzipien sucht.
00:43
Bei Google ist das erste, was man findet, das Solid, das kommt von Robert C. Martin, Uncle Bob aus seinem Buch Clean Code. Das steht für Single Responsibility. Eine Klasse hat bloß einen Grund, seinen Zustand zu ändern.
01:02
Open and closed, be open to extension, not closed to modification. Das List Gov der Substitutionsprinzip, eine ableitende Klasse kann für eine Elternklasse eingesetzt werden. Interface segregation, so Interfaces sollten wirklich bloß das beschreiben, was sie tun, also wenn es ein Worker-Interface gibt,
01:22
dann ist die Methode take a break für Roboter wenig hilfreich zum Beispiel. Und die dependency inversion, das heißt die Kollaboratoren werden Klassen zugewiesen. Das ist alles richtig und kommt auch gerne in Vorstellungsgesprächen vor, zumindest bei uns ist aber ein bisschen kurz gesprungen, finde ich.
01:45
Die Frage ist, gibt es mehr und das beschäftigt mich schon seit einiger Zeit. Vielleicht kann man einen Schritt zurückgehen und schauen, ob wir nicht vom klassischen Design was sehen können. Das kommt daher, ich war in den letzten Jahren häufiger in London und in New York und in beiden gibt es fantastische Museen.
02:07
In London das neue Designmuseum, in New York das Cooper Hewitt. Beide Museen arbeiten daran oder investieren viel Zeit und Aufwand daran, den Menschen Design nahezubringen, insbesondere Industriedesign.
02:24
Und es trat mich seit einiger Zeit um, diese Prinzipien, die da stecken, auch in Software zu sehen. Ich bin dann über dieses fantastische Buch gestolpert, Universal Principles of Design. Bei von Luit und wie das so ist mit dem menschlichen Hirn, wir
02:42
erkennen gerne Muster und ich habe einige davon in Softwarearchitekturen durchaus wir erkannt. Vielleicht ist es Unsinn, was ich jetzt erzähle, vielleicht glaube ich aber nicht und vielleicht geht es euch ja ähnlich und ihr könnt hier was mitnehmen. Mit dem ersten Designprinzip, das ich von dem ich hier sprechen möchte, ist
03:05
das Survivorship Bias, was uns offen begegnet ist, auch als Selection Bias bekannt. Es gibt ein Bild, das vielleicht einige von euch kennen oder es gibt kein Bild. When failures become invisible, the difference between failures and success may also become invisible.
03:23
Das heißt, wenn das Scheitern nicht mehr sichtbar ist, ist der Unterschied zwischen Scheitern und Erfolg unter Umständen auch nicht mehr sichtbar. Das Ganze geht zurück auf dieses Bild oder ein so ähnliches, das ist ein nachgemachtes.
03:40
Im zweiten Weltkrieg hat ein Bomberpilot eine 50%ige Lebenschance. Es entspricht einem Münzwurf. Also wenn man irgendwie eine Stadt bombardiert oder zurückfliegt und am nächsten Tag wieder irgendwie eine Münze wirft, ob man überlebt oder nicht, dann ist die Wahrscheinlichkeit sehr groß.
04:02
Jeder Flug, also du hattest die 50%ige Überlebenschance von einem Flug gesund oder zumindest lebend zurückzukehren. Genau, das hat die US Navy sich auch gedacht und überlegt, was kann
04:20
sie tun, um ihre Flugzeuge schussfest zu machen oder die Überlebensfähigkeit zu erhöhen. Sie haben also eine Studie begonnen, um zu gucken, wie sie die Panzerung in Flugzeugen verstärken können, um die Überlebenschance ihrer Piloten zu erhöhen.
04:44
Das ist jetzt so, dass Panzerung natürlich wiegt und Bomber haben ein Ziel, nämlich Bomben zu transportieren. Das heißt, je mehr Panzerung, desto weniger Ladung. Also haben sie sich überlegt, was können wir machen, um unsere Flugzeuge zumindest ein wenig mehr Überlebenschance zu verschaffen.
05:07
Sie sind also losgezogen und haben die Flugzeuge, die zurückgekommen sind, untersucht und geschaut, wo diese am häufigsten getroffen wurden und sich überlegt, na gut, dann werden wir da an dieser Stelle die Panzerung anbringen, um das Überleben zu ermöglichen oder die Rückkehr zu ermöglichen.
05:34
Aber der Mathematiker, Ungarisch-Hilfsche Abstammung, Abe Walt, hat angemerkt, dass es
05:44
vielleicht keine gute Idee ist, sich bloß die Flieger anzugucken, die zurückgekommen sind, weil immerhin sind die halt zurückgekommen, vielleicht irgendwie angeschossen und kaputt, aber sie sind halt wieder da.
06:04
Und die Navy hat dem zugestimmt und dann die Flieger an den Stellen verstärkt, wo die zurückkehrenden Flugzeuge nicht beschädigt waren. Abe Walt ist wieder so eine super interessante Biografie, viel zu jung gestorben, mit 50 irgendwie im Flugzeug abgestürzt, ironischerweise.
06:29
Aber es gibt manche Leute, manche Leute haben ein Leben, das reicht für zwei, er ist einer davon. Survivorship Bias ist das Result of Non-Random Sampling of Evidence, Distorting Analysis and Conclusions thereof.
06:47
Das heißt, sobald man anfängt, seine Schlüsse an nicht-zufällig gesammelten Messpunkten anzulegen, wird die Schlussfolgerung gestört.
07:04
Es gibt dieses fantastische Buch von Van Talep, The Black Swan, das heißt auf Deutsch der schwarze Spahn. Der bringt das Beispiel, dass Leute gerne, dass es der Traum vieler Leute ist, ein Restaurant zu gründen, weil sie gerne essen gehen und sehen. Gerade als er bringt die New Yorker-Restaurantszene, das ist da vielleicht nochmal
07:23
ein bisschen anders als hier, dass Leute gerne Restaurants gründen wollen, weil sie feststellen, da ist immer was los, sind immer voll, die Leute freuen sich, denen geht es gut. Sie haben Leute, diese Receptionist, die platzieren und das scheint ein wunderbarer Berufswunsch zu sein.
07:46
Aber der Friedhof der gescheiterten Restaurants ist sehr leise, niemand singt von denen. Auf Software beziehen könnte man sagen, dass der Friedhof der gescheiterten Open Source Projekte heißt SourceForge.
08:04
Wenn man da mal guckt, findet man einige ab einiger zurückgelassenen, halb fertige Open Source Projekte. Was kann man machen, um dem Survivorship Bias zu begegnen, der erste Schritt ist zu wissen, dass es es gibt. Wenn man also eine kleine Kundenmenge für sein Produkt hat oder für seine Software, ich rede von Nutzern, man sollte Nutzer als Kunden betrachten,
08:30
dann ist es vielleicht eine gute Idee, alle zu fragen. Ein Beispiel, was ich in dem Zusammenhang gerne bringe, ist, wenn ich Software für Kernkraftwerke schreibe, dann kann ich durchaus alle Kernkraftwerke fragen, ob sie Bedarf dafür haben, bevor sie endlich abgeschaltet werden.
08:45
Wenn das nicht der Fall ist, ist es eine gute Idee, möglich zufällig die Befragung durchzuführen, wenn die Population zu groß dafür ist.
09:03
Die Idee ist, dass man sich seine Population, also die gesamtmöglichen Kunden oder Benutzer anguckt und die Sample Methods sich genau überlegt, ob das eine gute Idee ist, damit Statistische Analyse anzugehen.
09:27
Man sollte sich die Ergebnisse, die man aus der Statistischen Analyse zieht, genau angucken und sowohl die Sample Methode als auch die Analysen mit Zonen betrachten.
09:41
Weil, und auch das ist wieder ein tolles Buch, das ich lesen kann, eine dumme Entscheidung, die funktioniert, mit Glück erscheint bloß im Rückblick als eine brillante Entscheidung. Die meisten dummen Entscheidungen führen zu derben.
10:03
Das nächste wäre die 80-20-Regel, die einige von euch vielleicht als das Pareto-Prinzip kennen. Das Pareto-Prinzip wurde zum ersten Mal festgestellt von Wilfredo Pareto. Das war ein Ökonom Anfang des letzten Jahrhunderts, und zwar mit einem Namen wie Donahal in der Disziplin.
10:41
Man könnte auch böse sagen, Pareto ist der Grund, warum Wirtschaftswissenschaftler denken, sie würden eine Wissenschaft betreiben und keine Sozialwissenschaft. Und die Frage, die Pareto sich gestellt hat, ist, wieso haben 20% der italienischen Bevölkerung 80% des Reichtums?
11:05
Und er kam zu dem Schluss, dass sie die entscheidenden 20% identifiziert haben und ihre Ressourcen auf diese 20% angewendet haben. Wenn man Ressourcen auf Sachen jenseitiger 20% anwendet, gibt es diminishing returns.
11:25
Also kommt das Return of Investment, wie es im Business-Jargon heißt, er nimmt es einfach ab. 80% der Benutzung eines Produktes werden von 20% ihrer Features getrieben.
11:45
Wer von euch hat irgendwie alle Features seiner Textverarbeitung benutzt? 80% der Wachs eines Produktes kommen aus 20% seiner Komponenten. Und mein Lieblingsbeispiel für das Pareto-Prinzip im Produktdesign will ich euch jetzt zeigen.
12:04
Das ist zum einen der Walkman. Als Sony 1979 den Walkman präsentiert hat, hat niemand gedacht, dass das Ding fliegen würde. Das konnte nichts, was man von einem mobilen Abspielgerät erwartet hat. Es konnte nicht aufnehmen. Die Audioqualität war viel zu schlecht, dass man da irgendwie als Audiophiler sich trauen würde, damit Musik zu hören.
12:27
Das ging ja nicht. Und die ganze Audioindustrie hat dem Produkt quasi keine langen Überlebenschancen zugetraut.
12:41
Ich glaube, der Bryant Walkman wurde bis vor kurzem von Sony geritten und ist ein Wunderwerk der Produktdesigns. So was Ähnliches ist Apple nochmal gelungen, 20 Jahre später mit dem iPod. Die haben nämlich festgestellt, dass wenn man das Verwalten seiner Musiksammlung trennt von dem Abspielen und sagt,
13:10
ich muss meine MP3-Sammlung nicht auf meinem MP3-Player verwalten, sondern kann sie auf dem Computer verwalten und dann synchronisieren auf dem iPod,
13:20
Entschuldigung, dann kann ich das Use-Enterface und das gesamte Design des Abspielgerätes so vereinfachen, dass es für Mom and Pop, wie es in den Amerikanischen heißt, benutzbar geworden ist. Und ich glaube, wir wissen alle, dass der gesamte Mobilmarkt von Apple damit startend umgekrempelt wurde.
13:46
Als Softwaresystem sieht man diese 80-20-Regel ganz besonders gut bei Ruby on Rails. Der Autor Daniel Heimeier-Hansen ist bekennender Advokat dieser Ergänzweise
14:09
und hat tatsächlich mit dem Freigeben von Rails dafür gesorgt, dass der Weg oder die Art, wie wir Software entwickeln oder zumindest Web-Anwendungen maßgeblich verändert wurde.
14:24
Und zumindest zeitweise liefen ein Haufen der jetzt bekannten großen Sites auf Rails, Twitter, Airbnb, Shopify, Soundcloud, Goodreads, Wunderlist und einige mehr.
14:42
Zumindest die meisten von denen, die ich da aufgeschrieben habe, gibt es auch noch und irgendwie auch noch in der ursprünglichen Form. Aber wenn man sich dabei bewusst wird, kann man das machen. Das 80-20-Prinzip ist besonders wichtig, wenn man über beschränkte Ressourcen verfügt.
15:04
Wir use the 80-20-Rule to assess the relative value of elements, target areas of refactoring and optimization and focus resources in an efficient manner. Wir haben immer bloß beschränkte Ressourcen, sei es Mitarbeiter oder Geld oder Zeit. Und wenn es uns gelingt, die entscheidenden 20% zu identifizieren,
15:21
können wir die uns zur Verfügung stehenden Ressourcen da am gewinnbringendsten einsetzen. Das nächste Designprinzip, das ich hier vorstellen möchte, ist der Feature Creep. Das ist eher ein Anti-Pattern und der wird gerne verwandt mit diesem Schiff.
15:45
Das ist die Vasa. Die Vasa wurde 1628 gebaut und sollte Stolz der schwedischen Flotte sein. Sie sollte Angst in die Herzen der Gegner von Schweden bringen und sollte
16:07
König Gustav Adolf den Krieg, den er damals führte, gegen Polen, Litauen gewinnen. Also es wurde das neue, das geplante Flaggschiff der polnischen Flotte. Das Problem ist, es ist nach 1300 Metern gesunken auf der Jungfernfahrt
16:22
vor den Augen von entsetzten Zuschauern und hat 30 Leuten mit ihnen totgerissen. Mittlerweile gibt es in Stockholm ein wirklich beeindruckendes Museum, wo das Wrack ausgestellt und restauriert wurde. Die Vasa gilt zumindest nun als Goldstandard für geborgene Schiffwracks und die Präsentation da.
16:47
Das Gerücht geht, dass König Gustav Adolf nach Beginn des Baus angefangen hat, extra Kanonendecks und Verzierungen zu bestellen und hat damit die Stabilität des Designs gefährdet.
17:04
Leider ist es so, dass es dafür keinen historisch belegten Beweis gibt, dass das wirklich so passiert ist. Sonst könnte man sich hinstellen und sagen, Feature creep literally sank the boat. Aber die Geschichte ist sehr schön.
17:21
Für Software-Systeme gibt es Savinsky's Law. Jamie Savinsky war einer der entscheidenden Entwickler von Mozilla und VRX EMAX. Er ist jetzt Nachtclubbesitzer in San Francisco. Every program attempts to expand and it can read mail.
17:42
Those programs which cannot so expand are replaced by ones which can. Das heißt, jedes erfolgreiche Programm wird druckausgesetzt in ein Toolkit oder eine Applikationsplattform sich zu entwickeln.
18:03
Die Mailgeschichte ist nur ein Seiteneffekt. Wenn man darüber nachdenkt, gibt es da einige, die wir alle kennen. Eine zum Beispiel ist der EMAX oder das lange Warten auf eine Programmiersprache, auf die wir uns alle sehr gefreut haben
18:20
und die dann 20 Jahre zu spät kam oder 20 Jahre zu spät Perl 6, könnte man dem Feature creep zuschreiben. Feature creep ist einer der Hauptgründe, warum Kosten und Zeit wie GEs überzogen werden in Projekten und in Software.
18:44
Ich habe das selbst erlebt, dass relativ schnell Fragen kamen in unserem Open Source Projekt, ob wir nicht doch das als Framework ausbauen könnten und man sich das selbst zusammenstöpseln kann. Da waren wir hart und haben gesagt, nein, das machen wir nicht. Wir bauen kein Framework, sondern wir machen weiter ein Produkt.
19:05
Features werden nämlich eigentlich nur hinzugefügt, kaum entfernt. Es gibt merkwürdigerweise die Idee, dass mehr besser ist.
19:22
Viel hilft viel, wie die Hausfrau sagt. Was kann man dagegen tun? Man kann sich überlegen, dass jedes Feature auf jeden Fall an einen Benutzer oder Kunden-Use-Case gebunden ist.
19:43
Es ist eine gute Idee, Checkpoints einzuführen, Milestones, nach denen keine neuen Features mehr hinzugefügt werden. Das nächste Design-Prinzip, das ich hier vorstellen möchte, ist KISS. Das war das erste Album, das ich von meinem Taschengeld gekauft habe.
20:02
Das war großartig. Vier maskierte Männer, die Rock'n'Roll gespielt haben. Der eine konnte sogar Blut spucken. Das war ganz toll. Im Zuge meines Vortrags habe ich das noch mal angehört und muss sagen, ich muss meinen Eltern dankbar sein, dass sie so viel Nachsicht mit mir hatten. Das war ganz fürchterlich.
20:21
KISS steht natürlich für Keep It Simple Stupid. Das war leider wieder ein sehr militaristischer Ansatz, ein sehr militaristisches Bild. Das Produkt Design, das mit diesem Design-Prinzip gewonnen wird, ist die AK-47 Kalashnikov.
20:40
Das ist die AK-47 von Michael Kalashnikov designed worden, verfügt bloß über acht wirkliche Teile und ist irgendwie leicht zu pflegen von gering qualifiziertem Personal, wie man so schön sagt, in Einsatzzituation.
21:03
Wahrscheinlich die Kleinwaffe, die Schuld an dem Tod der meisten Menschen des 20. Jahrhunderts ist. Die Lehre, die man daraus ziehen kann, ist, dass eine einfache Lösung besser ist als eine komplexe, auch wenn sie dämlich aussieht.
21:23
Mein Lieblings, wo ich das Prinzip quasi in hoher Form sehe, sind Lisp und Go. Go wurde als Sprache entwickelt von Google oder von Pike bei Google unter der Prämisse,
21:41
dass die Sprachspezifikation in den Kopf eines Entwicklers passen soll. Das heißt, dass man nicht irgendwie nachgucken muss, wie war denn so was mal, sondern das wirklich im Kopf haben kann. Sie sollte extrem schnell aufnehmbar sein, weil Google das Problem hat, sie haben irgendwie einen hohen Durchsatz an Entwicklern. Es gehen ständig welche, es kommen neue.
22:01
Sie müssen in der Lage sein, schnell im Projekt von denen sie hin und her springen, up to speed zu sein und produktiv teilnehmen zu können. Es gibt quasi eine ganze Problemklassifikation von Diskussionsklassifikation von Problemen.
22:21
Die andere, die wir alle aus Diskussionen über Programmgesprachen kennen, fällt bei Go einfach weg. Es gibt keine Bike-Shading-Diskussion, wie viele Taps man jetzt benutzen soll oder wie viele Spaces oder 3 oder 4 oder woher die Klammern hingehören. Es gibt irgendwie Go-Format, das ist die kanonische Formata für Go und so haben die Phoenix-Go-Programme auszusehen.
22:45
Features werden nur hinzugefügt, wenn sie der Sprache was bringen, also wenn sie tatsächlich im Sinne von was wirklich einzigartiges der Sprache hinzufügen. Sie reden in dem Fall von der Feature-Ortogonalität und es gibt dieses Zitat von Rob Pike,
23:08
dass ein wenig Kopieren besser ist als Dependency-Management. Das heißt, Abhängigkeiten werden nicht irgendwie geladen, sondern werden einfach mitkompiliert. Und wie kommt man dazu, wie kriegt man seine Entscheidung, seinen Design möglichst einfach?
23:24
Ein weiteres Designprinzip ist Orcum's Razor. Die Anwendung von Orcum's Razor ist hervorragend geeignet, um Designs simpel zu bekommen. Die Anwendung von Orcum's Razor.
23:42
Applying Orcum's Razor is a good method to achieve simplicity. Das Theorien wurde von einem Mönch im 13. oder 14. Jahrhundert, ich bin nicht ganz sicher, postuliert. Among competing hypotheses, the one with the fewest assumptions should be selected.
24:01
Man kann es nicht ganz wortgetreu übersetzen. The simplest solution is most likely the correct solution. Wenn man sich das als Leitbild setzt, dann ist das Ergebnis meistens relativ einfach.
24:21
Es gibt das zugeschriebene Zitat, make everything as simple as possible, but not simpler. Man kann es auch verdummen. Ein Lieblingsbeispiel dafür sind TLSRs, also Spiegelreflexkameras und Mobiltelefonkameras. Es gibt kaum noch kleine Taschenkameras, weil die Mobiltelefonkameras hervorragend funktionieren.
24:47
Ich weiß nicht, wann ich zum letzten Mal in einer Retro-Click unterwegs war. Aber es gibt auch noch die Schlachtschiffe, die ein anderes Benutzerprofil haben.
25:04
Deswegen sind die Bedienungen in der Bedienung komplett anders und viel komplexer als eine Mobiltelefonkamera. Das kann man auch Go vorhalten. Können Sie das lesen? Ich bin mir nicht sicher, ob ich dem zustimme.
25:21
Ich bin mir bei Go noch nicht. Ich habe da noch keine abschließende Meinung gebildet.
25:44
Das letzte Design-Prinzip ist Form follows Function. Form follows Function kommt zum ersten Mal vor in einem Zitat von Louis Sullivan. Form ever follows Function and this is the law. Where the function does not change, form does not change.
26:04
Louis Sullivan war einer der großen Architekten der Prairie School of Architecture in Chicago Anfang des letzten Jahrhunderts. Es wird gemunkelt, er wäre der Ideengewer für diesen Architekten in Ayn Rand's The Fountainhead.
26:22
Das unsägliche Buch. Das ist aber nicht ganz klar. In Deutschland ist Form follows Function bekannter durch das Bauhaus, die Anfang des 20. Jahrhunderts, die das Produktdesign revolutioniert haben durch Verwendung moderner Technologien und Werkstoffe, gegründet von dem Architekten auch, wobei Architekt vielleicht ein bisschen zu kurzgreifend ist, Walter Gropius.
26:48
Und Form follows Function war bis der Schlachtruf der Modernisten. Und wenn man das präskriptiv beschreiben möchte, Focus on Function first, only second on Form.
27:02
Das heißt immer zuerst auf die Funktionität achten. Erst beim zweiten auf die Form. Beschreiben könnte man sagen, beauty arises from purity of function. Das heißt die Schönheit entsteht aus der Reinheit der Funktion.
27:22
Es gibt, wie das immer so ist, es gibt natürlich nicht in does not apply in every case, but following it usually leads to superior design. Also natürlich gibt es immer Gründe, sich dem anders zu widmen,
27:43
aber wenn man dem folgt, führt das üblicherweise hervorragende Designergebnissen. Wenn wir jetzt die Funktion eines Software-Systems begreifen, da fehlt der Business-Process, sorry, gerade noch geändert die Folie.
28:07
Wenn wir jetzt die Funktion eines Software-Systems begreifen, als den Business-Prozess, den das ausführt, dann sollte die Form der Software, die Architektur von ihm definiert werden, vom Geschäftsprozess,
28:23
nicht den anderen Weg, nicht umgekehrt, wie man auf Deutsch sagt. Das ist das Bauhaus-Museum in Berlin, das Bauhausarchiv. Wenn ihr mal da seid, also kann ich das als unbedingt Museumsempfehlung aussprechen.
28:41
Frameworks sollte man nicht benutzen, bloß um sie zu benutzen. Man könnte sogar weitergehen und sagen, vielleicht ist es eine gute Idee, erstmal mit der Problemdomäne anzufangen, bevor man sich für die Datenbank entscheidet. Try a different, try a domain-driven approach, domain-driven design.
29:03
Das Buch ist ein hervorragendes Hilfsmittel, um die Form der Funktion folgen zu lassen.
29:23
Stellt sicher, dass ihr in kleinen Inkrementen arbeitet und die Form immer noch der Funktion folgt. Und wenn das nicht der Fall ist, dann scheut euch nicht zu refakturieren. Und jetzt bin ich so schnell da durchgerast, dass ich jetzt fertig bin.
29:49
Habt ihr Fragen? Die Frage ist, ob die Designprinzipien autogonal sind
30:15
und ob man sie alle axematisch befolgen kann. Die Antwort? Ich habe da nie drüber nachgedacht.
30:22
Tatsächlich bin ich da eher beschreibend rangegangen. Also wenn ich Sachen, die ich gesehen habe, wo ich der Meinung war, hier ist ein Designprinzip beim Werk und nicht, jetzt setze ich diese drei ein und das nicht.
31:13
Wenn das mit einem Benutzer oder einem Kunden machbar ist, ist das eine sehr gute Idee. Also tatsächlich ist es so, es gibt dieses Finesse-Framework,
31:24
auch von Robert C. Martin, dieses Testing-Framework. Die haben irgendwann die Datenbank-Speicher wieder ausgebaut, weil das jemand benutzt hat. Also wenn das geht, ist das eine erfahrene Idee, bloß ist es halt sehr, sehr schwer. Es ist immer schwerer, Leuten was wegzunehmen, als es ihnen gar nicht erst zu geben.
31:51
Nehme ich mit? Okay, danke.
Recommendations
Series of 25 media