it-swarm-eu.dev

Warum wird Klugheit von manchen Leuten beim Programmieren als schädlich angesehen?

Ich habe in letzter Zeit viele Fragen zu verschiedenen Abstraktionstechniken bemerkt und Antworten, die im Grunde sagen, dass die fraglichen Techniken "zu klug" sind. Ich würde denken, dass ein Teil unserer Arbeit als Programmierer darin besteht, die besten Lösungen für die Probleme zu finden, die wir lösen müssen, und Klugheit ist dabei hilfreich.

Meine Frage lautet also: Sind die Leute, die bestimmte Abstraktionstechniken für zu klug halten, der Klugheit per se entgegengesetzt, oder gibt es einen anderen Grund für den Einwand?

EDIT: Dieser Parser-Kombinator ist ein Beispiel für das, was ich als cleveren Code betrachten würde. Ich habe das heruntergeladen und es ungefähr eine halbe Stunde lang durchgesehen. Dann ging ich durch die Makroerweiterung auf Papier und sah das Licht. Jetzt, wo ich es verstehe, wirkt es viel eleganter als der Haskell-Parser-Kombinator.

89
Larry Coleman

Einfache Lösungen sind besser für die langfristige Wartung. Und es geht nicht immer nur um Sprachvertrautheit. Eine komplexe Linie (oder Linien) braucht Zeit, um herauszufinden, selbst wenn Sie ein Experte in der angegebenen Sprache sind. Sie öffnen eine Datei und beginnen zu lesen: "ok, einfach, einfach, verstanden, ja, WTF?!" Ihr Gehirn kommt kreischend zum Stillstand und Sie müssen jetzt anhalten und eine komplizierte Linie entschlüsseln. Sofern es keinen messbaren, konkreten Grund für diese Implementierung gab, ist sie "zu klug".

Herauszufinden, was los ist, wird immer schwieriger, wenn die Komplexität von einer cleveren Methode über eine clevere Klasse zu einem cleveren Muster wächst. Abgesehen von bekannten Ansätzen muss man den Denkprozess herausfinden, der zur Schaffung einer "cleveren" Lösung geführt hat, was ziemlich schwierig sein kann.

Trotzdem hasse ich es, ein Muster zu vermeiden (wenn seine Verwendung gerechtfertigt ist), nur weil jemand es möglicherweise nicht versteht. Es liegt an uns als Entwicklern, weiter zu lernen, und wenn wir etwas nicht verstehen, ist es ein Grund, es zu lernen, nicht zu vermeiden.

207
Adam Lear

KISS-Prinzip

Halten Sie es einfach blöd. Clevere Lösungen sind großartig, aber oft ist die einfachste direkte Lösung die beste.

„Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code so geschickt wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen. “

Brian Kernighan

102
Josh K

Dummköpfe ignorieren die Komplexität; Pragmatiker leiden darunter; Experten vermeiden es; Genies entfernen es. - Alan Perlis

83
Martijn Verburg

Die beste Lösung ist nicht immer die klügste. Manchmal sind einfache Lösungen gleich gut.

In Software müssen Sie immer an die Wartbarkeit denken. Wenn ein Code für jemanden, der ihn pflegen wird, zu clever ist, würde ich sagen, dass Cleverness es nicht wert ist.

30
Geek

Um Brian Kernighan zu zitieren:

"Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code daher so geschickt wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen."

26
peterchen

klugheit ist ein Werkzeug; an sich ist es nicht schädlich. Es wird nur dann schädlich, wenn es nicht notwendig ist.

22
Steven A. Lowe

"Clever" ist, wenn es auf Code angewendet wird, fast immer nur ein Euphemismus für "unnötig kompliziert".

Es ist schwer genug, guten, klaren und einfachen Code zu lesen. Das Lesen von "cleverem" Code ist wie ein erneutes Studium der lateinischen Poesie.

Die Verwirrung entsteht, weil "klug" als Attribut einer Person eine ganz andere Bedeutung hat. Dieser Fall kann auch als Beispiel dafür angesehen werden, warum das Entwerfen von Software für echte Menschen schwierig ist: Weil sie nicht eindeutig sind.

Und weil einige Programmierer die sozialen Protokolle verstehen, denen die meisten Menschen folgen und die es ihnen verbieten, Code direkt als "unnötig kompliziert" anzuprangern, fällt es ihnen möglicherweise schwer, zwischen den beiden Bedeutungen des Wortes zu unterscheiden clever. Im Gegensatz zu dem, was manche vielleicht denken, denke ich, dass letztendlich bessere "Personen" (dh Menschen mit Empathie, Selbstbeobachtung und Geduld) bessere Entwickler sind. Weil sie wissen, für wen sie schreiben müssen.

16
fzwo

Die meisten Leute konzentrieren sich auf die Klugheit unter dem Aspekt "Der Code erfordert zu viel Entschlüsselung, um herauszufinden, was er tut" und all die schlechten Dinge, die damit einhergehen, wie z

  1. Niemand sonst kann es herausfinden, geschweige denn warten/debuggen.
  2. Die Person, die geschrieben hat, weiß nicht einmal, was es tut.
  3. Es mag tatsächlich gar nicht so brillant sein
  4. usw....

Alles gute Punkte, aber es gibt noch einen weiteren negativen Aspekt der Klugheit, und das ist das alte Ego-Problem. Dies verursacht Probleme in der Art von

  1. Jemand, der zu "klug" ist, um die Lösungen anderer zu verwenden. Warum nach dem suchen, was andere Leute getan haben, wenn Sie Ihre eigene Art erfinden können, dieselbe Katze zu häuten?
  2. Jemand, der glaubt, die coolste Lösung für ein Problem erfunden zu haben, wird sich oft weigern, Eingaben zu machen.
  3. Niemand darf "seinen" Code ändern, selbst wenn offensichtliche Probleme vorliegen oder eine geringfügige Änderung erforderlich ist.
  4. Umgekehrt denken sie, dass sie klug sind und die "neueste" Technik verwenden müssen, um zu beweisen, wie klug sie sind, aber sie können es weder in persönlichen Projekten noch in anderem nicht produktionsbezogenen Code gut in den Griff bekommen, bevor sie es in kritische Teile von rollen das System.

Wir sind alle manchmal zu viel Ego schuldig, aber wenn es dem Team im Weg steht, ist es ein Problem.

9
MIA

Good Clever - hohes Verhältnis zwischen cleveren Codezeilen und Zeilen von in einer nicht cleveren Alternative. 20 Codezeilen, die Sie vor dem Schreiben von 20000 bewahren, sind extrem gut clever. Bei Good Clever geht es darum, sich Arbeit zu sparen.

Bad Clever - geringes Verhältnis zwischen geschriebenen Codezeilen und gespeicherten Codezeilen. Eine clevere Codezeile, die Sie vor dem Schreiben von fünf Codezeilen bewahrt, ist Bad Clever. Bei Bad Clever geht es um "syntaktische Masturbation".

Nur zur Anmerkung: Bad Clever wird fast nie "Bad Clever" genannt; es wird oft unter den Decknamen "schön", "elegant", "prägnant" oder "prägnant" reisen.

8
user8865

Ich muss mich fragen, wie jeder klug definiert.

Persönlich fühle ich mich schlau, wenn ich ein schwieriges, komplexes Problem auf sehr einfache und unkomplizierte Weise umgesetzt und dabei ein akzeptables Maß an Effizienz beibehalten habe.

ich fühle mich schlau, wenn mein Rezensent während einer Codeüberprüfung sagt "Wow, das war einfacher als ich dachte", im Gegensatz zu "wtf ist das alles ..."

7
Avatar_Squadron

Manchmal war ich so schlau, dass ich mich geirrt habe.

6
John

Abgesehen von den aufgeführten theoretischen Antworten wird dies häufig im Zusammenhang mit zu klug für alle anderen verwendet.

Wechseln Sie irgendwann zwischen einem leistungsintensiven Team der Spitzenklasse und einem Wartungsteam der mittleren Ebene, um die tatsächlichen Unterschiede im Bereich "zu clever" zu erkennen.

Wenn man die theoretischen Argumente weglässt, basiert zu klug oft darauf, mit was die am wenigsten qualifizierten Teammitglieder vernünftigerweise arbeiten können, daher ist es sehr relativ zur Umgebung.

6
Bill

Performant, wartbar, zeitnah und kostengünstig sind die Methoden, mit denen ich eine Lösung messe. Ich denke, clever könnte auch Teil einer Lösung sein, solange es diese Eigenschaften nicht negativ beeinflusst.

4
Heath Lilley

Wenn cleverer Code + die Anzahl der Kommentare, die erforderlich sind, um ihn verständlich zu machen, <= einfacher Code, dann sage ich, entscheiden Sie sich für den cleveren Code. Jedes Mal.

Ich denke, das Problem entsteht, wenn Leute, die "cleveren Code" schreiben, ihn absichtlich nicht richtig kommentieren, weil zukünftige Generationen, die darauf stoßen, Zeit damit verbringen müssen, zu "schätzen", wie clever er ist.

3
thesunneversets

Ich erinnere mich an ein Zitat, das ich vielen verschiedenen Menschen zugeschrieben habe, wie es die guten Zitate oft sind.

Umschreiben:

Jeder intelligente Mensch kann den einfachen Komplex machen, es braucht ein Genie, um den Komplex einfach zu machen.

Eine komplexe Idee zu nehmen und sie so zu vereinfachen, dass sie verständlich ist, zeigt die Klugheit des Konstruktors, aber eine einfache Idee zu nehmen und sie komplex zu machen, zeigt, dass der Konstruktor als klug angesehen werden möchte.

3
Pickle Pumper

Meiner Meinung nach ist Klugheit an sich kein Problem. Normalerweise können wir Verwirrungen über "cleveren" (ohne Sarkasmus) und "aufschlussreichen" Code machen. Was ich als Problem sehe, ist die Tatsache, dass der "clevere" Code (mit Sarkasmus) normalerweise implizite, nicht sichtbare Anforderungen enthält, was das Debuggen und Verwalten im Laufe der Zeit erschwert.

Es gibt mehrere bekannte Algorithmen, die clever sind. Quicksort ist eins, IMO.

"Cleverer" (mit Sarkasmus) Code macht normalerweise Annahmen über gesetzte Variablen und Zustände des Systems, die praktisch vom "cleveren" Code getrennt sind (wie zuvor geöffnete Dateien, Netzwerkverbindungen, Datenbanken usw.).

Die Datenmenge, die Sie in Ihr Gehirn laden müssen, um einen "cleveren" Code korrekt zu verwalten, ist normalerweise zu groß, um ein gutes Kosten-Nutzen-Verhältnis zu erzielen.

2
Machado

Wenn die "clevere" Lösung schwer herauszufinden ist, sollte sie nicht verwendet werden. Wenn Sie beispielsweise durch Nebenwirkungen eine komplexe Berechnung auf eine Zeile beschränken können, ist dies clever. Aber wenn jemand eine Stunde braucht, um herauszufinden, was in aller Welt Sie getan haben, ist es zu klug.

2
Michael K

Ich kenne einen Mann; Er ist wahrscheinlich der brillanteste Mensch, den ich je getroffen habe. Er ist definitiv ein unglaublicher Programmierer, wahrscheinlich besser als ich es jemals in meinem ganzen Leben sein werde, was reine Programmierkünste angeht. Er schreibt Code, als würde er ein Word-Dokument eingeben, und kann eine verknüpfte Liste umkehren, wie Sie es nicht glauben würden. Wenn Sie über das Schreiben eines ernsthaft komplexen Codes sprechen möchten, ist er Ihr Mann, und wenn ich auf ein unglaublich schweres Problem stoße, wende ich mich immer an ihn. Es ist jedoch unerträglich, mit ihm in einem Team an einem Projekt zu arbeiten. Er ist nicht in der Lage, das Geschäftsproblem direkt anzugehen und eine logische, effiziente und präzise Lösung dafür zu finden. Für ihn wäre eine Codeliste mit 1000 Zeilen besser als 100. Anstatt die ihm über das IDE oder Framework) zur Verfügung gestellten Tools zu verwenden, wird er sein eigenes superoptimiertes Tool rollen Alles schön und gut, außer wenn andere Teammitglieder darauf warten, dass er etwas erledigt, oder wir eine Frist haben.

Während ich seine Fähigkeit bewundere, diese komplexen Dinge zu tun, brauche ich jemanden, der das Problem lösen und weitermachen kann. Es ist nicht großartig zu sagen oder zuzugeben, aber manchmal ist in einem Geschäftsumfeld die Zeit alles und Sie müssen nur das Problem lösen und mit Ihrem Leben weitermachen. Sie können später immer wieder darauf zurückkommen und es verdammt noch mal umgestalten, um es zu verbessern dein Code. Es gibt eine feine Linie zwischen klug sein und auch ein Schmerz im Hintern sein. Mein Motto für mein Team ist immer, was in dieser Situation so einfach wie möglich ist und dann von dort aus weitergeht. Manchmal ist einfacher nicht immer die Antwort, aber es ist ein verdammt guter Anfang.

1

"Clever" bedeutet in diesem Zusammenhang "zu klug für das eigene Wohl", d. H. Etwas, das jetzt funktioniert, aber ein Albtraum sein wird, um es später zu verstehen und zu ändern.

Vor allem, wenn es sich um einen Trick handelt, der eine dunkle Funktion der Programmiersprache ausnutzt, seltsame Nebenwirkungen nutzt oder eine wirklich bizarre Methode zur Lösung des Problems in der Zielsprache darstellt.

1
Andres F.

Denn was wie Klugheit für einen Entwickler in einem Ausbruch von Kreativität aussieht, kann einfach als Chaos übergeben werden und einfach ein nlesbar, nicht wartbar) sein Block von obskure Rätsel für andere.

Trotzdem ein netter, kluger und leistungsfähiger Rätselblock, aber wenn Sie die Erfahrung haben, werden Sie oft feststellen, dass es Ihr Unternehmen (nicht Sie, den Entwickler) viel mehr kostet, dieses Ding auf dem Medium zu halten. oder langfristig. Sie ziehen es also vor, die Begeisterung Ihrer Entwicklerkollegen zu beruhigen, wenn sie getragen werden.

Außer natürlich, wenn es eine Rechtfertigung für die Klugheit gibt. Und wenn es eine gute Dokumentation gibt, die mit der verschleierten Sache einhergeht, die Sie gerade geschrieben haben. Sie haben diesen cleveren Code kommentiert, richtig? Erklären Sie die Absicht, warum es so sein muss und wie es sich verhält?

Wenn es keine Rechtfertigung gibt, handelt es sich wahrscheinlich nur um vorzeitige Optimierung, Überentwicklung oder ein YAGNI-Problem. Wenn 15 Indirektionsebenen erforderlich sind, um etwas Einfaches zu tun, besteht eine gute Chance, dass Sie auch unter die vorherigen Kategorien fallen. Und wenn es nicht dokumentiert ist, dann ist es nur Ärger.

Bei großartigem Code sollte der Betreuer nicht immer zu 100% auf dem neuesten Stand sein, um ihn zu verstehen. Guter Code ist klug. Großartiger Code kann fast genauso effizient sein, aber in vielen anderen Aspekten besser. Für großartigen Code sollte kein IDE mit 15 Ansichten) erforderlich sein, um dem Design Ihrer Anwendung zu folgen.

Anmerkung: Hey, ich habe ein paar Sachen geschrieben, die ich für schlau hielt, aber das hat WTF aus dem Mund meines Managers gezogen - wenn nicht aus dem meiner Manager. Ich muss es aus ihrer Perspektive betrachten.

1
haylem

Ich neige dazu, klug zu sein, aber ich bemühe mich, elegant zu sein.

Entwickle Code jetzt, den andere nicht vermeiden wollen später.

1
kevpie

"Cleverer Code" ist jeder Code, für den der Programmierer wirklich nachdenken oder fortgeschrittene Fähigkeiten einsetzen musste, um ihn zu schreiben. Das Problem dabei ist, dass die Notwendigkeit einer gewissen "Klugheitsspanne" außer Acht gelassen wird, die am besten von Brian W. Kernighan ausgedrückt wird:

"Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code daher so geschickt wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen."

1
Alex

Dies ist mein Verständnis des Problems, basierend auf meiner Erfahrung und den anderen Antworten:

  1. Code, dessen Schreiben klug war, der jedoch lesbar und wartbar ist, wird nicht als schädlich angesehen. Die meisten Entwickler würden diese Art von Code jedoch nicht als "clever" bezeichnen. Sie können einen anderen Begriff wie "elegant" verwenden. Es kann eine Debatte darüber geben, ob ein solcher Code existiert oder nicht.
  2. Produktionscode, dessen Verständnis selbst von einem erfahrenen Entwickler, der mit der Sprache vertraut ist, viel Zeit und Mühe erfordert, ist "clever" und wird von allen als schädlich angesehen.
  3. Produktionscode, der von unerfahrenen Entwicklern viel Zeit und Mühe erfordert, wird von einigen als schädlich angesehen. Ich habe so oder so Antworten gesehen und mit Entwicklern zusammengearbeitet, die ausdrücklich gesagt haben, dass sie es vorziehen würden, alles auf dem "kleinsten gemeinsamen Nenner" zu halten.
1
Larry Coleman

Wenn Sie "clever" sein müssen, können Sie normalerweise ein Problem im Code umgehen. Wenn dies eine Problemumgehung ist und nicht sehr einfach ist, treten bei Annahme bestimmter Bedingungen (die zum Zeitpunkt des Schreibens des Codes möglicherweise zu 100% korrekt sind) viele verwirrte Gesichter oder andere seltsame Nebenwirkungen auf.

So clever == verwirrend == schlecht :( Aber es ist auch großartig, da ich sie für praktische Lösungen für begrenzte Probleme verwendet habe.

0
user2528

Ich bevorzuge einfache Lösungen, ich mag den Weg Ruby. Wenn Sie zum Beispiel zuerst 2 Elemente in der Liste summieren möchten. Zuerst schneiden Sie die Liste so, dass sie Größe = 2 hat, und dann Sie summiere es.

Ich erinnere mich, dass ich einmal 1 Liste anstelle von 3 verwendet und eine große Funktion erstellt habe, die sehr schwer zu warten/zu ändern war.

in der heutigen Welt müssen wir die Code-Klarheit nicht für die Leistung opfern (außer c ++ müssen sie nicht, aber sie werden).

0
IAdapter

Für den Kontext und das leichtere Verständnis neu zitieren:

"Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code daher so geschickt wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen."

Was Brian Kernighan hier schrieb, bezieht sich offensichtlich auf Faltung, und er benutzte fälschlicherweise das Wort klug.

"Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie den Code daher so [verschlungen] wie möglich schreiben, sind Sie per Definition nicht klug genug, um ihn zu debuggen."

Faltung:

A thing that is complex and difficult to follow.

Klug:

Showing intelligence or skill; ingenious

Gebildete Programmierer wissen, dass einfacher Code genial ist. Code, der so clever wie möglich ist, sollte per Definition einfach sein. Gebildete Programmierer vermeiden es auch, mit verschlungenem Code wie der Pest zu arbeiten und ihn zu schreiben. Sie werden auch verschlungenen Code in cleveren Code verwandeln, wann immer sie die Chance dazu haben. Code beginnt normalerweise verschlungen und nähert sich der Klugheit, da das Wissen über den Bereich und das Verständnis der menschlichen kognitiven Fähigkeiten beim Programmieren durch Erfahrung und gemeinsames Wissen besser verstanden wird.

Aufgrund der Popularität dieses Zitats und der Tatsache, dass Brian Kernighan in der Branche sehr beliebt ist, hat dieser Missbrauch des Wortes negative soziale Auswirkungen, und ich würde es ehrlich sehen, wenn der Mann selbst darauf eingeht. Bevor ich diesen Artikel schrieb, versuchte ich zu sehen, ob ich ihm einfach eine E-Mail senden konnte, aber ich konnte keine E-Mail-Kontaktinformationen finden, die ich verstand :(.

Die negativen sozialen Auswirkungen, die ich gesehen habe, sind andere Programmierer, die ihre klügeren Kollegen ausschließen, weil sie Klugheit jetzt als Problem ansehen. Das eigentliche Problem sind die dummen Kollegen, die glauben, sie seien schlau, indem sie Dinge auf eine neue, unidiomatische Weise tun und ständig neue Dinge erfinden, wenn es keinen Vorteil gibt, anstatt die größere Gemeinschaft zu gewinnen und zu verstehen und kluge Ideen so weit wie möglich wiederzuverwenden.

Ich muss jedoch klarstellen, dass es oft schwieriger ist, ein Verständnis zu erlangen, als ein eigenes zu erfinden. Aufgrund des in der Industrie häufig auftretenden Problems unrealistischer Fristen wird es Zeit sparen, eigene für Ihr kleineres Nischenproblem zu erfinden. Dies basiert auf der Beobachtung, dass nützliche, wiederverwendbare Dinge normalerweise auf eine größere Nische abzielen oder eine nützliche Abstraktion für Erfindungen darstellen. Es basiert auch auf der Tatsache , dass Menschen auf große Nischen abzielen, um mehr Geld zu verdienen, wenn dies häufig die Verwendung des Tools aufgrund der Komplexität extrem schwierig macht etwas für einen weiten Bereich von Anwendungen nutzbar zu machen.

Die andere negative soziale Auswirkung ist, dass dies den Fortschritt und den Wunsch nach Verständnis verhindert, weil wir in unserer egozentrischen Welt sofort unseren eigenen Mangel an Verständnis leugnen und den Code als verschlungen abschreiben werden, selbst wenn die Idee, sobald sie verstanden wurde, tatsächlich ist ziemlich schlau.

TODO Ich möchte einige Referenzen zitieren, aber ich möchte auch, dass das Fehlen von Referenzen meine Fähigkeit, Informationen zu teilen, nicht beeinträchtigt, sodass ich schnell das zitieren kann, woran ich mich als Quellen meiner Informationen erinnere, und vielleicht die tatsächlichen Informationen finden werde Tag (oder du kannst es für mich finden! :)

  • Guido Van Rossums Vortrag über Event-Loops und wie er sie verstand
  • Ein GitHub-Mitarbeiter, der erklärte, er vermeide es, kluge Leute für Y-Combinator einzustellen
  • Ein Großteil der Diskussionen und des Lernens, die in der Python Community) stattfinden. Die Python Community) steht neuen Ideen besonders kritisch gegenüber, lehnt jedoch neue Ideen nicht ab nicht aus der Hand zu verstehen, und Sie können in der Regel Funktionen sehen, die zunächst als verschlungen angesehen wurden, und das Tageslicht als Kernsprachenfunktion/-paket sehen.
  • Meine eigene Erfahrung und berufliche Meinung basiert auf meinen 10000 Fuß-Beobachtungen. Ich kann die Einzelheiten, die von dort oben aufgeklärt werden müssen, nicht wirklich erkennen :( Hoffentlich werden Ihre Erfahrungen und Beobachtungen Ihnen dasselbe sagen, und jemand anderes kann unten einen Kommentar abgeben, um dieser Antwort einen gewissen Wert zu geben.

Fühlen Sie sich frei, Ihre eigenen Zitate hinzuzufügen! Sie können meinem Text auch Kommas hinzufügen. Ich habe meine Kenntnisse über die Verwendung von Kommas in Englisch seit einiger Zeit nicht mehr aktualisiert ...

0
Derek Litz