- Technischer Geschmack ist ein anderes Konzept als technische Kompetenz: Man kann sehr fähig sein und trotzdem einen schlechten Geschmack haben, oder wenig Können besitzen und dennoch guten Geschmack zeigen.
- Der Geschmack von Software Engineers bedeutet die Fähigkeit, die zum Projekt passenden Engineering-Werte auszuwählen.
- Er zeigt sich in dem Gespür dafür, welcher Code gut/schlecht aussieht, welche Architekturentscheidungen zufriedenstellend sind und an welchen Problemen man festhält – und spiegelt damit die Menge der Engineering-Werte wider, die man wichtig findet.
- Jede Entscheidung im Software Engineering ist eine fortlaufende Reihe von Trade-offs. Unreife Engineers behandeln bestimmte Ansätze als absolute Wahrheit, während reife Engineers Werte je nach Kontext flexibel austarieren.
- Guter Geschmack ist die Fähigkeit, die Priorität von Werten passend zu einem bestimmten Projekt zu wählen; schlechter Geschmack zeigt sich in der Starre, mit der man an absoluten Maßstäben wie „Best Practices“ festhält.
- Geschmack entsteht durch Erfahrungen in unterschiedlichen Projekten und offenes Denken; letztlich zeigt sich das Vorhandensein guten Geschmacks daran, ob ein Projekt erfolgreich ist.
Der Unterschied zwischen technischem Geschmack und Können
- Technischer Geschmack deckt sich nicht zwangsläufig mit hoher Kompetenz.
- So wie jeder unabhängig von seinen Kochkünsten gutes und schlechtes Essen unterscheiden kann, bildet sich auch in der Softwareentwicklung Geschmack oft vor dem eigentlichen Können heraus.
- Daran, welcher Code „gut aussieht“ oder „nicht besonders gut wirkt“, zeigt sich der Geschmack eines Engineers.
- Welche Architekturentscheidungen Zufriedenheit auslösen und welchen Problemen man mehr Aufmerksamkeit schenkt, funktioniert ebenfalls als Teil des Geschmacks.
- Technische Fähigkeiten können durch Wiederholung und Lernen wachsen, Geschmack entwickelt sich dagegen auf undeutlichere und intuitivere Weise.
-
Anzeichen für Engineering-Geschmack
- Das Gefühl: „Dieser Code sieht gut/schlecht aus“
- Starkes Zufriedenheitsgefühl oder Gleichgültigkeit gegenüber bestimmten Architekturentscheidungen
- Softwareprobleme, die einen auch nach Feierabend weiter beschäftigen – und solche, die das nicht tun
- Geschmack ist, so die These, die Fähigkeit, die für das aktuelle Projekt passenden Engineering-Werte zu übernehmen.
Die Unterscheidung zwischen Können und Geschmack
- Es stellt sich die Frage, ob „gut aussehender Code“ tatsächlich immer der bessere Code sein muss.
- Beispiel: Wer
map/filter bevorzugt, legt möglicherweise mehr Wert auf Lesbarkeit und pure Funktionen; wer for-Schleifen bevorzugt, legt womöglich mehr Wert auf Performance und einfache Erweiterbarkeit.
- Es geht dabei nicht um richtig oder falsch, sondern um Unterschiede in den Werten, die man priorisiert.
- Je nach Sprache und Kontext gibt es jeweils Vor- und Nachteile, daher ist eine Wahl nicht zwangsläufig immer besser.
- Jeder Engineer gewichtet andere Werte, und entsprechend fallen die Präferenzen unterschiedlich aus.
Was Engineering-Geschmack eigentlich ist
- Fast alle Entscheidungen im Software Engineering sind ein Ausbalancieren zwischen konkurrierenden Werten (Trade-offs).
- Unreife Engineers halten zu starr an ihrem eigenen Geschmack fest.
- Reife Engineers erkennen Vorteile aus unterschiedlichen Perspektiven und legen Wert auf Entscheidungen, die zur aktuellen Situation passen.
- Entscheidend ist nicht, ob X (Technik) oder Y (Technik) besser ist, sondern ob die Vorteile von X im aktuellen Projekt stärker gebraucht werden als die von Y.
-
Beispiele für Engineering-Werte
- Resiliency: Funktioniert das System auch bei Ausfällen oder Netzwerkproblemen zuverlässig?
- Speed: Erreicht es eine Performance nahe an theoretischen Grenzen, oder fällt viel unnötige Arbeit an?
- Readability: Können neue Engineers das System schnell verstehen und produktiv werden, sind Funktionen kurz und klar?
- Correctness: Werden ungültige Zustände modelliert, gibt es ausreichend Tests, Typen und
asserts, kommt sogar formale Verifikation zum Einsatz?
- Flexibility: Lässt sich das System leicht erweitern, können Änderungen einfach eingebracht werden?
- Portability: Ist es von einer bestimmten Umgebung abhängig, lassen sich Änderungen an der Deployment-Umgebung einfach umsetzen?
- Scalability: Kann das System bei 10- oder 100-fach mehr Traffic skaliert oder automatisch hochskaliert werden, und wo liegen die Bottlenecks?
- Development speed: Wie schnell lässt sich das System erweitern, und können die meisten Engineers daran arbeiten?
- Darüber hinaus gibt es viele weitere Werte wie Eleganz, Modernität, Open-Source-Nutzung oder Wartungskosten.
- Nicht alle Engineers interessieren sich in gleichem Maß für jeden dieser Werte.
- Je nachdem, welchen Wert man am höchsten gewichtet, unterscheiden sich Sprache, Framework und Design Patterns, die man einsetzt.
Merkmale von schlechtem Geschmack
- Schlechter Geschmack zeigt sich, wenn die eigenen bevorzugten Werte nicht zum aktuellen Projekt passen.
- Problematisch ist mangelnde Flexibilität: die Vorteile bestimmter Technologien oder Methoden ungeachtet des Projektkontexts konsequent durchdrücken zu wollen.
- Wer immer nur mit „Best Practice“ argumentiert, lässt häufig situationsbezogenes Urteilsvermögen vermissen.
- Unflexible Engineers können in bestimmten Projekten gut funktionieren, bei veränderten Rahmenbedingungen oder Aufgaben aber ernste Probleme verursachen.
Eigenschaften von gutem Geschmack
- Guter Geschmack ist die Fähigkeit, je nach Problemstellung die richtigen Engineering-Werte passend auszuwählen.
- Anders als reine technische Fähigkeit lässt sich das nur im komplexen Kontext realer Projekte überprüfen.
- Wenn ein Projekt, in dem eigene Architekturentscheidungen umgesetzt wurden, gut verläuft, kann das ein Hinweis darauf sein, dass der eigene Geschmack passend war.
- Wichtige Lernelemente sind Erfahrungen in verschiedenen Projekten und in bestimmten Momenten eine offene Haltung gegenüber neuen Werten.
- Flexibilität zu bewahren und feste Vorstellungen über bestimmte Technologien oder Methoden zu vermeiden, hilft dabei, guten Geschmack zu entwickeln.
Schlusswort
- Guter Geschmack ist fast so wichtig wie Können und lässt sich im Entwicklungsprozess durch Vielfalt, Flexibilität und Selbstreflexion weiterentwickeln.
- Manche Menschen zeigen einen außergewöhnlich guten Geschmack, der über ihre Erfahrung hinausgeht (etwa Hochbegabte im Programmieren oder in anderen Bereichen).
Weitere Diskussion
- In den Hacker-News-Kommentaren gab es auch skeptische Stimmen, die schon die Existenz von „Geschmack“ infrage stellten.
- Einige behaupteten, für jedes Problem gebe es genau eine richtige Lösung; der Autor entgegnet jedoch, dass in der Realität mehrere Lösungen möglich sind und letztlich persönliche Werte und Kontext die Wahl bestimmen.
- Eine weitere Sichtweise war, dass auch Kunden- und Business-Kontext Teil des Geschmacks sind
7 Kommentare
Es wirkt weniger wie etwas, das man einfach als schlechten Geschmack abtun kann, sondern eher wie eine problematische Neigung, die für Team und Projekt schädlich sein kann.
Hacker-News-Kommentare
Ich habe erlebt, dass unreife Ingenieure dazu neigen, sich zu sehr an ihren eigenen Vorlieben festzubeißen, und dass diese Unreife auch bei erfahrenen Ingenieuren vorkommen kann. Früher, wenn ich Freunden bei Programmieraufgaben an der Uni half, verspürte ich den Drang, den Code komplett neu zu schreiben, nur weil er mir nicht gefiel. Am Ende wurde mir aber klar, dass das viel zu lange dauern würde und meine Freunde das Ergebnis dann nicht mehr verstehen könnten. Also half ich, indem ich nur kleine Anpassungen an ihrem Ansatz vornahm, und damit waren sie zufriedener. Durch solche Erfahrungen habe ich unterschiedliche Sichtweisen kennengelernt, was auch meinen eigenen Code verbessert hat. Eigentlich sollte ich meinen Freunden dafür dankbar sein. Noch heute fällt es mir schwer, Vorurteile abzulegen, aber ich bemühe mich, die Perspektive anderer so ernsthaft wie möglich zu verstehen und manchmal anzuerkennen, dass ihr Ansatz besser ist. Prinzipien sind in Wahrheit ziemlich subjektiv, daher bedeutet es oft nur eine faule Herangehensweise, sich immer nur auf Prinzipien zu stützen, ohne die konkrete Situation ernsthaft zu durchdenken
Auch wenn ein Junior Engineer etwas ineffizient macht, sage ich nie einfach, dass sein Ansatz weniger optimiert ist. Stattdessen frage ich immer, warum er es so gemacht hat. Nach jedem Gespräch hat einer von uns beiden etwas gelernt. Entweder lerne ich einen neuen Ansatz oder ihre Beweggründe kennen, oder sie lernen, warum diese Methode langfristig nicht funktioniert. So oder so enden solche Gespräche nie konfrontativ
Ich denke, „guter Geschmack“ entsteht dadurch, dass man großartige APIs und guten Code erlebt. Guten Code erkennt man sofort, wenn man ihn sieht, und mit der Zeit sollte man auch selbst so schreiben können. Wenn man aber neu in diesem Bereich ist, ist es schwer, einen guten Coding-Geschmack zu entwickeln, und Erfahrung allein führt auch nicht zwangsläufig dazu. Deshalb braucht es die ständige Anstrengung, guten Geschmack zu suchen, zu erkennen und nachzuahmen
Die Lösung, um sich von Vorurteilen, Bias und starren Denkmustern zu lösen, sind Bildung und vielfältige Erfahrungen jenseits der eigenen Perspektive. Nur wenn man aktiv versucht, die Welt aus der Sicht anderer zu verstehen, kann man als Mensch und als Profi wachsen und den eigenen Horizont erweitern. Als Ingenieur, der sich für viele unterschiedliche Bereiche interessiert, verändert schon allein das Wissen, dass es andere Lösungen und Sichtweisen gibt, meine Art, Probleme zu lösen, sodass ich bessere Lösungen finde als meinen ersten intuitiven Ansatz
Deshalb ist es gut, mit verschiedenen Programmiersprachen zu experimentieren. Indem man sich immer wieder auf neue Sprachen einlässt, die die bisherige Sichtweise herausfordern, erlebt man ständig diese „Aha“-Momente. Am Anfang wirkt etwas vielleicht seltsam oder falsch, aber man muss den Prozess akzeptieren, bis man vollständig verstanden hat, warum es so ist und wie es funktioniert
Toller Kommentar. Diese Denkweise wende ich bei Teammitgliedern an, die ich selbst einstelle oder mit denen ich zusammenarbeite. Wenn Ziel oder Ergebnis erreicht werden, müssen mein Vorgehen und meine Detailentscheidungen nicht zwingend exakt übernommen werden. Es gibt viele Wege
Ich denke, „guter Geschmack“ in der Mode besteht nicht so sehr aus jedem einzelnen Kleidungsstück für sich, sondern daraus, dass man Stücke, die für sich genommen kaum Bedeutung zu haben scheinen, zu einem kraftvollen und harmonischen Gesamteindruck kombiniert. Ich hatte gehofft, dass der Artikel in diese Richtung gehen würde. Ich würde gern weiter erkunden, ob das, was Software Engineers nach Geschmack entscheiden, wirklich ein Bereich echten Geschmacks ist und nicht bloß technischer Trade-offs. Ehrlich gesagt wirkt dieser Text selbst wie ein Beispiel für schlechten Geschmack. Inhaltlich sind die einzelnen Teile solide geschrieben, aber insgesamt entsteht kein stimmiger „Look“, wodurch der Text zerstreut wirkt. Das ist nicht als Angriff auf den Autor gemeint; ich halte das Thema für hervorragend und möchte deshalb umso mehr Verbesserungsvorschläge geben
Ich stimme nicht zu, dass ein einzelnes Kleidungsstück an sich bedeutungslos ist. Kleidung trägt schon vor jeder Kombination kulturelle, historische und symbolische Bedeutung. Mode ist mehr als bloßes Kombinieren. Außerdem gibt es auch in der Mode unterschiedliche Trade-offs bei Produktion, Tragen und Zusammenstellung
Deine Frage, „wie wir Schönheit und Eleganz wahrnehmen“, beschäftigt Philosophen seit der Antike und ist viel zu groß, um in einem einzelnen Artikel abschließend behandelt zu werden. Christopher Alexander aus der Architektur hat das tiefgehend untersucht, und seine Ideen haben auch die Softwarearchitektur stark beeinflusst. Alexander vertrat die Auffassung, dass es objektive Schönheit gibt. Empfehlenswert sind seine OOPSLA-Keynote und Roy Fieldings Dissertation. Das im Artikel erwähnte „Wert“-Konzept ist in Fieldings Arbeit systematischer als „Architektureigenschaften“ ausgearbeitet
Interessanterweise halte ich diesen Text für einen seltenen, hervorragend geschriebenen Beitrag, der das Thema tiefgehend und systematisch behandelt
Ich möchte wissen, ab welchem Punkt bei einer bestimmten Kombination für einen Engineer wirklich „Geschmack“ den Ausschlag gibt und worin genau sich dieser „Bereich des Geschmacks“ von bloßen technischen Trade-offs unterscheidet. Meiner Ansicht nach werden viele Entscheidungen unter „technischer Trade-off, aber nicht absolut beweisbar oder mit so geringem Unterschied, dass es praktisch egal ist“ eingeordnet. Mit anderen Worten: Wenn es schwer ist, eindeutig zu urteilen, nennt man es einfach Geschmack
Die meisten Entwickler haben im Allgemeinen wenig Gespür für Mode und verstehen daher auch guten Geschmack im Allgemeinen nicht besonders gut. Und die meisten Dinge in der Tech-Welt wirken auf Nicht-Techies überhaupt nicht schick oder cool. Programmiersprachen sind nicht cool. In der Entwicklerwelt beginnt man schon bei „nicht cool“ und geht von dort weiter nach unten. Zum Beispiel gehören Rust, C++ und Ähnliches in die Kategorie „nicht cool“, während obskure funktionale Sprachen oder Bash, Linux und Ähnliches in die Kategorie „wirklich überhaupt nicht cool“ fallen
Guter Geschmack bedeutet, kraftvoll einfachen Code zu schreiben, den scheinbar jeder hätte schreiben können
Noch ein Beispiel dazu. Beim Zerlegen und Wiederzusammenbauen eines Dodge Challenger von 1972 bin ich immer wieder erstaunt, wie einfach, direkt und günstig dieses Auto erstaunlich gut konstruiert wurde. Zum Beispiel braucht die Stromversorgung der Instrumente 5 Volt getrennt von der Gesamtspannung des Autos (10–18V). Es gibt dafür eine Art Summer, der mithilfe eines Elektromagneten arbeitet: Über 5 Volt öffnet er den Stromkreis, darunter schließt er ihn, sodass durch schnelles Ein- und Ausschalten im Mittel 5 Volt entstehen. Die meisten ersetzen das durch einen elektronischen Spannungsregler, aber dann funktionieren die Instrumente nicht richtig. Tatsächlich sind die Anzeigen mechanisch, und ohne das feine „Rauschen“ dieser 5 Volt bleiben die Nadeln oft hängen; gerade diese „rauen“ 5 Volt verhindern das. Ersetzt man das elektronisch, muss man absichtlich wieder etwas „Rauschen“ hinzufügen. Ich finde es beeindruckend, wie wirkungsvoll und zugleich einfach so ein simples mechanisches Bauteil ist
Der wahre Wert solchen einfachen Codes wird meist nicht angemessen anerkannt, selbst wenn er Wartungskosten oder Arbeitszeit spart. Code, der das KISS-Prinzip (Keep It Simple, Stupid) umsetzt, wird oft sogar abgewertet, weil sein Wert nicht sichtbar genug sei. Deshalb gibt es tatsächlich Teams oder Organisationen, die praktisch nur unnötige Komplexität verwalten
Gelegentlich ist es schön, wenn ein Engineer etwas Außergewöhnliches leisten kann, aber wirklich wichtig ist ein Engineer, der immer wieder gewöhnliche, einfache Lösungen findet, auch wenn sie anfangs schwierig erscheinen
Beim Ballett hört man oft nur: „Das sieht ja ganz leicht aus!“, aber in Wirklichkeit haben die Tänzer es zehntausende Male geübt, damit es tatsächlich leicht aussieht
Ich bewundere immer am meisten Menschen, die etwas Komplexes wirklich einfach zusammenfassen können. So klar wie in den K&R-C-Beispielen, nur bitte mit etwas sorgfältigeren Kommentaren
Die Frage „Lässt sich der Code auf einen Blick verstehen, und ist das Onboarding neuer Engineers einfach?“ ist schwieriger, als man denkt. Es ist unklar, ob mit „neu“ jemand mit 0, 10 oder 30 Jahren Erfahrung gemeint ist. Auch „Lesbarkeit“ ist zwar für manche ein klarer Begriff, in der Praxis aber ein Spektrum von 0 bis unendlich. Maxwells Gleichungen sind für manche völlig klar und für andere komplett undurchsichtig. Deshalb frage ich mich immer, für wen genau der Satz „Code sollte leicht zu lesen sein“ eigentlich gemeint ist
Lesbarer Code bedeutet Code, der Rücksicht auf den Leser nimmt und die kognitive Last minimiert. Darum geht es auch bei geschichteten Abstraktionen und Design Patterns. Natürlich ist das subjektiv, weil es von der Expertise der Zielgruppe und ihrer Vertrautheit mit der Codebasis abhängt. Aber Lesbarkeit allein deshalb zu verwerfen, weil sie subjektiv ist, geht zu weit. Man kann ja auch nicht sagen, Joyces Ulysses und Seuss’ The Cat in the Hat seien gleichermaßen leicht zu lesen
Ich stimme der Behauptung nicht zu, dass „Lesbarkeit kein Konzept“ sei. Unlesbarer Code ist Code, den niemand lesen kann, auch nicht der Autor selbst (oder eine KI). Code, den nur sein Autor lesen kann, ist ebenfalls nicht leicht lesbar
Zu Maxwells Zeiten waren die Gleichungen tatsächlich schwer, aber die Form, in der wir sie heute kennen, ist das Ergebnis späterer Überarbeitungen unter anderem durch Heaviside, die ihre Lesbarkeit verbessert haben
Ich halte die „lokale Lesbarkeit“ einzelner Codefragmente für wenig aussagekräftig. Wenn Muster über die gesamte Codebasis hinweg konsistent angewendet werden, kann der Code insgesamt sehr gut lesbar sein, selbst wenn das Muster für sich genommen etwas komplex ist. Vorübergehende Komplexität ist in Ordnung, solange sie die Gesamtqualität der Codebasis nicht beeinträchtigt
Lesbarkeit dient meist dazu, „accidental complexity“ zu verringern. Selbst mathematische Formeln wie in Drehbüchern oder komplexe Algorithmen werden schwer verständlich, wenn die Notation schlecht ist. Auf die Frage „Für wen sollte Code lesbar sein?“ würde ich antworten: für einen Engineer, der mit dem Problemfeld vertraut ist, den konkreten Code aber noch nicht gesehen hat. Das ist ähnlich wie bei wissenschaftlichen Arbeiten: Sie sollten für die jeweilige Fachgemeinschaft gut lesbar sein. Zusammenfassung von No Silver Bullet
Ich denke, die Metapher „Ein Engineer mit schlechtem Geschmack ist wie ein kaputter Kompass, der am Ende in die falsche Richtung weist“ bringt den Kern gut auf den Punkt. Solche „vorhersehbar kaputten“ Leute kann man im Gespräch oft aussortieren. Gefährlicher ist eher der „teilweise kaputte Kompass“. So jemand wirkt oberflächlich betrachtet fast richtig, liegt in Wahrheit aber immer genau um 127 Grad daneben
Solche Texte vermischen oft zwei Themen. Erstens gibt es objektiv schlechte Entscheidungen, unabhängig von Geschmack oder Prinzipien, etwa O(n)-Suche in einer Liste statt O(1)-Lookup in einem Dictionary. Es gibt technische Fragen mit klaren Vor- und Nachteilen. Zweitens ist alles Übrige ein Trade-off. Ob man map-reduce oder eine normale Schleife verwendet, hängt dann nur noch von Performance, Lesbarkeit, Kompatibilität usw. ab. Wenn es für eine Option Gründe gibt, ist das für mich in Ordnung, auch wenn ich persönlich anders entscheiden würde. Problematisch ist es nur, wenn die Entscheidung schlicht falsch ist oder der Trade-off gar nicht berücksichtigt wurde. Dann ist es eine Frage der Wartung, und je nach Performance oder Häufigkeit muss man vielleicht nicht einmal eingreifen. Solange das „Warum“ einer Entscheidung klar ist, kann ich es akzeptieren. Ob man das wirklich „Geschmack“ nennen sollte, weiß ich nicht
Das Problem dieses Artikels ist, dass er den Punkt „Menschen gewichten unterschiedliche Werte unterschiedlich“ zu kontextlos behandelt. In Wirklichkeit sollte ein Engineer ungefähr erkennen können, welche Werte für ein Problem am wichtigsten sind, also die hard constraints. Die verbleibenden Freiheitsgrade ohne diese hard constraints als „Geschmack“ zu bezeichnen, erscheint mir passend. Bei einem Künstler wäre das der Bereich, in dem neben vorgegebenem Material und Format noch eigene zusätzliche Beschränkungen oder Freiheiten bleiben. Guter Geschmack bei Software Engineers ähnelt für mich dem Streben nach maximaler ästhetischer Minimalität und maximaler Selbstdisziplin. Wirklich „schlechter Geschmack“ ist für mich, wenn jemand ohne jeden Grund gegen Prinzipien verstößt. Oft wurde Einfachheit dabei fälschlich mit bloßer Vertrautheit verwechselt
Der Abschnitt über „Werte“ im Text lässt sich mit den Eigenschaften von Softwarearchitektur in Roy Fieldings Dissertation verbinden. Fieldings Arbeit ist zwar vor allem wegen REST bekannt, behandelt in Wirklichkeit aber Softwarearchitektur viel breiter und solider. Sie hilft dabei, im Kontext verschiedener „Architektureigenschaften“ wie Skalierbarkeit, Lesbarkeit und Wartbarkeit zu denken, und ich möchte persönlich noch betonen, wie wichtig es ist, zusätzlich auch „Architekturbeschränkungen“ zu verstehen
Solides Engineering (Principled Engineering) sollte selbstverständlich sein. Darauf aufbauend kann man guten oder schlechten Geschmack haben. Umgekehrt gilt das aber nicht. Wenn schon das Engineering schlecht ist, ist Geschmack bedeutungslos. Schlechter Geschmack kann die Wirksamkeit von Engineering beeinträchtigen, macht Engineering an sich aber nicht unmöglich. Engineering dient grundsätzlich dazu, Geschmack zu tragen. Etwas kann zum Beispiel perfekt konstruiert sein und trotzdem bedeutungslos, wenn es niemand braucht oder will
Schlechter Geschmack führt uns am Ende in ungewisse Zustände, die wir eigentlich vermeiden wollen. Für mich bedeutet guter Geschmack letztlich, eine Codebasis so vorzubereiten, dass sie eine robuste Grundlage und Sicherheitsmechanismen für die Unsicherheiten der Zukunft besitzt. So gerät man nicht in Gefahr
Wirklich gut
Das Original ist gut, aber auch der Inhalt der Kommentare ist wirklich großartig.
Wenn ich an Geschmack denke, muss ich an Torvalds’ TED-Video denken:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
Ab 14:20: guter Geschmack, betrachtet anhand der Implementierungsweise von Code zum Entfernen eines Eintrags aus einer linked list
Sogar bei in Hacker-News-Kommentaren erwähnten „objektiv schlechten Entscheidungen“ (z. B. O(n)-Suche in einer Liste vs. O(1)-Suche mit einem Dictionary) kann je nach Kontext eine andere Entscheidung sinnvoll sein.
Wenn die Abfrage nur ein einziges Mal erfolgt, können die Kosten für das Erstellen einer Hash-Tabelle höher sein als eine O(n)-Suche in einer Liste.
Guter Kommentar.