Wie gehe ich mit Missverständnissen über „vorzeitige Optimierung ist die Wurzel allen Übels“ um?

26

Ich habe viele Leute getroffen, die dogmatisch gegen alles sind, was man als "Optimierung" im allgemeinen englischen Sinne des Wortes bezeichnen kann, und sie zitieren sehr oft wörtlich das (teilweise) Zitat "vorzeitige Optimierung ist die Wurzel allen Übels". als Rechtfertigung für ihre Haltung implizieren sie, dass sie alles, wovon ich spreche, als "vorzeitige Optimierung" interpretieren. Diese Ansichten sind jedoch manchmal so lächerlich verwurzelt, dass sie so ziemlich jede Art von algorithmischen oder Datenstrukturabweichungen von der rein "naiven" Implementierung ausschließen ... oder zumindest jegliche Abweichungen von der Art und Weise, wie sie die Dinge zuvor getan haben.Wie kann man sich solchen Menschen nähern, um sie dazu zu bringen, "die Ohren wieder zu öffnen", nachdem sie nicht mehr von "Leistung" oder "Optimierung" gehört haben? Wie diskutiere ich ein Design- / Implementierungsthema, das sich auf die Leistung auswirkt, ohne dass die Leute sofort darüber nachdenken: "Dieser Typ möchte zwei Wochen mit zehn Codezeilen verbringen?"

Die Frage, ob "alle Optimierungen verfrüht und daher böse sind" oder nicht, wurde hier und in anderen Bereichen des Web bereits behandelt, und es wurde bereits diskutiert, wie man erkennt, wann Optimierung verfrüht und daher böse ist , aber Leider gibt es immer noch Menschen in der realen Welt, die nicht ganz so offen für Herausforderungen sind, die ihren Glauben an Anti-Optimierung in Frage stellen.

Bisherige Versuche

Einige Male habe ich versucht, das komplette Zitat von Donald Knuth zu liefern, um zu erklären, dass "vorzeitige Optimierung schlecht ist" - "alle Optimierung ist schlecht":

Wir sollten kleine Wirkungsgrade vergessen, sagen wir in 97% der Fälle: Vorzeitige Optimierung ist die Wurzel allen Übels. Dennoch sollten wir unsere Chancen bei diesen kritischen 3% nicht verpassen.

Wenn ich jedoch das gesamte Zitat vorlege, sind diese Leute manchmal sogar mehr davon überzeugt, dass ich Premature Optimization ™ mache, und greifen ein und lehnen es ab, zuzuhören. Es ist fast so, als ob das Wort "Optimierung" sie erschreckt: Bei einigen Gelegenheiten konnte ich tatsächliche leistungsverbessernde Codeänderungen vorschlagen, ohne dass sie ein Veto einlegten, indem einfach die Verwendung des Wortes "optimiz (e | ation)" vermieden wurde ( und "Leistung" auch - dieses Wort ist auch beängstigend) und verwendet stattdessen einen Ausdruck wie "alternative Architektur" oder "verbesserte Implementierung". Aus diesem Grund scheint es wirklich so, als ob dies wirklich Dogmatismus ist und nicht sie, die das, was ich sage, kritisch bewerten und es dann als nicht notwendig und / oder zu teuer abtun.

irrantlinguist
quelle
10
Nun, als Sie das letzte Mal eine solche Diskussion hatten, haben Sie wirklich gemessen, dass die Leistung durch die reinste, naive Implementierung schlecht sein würde? Oder zumindest eine grobe Schätzung der erwarteten Laufzeit? Wenn nicht, hätten diese anderen Leute mit ihrer Meinung völlig richtig liegen können, haben Sie keine Möglichkeit, es zu wissen.
Doc Brown
12
@errantlinguist: Wenn das Programm wirklich "langsam wie Melasse" ist, dann sollten Sie eindeutig in der Lage sein, Knuths "diese kritischen 3%" leicht zu erkennen und daher alle Argumente gegen eine Optimierung zu übertreffen. Und wenn Sie das nicht erkennen können ... dann haben Sie Ihre Hausaufgaben noch nicht gemacht und sind noch nicht bereit zu optimieren. Es ist also nicht klar, wo das Problem liegt.
Nicol Bolas
6
@errantlinguist: Wenn Sie den Nachweis erbracht haben, dass dieser Codeabschnitt ein erhebliches Leistungsproblem für die Anwendung darstellt und die Anwendung insgesamt langsamer ist als erforderlich, und die Notwendigkeit, den Code zu ändern, weiterhin abgelehnt wurde, ist dies nicht der Fall. ' t egal. Sie haben es mit Menschen zu tun, die für evidenzbasiertes Denken undurchlässig und somit unvernünftig sind.
Nicol Bolas
6
@errantlinguist: Die Schlüsselfrage: Haben sich Kunden beschwert, dass die Anwendung in diesem Bereich langsam war?
Gort the Robot
5
Ich stimme für den Abschluss, da OP eindeutig nur nach jemandem sucht, der eine Meinung bestätigt, und nicht nach einer Antwort auf eine tatsächliche Frage. Ich denke nicht, dass dies auf Workplace.SE offen bleiben würde (oder sollte).
BlueRaja - Danny Pflughoeft

Antworten:

35

Anscheinend suchen Sie nach Abkürzungen, um die "reinste naive Implementierung" nicht zuerst auszuprobieren und direkt eine "komplexere Lösung zu implementieren, da Sie im Voraus wissen, dass die naive Implementierung dies nicht tun wird". Leider wird dies selten funktionieren - wenn Sie keine Fakten oder technischen Argumente haben, die belegen, dass die naive Implementierung zu langsam ist oder sein wird, liegen Sie höchstwahrscheinlich falsch, und was Sie tun, ist eine vorzeitige Optimierung. Und mit Knuth zu streiten ist das Gegenteil von einer harten Tatsache.

Nach meiner Erfahrung müssen Sie entweder zuerst in die Kugel beißen und die "naive Implementierung" ausprobieren (und werden wahrscheinlich erstaunt sein, wie oft dies schnell genug ist), oder Sie werden zumindest eine grobe Schätzung der Laufzeit vornehmen, wie z.

„Die naive Implementierung O (n³) sein, und n ist größer als 100.000, das einige Tage laufen wird, während die nicht-so-naive Implementierung wird in O (n) läuft, die nur wenige Minuten in Anspruch nehmen“ .

Nur mit solchen Argumenten können Sie sicher sein, dass Ihre Optimierung nicht verfrüht ist.

Hiervon gibt es meiner Meinung nach nur eine Ausnahme : Wenn die schnellere Lösung auch die einfachere und sauberere ist, sollten Sie von Anfang an die schnellere Lösung verwenden. Das Standardbeispiel ist die Verwendung eines Wörterbuchs anstelle einer Liste, um unnötigen Schleifencode für Suchvorgänge zu vermeiden, oder die Verwendung einer guten SQL-Abfrage, mit der Sie genau den einen Ergebnisdatensatz erhalten, den Sie benötigen, anstelle einer großen Ergebnismenge, die benötigt wird danach im Code gefiltert. Wenn Sie einen solchen Fall haben, streiten Sie nicht über die Leistung- Die Aufführung könnte ein zusätzlicher, aber höchstwahrscheinlich irrelevanter Vorteil sein, und wenn Sie ihn erwähnen, könnten die Leute versucht sein, Knuth gegen Sie einzusetzen. Streiten Sie über Lesbarkeit, kürzeren Code, saubereren Code, Wartbarkeit - Sie müssen hier nichts "maskieren", sondern weil dies (und nur das) die richtigen Argumente sind.

Nach meiner Erfahrung ist der letztere Fall selten - der typischere Fall ist, dass man zuerst eine einfache, naive Lösung implementieren kann, die verständlicher und weniger fehleranfällig ist als eine kompliziertere, aber wahrscheinlich schnellere.

Und natürlich sollten Sie die Anforderungen und den Anwendungsfall gut genug kennen, um zu wissen, welche Leistung akzeptabel ist und wann die Dinge in den Augen Ihrer Benutzer "zu langsam" werden. In einer idealen Welt würden Sie von Ihrem Kunden eine formelle Leistungsspezifikation erhalten, aber in realen Projekten ist die erforderliche Leistung häufig eine Grauzone, was Ihre Benutzer Ihnen nur mitteilen, wenn sie feststellen, dass sich das Programm in der Produktion "zu langsam" verhält. Und oft ist dies die einzige Möglichkeit, um herauszufinden, ob etwas zu langsam ist - das Feedback der Benutzer, und dann müssen Sie Knuth nicht zitieren, um Ihre Teamkollegen davon zu überzeugen, dass ihre "naive Implementierung" nicht ausreichend war.

Doc Brown
quelle
15
@errantlinguist: vielleicht habe ich mich nicht klar ausgedrückt, oder ist es einfach nicht das, was ich hören wollte? Mein Rat ist: Versuchen Sie nicht, * philosophische Argumente "von Knuth über" 3% "oder" 97% "zu verwenden. Halten Sie es sachlich, sonst haben Ihre Kollegen höchstwahrscheinlich Recht, dass Ihre Leistungsargumente unangemessen sind.
Doc Brown
4
@errantlinguist: In dem Fall, den Sie in Ihrem Kommentar zu Karl Bielefelds Antwort beschrieben haben, scheinen Sie alle Argumente auf Ihrer Seite zu haben, ohne die "Leistung" verwenden zu müssen. Ich würde noch einen Schritt weiter gehen und sagen, wenn Sie in einem solchen Fall über die Leistung streiten, machen Sie einen gewaltigen Fehler, weil Ihre Kollegen Recht haben: Leistung spielt dort normalerweise keine Rolle. Streiten Sie über Einfachheit, Lesbarkeit, Wartbarkeit, weniger Codezeilen, aber nicht (!) Über Leistung, auch nicht als Randnotiz. Bieten Sie ihnen nicht die Möglichkeit, Knuth gegen Sie einzusetzen.
Doc Brown
2
@errantlinguist: nicht begraben - rücken Sie diese Aspekte in den Fokus, wenn es richtig ist, dass diese Aspekte im Fokus stehen, und verwenden Sie die Leistung nicht als Argument, wenn Sie nicht beweisen können, dass sie einen wichtigen Unterschied für den Endbenutzer darstellt.
Doc Brown
2
@errantlinguist: Ich bin mir nicht sicher, wie Sie zu dieser Schlussfolgerung kommen. Die Antwort von Doc Brown scheint völlig klar zu sein: Sie haben diese unproduktiven Argumente, die Sie mit Ihren Kollegen haben, vermieden, indem Sie sich an sachliche Aussagen darüber gehalten haben, was akzeptable Leistung ist und was nicht.
jl6
1
Dies ist ein guter Rat für das Programmieren im Kleinen, aber das Ignorieren von Leistungsfragen auf der Ebene des Architekturdesigns kann ein Team in eine lange Sackgasse führen, da es möglicherweise viel erledigen kann, bevor es gezwungen ist, sich dem Problem zu stellen. und es gibt keine Garantie, dass ein Großteil dieser Arbeit wiederverwendbar ist, wenn das Problem architektonisch ist (ich habe gesehen, dass es ein Produkt tötet). Ich weiß, dass Sie eine Ausnahme in Ihrer Antwort haben, aber um zu wissen, ob es zutrifft, müssen Sie die Frage noch stellen und sogar die Frage zu stellen, ist offenbar ein Gräuel für die Mitarbeiter von errantlinguist.
Sdenham
18

Fragen Sie sich folgendes:

  • Entspricht die Software NICHT den Leistungsspezifikationen?
  • Hat die Software ein Leistungsproblem?

Dies sind Gründe zur Optimierung. Wenn die Leute dagegen sind, zeigen Sie ihnen einfach die Spezifikation und gehen Sie zu ihnen zurück und erklären Sie, dass wir optimieren müssen, weil wir die Spezifikation nicht erfüllen. Ansonsten würde es einem schwer fallen, andere davon zu überzeugen, dass eine Optimierung notwendig ist.

Ich denke, der Hauptpunkt des Zitats ist, wenn Sie kein Problem haben, führen Sie keine unnötigen Optimierungen durch, da Zeit und Energie woanders ausgegeben werden könnten. Aus geschäftlicher Sicht ist dies durchaus sinnvoll.

Zweitens, für diejenigen, die Optimierungen befürchten, sichern Sie die Leistungsergebnisse immer mit Metriken. Wie viel schneller ist der Code? Wie viel hat sich die Leistung gegenüber dem Vorjahr verbessert? Wenn man nur zwei Wochen damit verbringen würde, den Code gegenüber der Vorgängerversion um 2% zu verbessern, wäre ich nicht glücklich, wenn ich Ihr Chef wäre. Diese zwei Wochen hätten damit verbracht werden können, eine neue Funktion zu implementieren, die mehr Kunden anzieht und mehr Geld verdient.

Schließlich muss die meiste Software nicht stark optimiert werden. Nur in wenigen spezialisierten Branchen ist Geschwindigkeit wirklich wichtig. Daher kann man die meiste Zeit vorhandene Bibliotheken und Frameworks effektiv nutzen.

Jon Raynor
quelle
4
Gute Informationen beantworten zwar nicht meine Frage, wie man mit Leuten zusammenarbeitet, die eine Diskussion in dem Moment blockieren, in dem es um Leistung geht.
Errantlinguist
7
Ich bin mit all dem einverstanden, außer "Nur in wenigen spezialisierten Branchen ist Geschwindigkeit wirklich wichtig." Ich denke, Sie unterschätzen die Menge an Software, die aus Kundensicht Leistungsprobleme aufweist.
Gort the Robot
@StevenBurnap: Ja - gibt es Webanwendungen in freier Wildbahn, die eigentlich nicht langsam sind? - Ich würde gerne eine in der gleichen Wissenschaft sehen.
Errantlinguist
1
google.com ist ziemlich schnell. :-P
Gort the Robot
Versuchen Sie, google.com für eine EDGE-Mobilfunkverbindung zu verwenden. Ja, das ist ein lächerlicher Randfall, aber es wird definitiv nicht sehr schnell gehen . ;) (Wortspiel eigentlich nicht beabsichtigt - wirklich)
Errantlinguist
7

Wie kann man mit Leuten arbeiten, die eine Diskussion in dem Moment blockieren, in dem es um Leistung geht?

Beginnen Sie mit gemeinsamen Grundsätzen, die auf der strategischen Ausrichtung Ihrer Gruppe aufbauen.

Meine Prinzipien:

Meine persönlichen Prinzipien beim Schreiben von Code bestehen darin, zunächst die Korrektheit in meinem Programm anzustreben, es dann zu profilieren und festzustellen, ob es optimiert werden muss. Ich profiliere meinen Code selbst, weil andere Programmierer potenzielle Konsumenten meines Codes sind und ihn nicht verwenden, wenn er langsam ist. Daher ist Geschwindigkeit für meinen Code ein Merkmal.

Wenn Ihre Kunden Kunden sind, werden Ihre Kunden Ihnen mitteilen, ob Sie schnelleren Code benötigen.

Es gibt jedoch bekannte, nachweislich bessere Entscheidungen im Code, die man treffen kann. Ich würde es in meinem ersten Entwurf aus mehreren Gründen vorziehen, es richtig zu machen:

  1. Wenn ich es beim ersten Mal richtig mache, kann ich die Implementierung vergessen (indem ich das Ausblenden von Informationen ausnütze) und meinen Code nicht mit TODOs überhäufen.
  2. Andere (vor allem diejenigen, die nur am Arbeitsplatz lernen) sehen es als richtig an und lernen und verwenden denselben Codestil für die Zukunft. Umgekehrt, wenn sie sehen, dass ich es falsch mache, machen sie es auch falsch.

Angenommen, der Optimierungsbedarf ist richtig

Angenommen, dies ist ein wirklich wichtiger Teil Ihres Codes, der optimiert werden muss, könnten Sie das Gleichnis von Schlemiel, dem Maler , erzählen oder den Rest des Zitats hervorheben:

"Programmierer verschwenden enorm viel Zeit damit, über die Geschwindigkeit unkritischer Teile ihrer Programme nachzudenken oder sich Gedanken zu machen, und diese Effizienzversuche wirken sich in der Tat stark negativ auf das Debugging und die Wartung aus. Wir sollten kleine Effizienzvorteile vergessen 97% der Fälle: Vorzeitige Optimierung ist die Wurzel allen Übels. Dennoch sollten wir unsere Chancen bei diesen kritischen 3% nicht verpassen. " - Donald Knuth

Wiegen Sie die Kosten für zusätzliche Komplexität

Manchmal entstehen echte Kosten in Bezug auf die Wartbarkeit der zusätzlichen Komplexität. In diesem Fall können Sie die sekundäre Implementierung in einer anderen Funktion oder Unterklasse belassen und dieselben Unittests auf sie anwenden, sodass die Richtigkeit nicht in Frage gestellt wird. Wenn Sie später Ihr Code-Profil erstellen und feststellen, dass die naive Implementierung ein Engpass ist, können Sie Ihren optimierten Code einschalten und Ihr Programm nachweislich verbessern.

Führung

Manchmal ist das Problem das Ego - manche Leute würden lieber suboptimalen oder fehlerhaften Code verwenden, als dass jemand anderes mehr Recht hat als sie. Sie möchten wahrscheinlich vermeiden, mit diesen Leuten zu arbeiten.

Bei Führung geht es, insbesondere wenn Sie keine Positionsautorität über Menschen haben, darum, vernünftige Vorschläge zu machen und andere zu einem Konsens zu führen. Wenn Sie Ihr Team nicht zu einem Treffen der Köpfe führen können, ist die Angelegenheit möglicherweise nicht dringlich. Es gibt wahrscheinlich größere Fische zum Braten.

Aaron Hall
quelle
6

Der Weg in die Zukunft besteht darin, das eigentliche Zitat und die verschiedenen Interpretationen zu vergessen - es ist Dogmatismus, sich so oder so auf ein bestimmtes Zitat eines Gurus zu konzentrieren. Wer sagt eigentlich, dass Knuth immer Recht hat?

Konzentrieren Sie sich stattdessen auf das Projekt, auf die Software, die Sie entwickeln, und auf die Kollegen, mit denen Sie nicht einverstanden sind. Was sind die Voraussetzungen für eine akzeptable Leistung dieser Software? Ist es langsamer als das? Dann optimieren.

Sie müssen es nicht "Optimierung" nennen, sondern können es "Beheben eines Fehlers" nennen, da es sich per Definition um einen Fehler handelt, wenn die Implementierung nicht den Anforderungen entspricht.

Generell gibt es zwei Möglichkeiten zur Optimierung:

  1. Der optimierte Code ist außerdem kürzer, verständlicher und leichter zu warten.

  2. Das Verständnis des optimierten Codes ist komplexer, das Schreiben und Testen dauert länger oder es ist komplexer, wenn sich die Anforderungen in Zukunft unerwartet ändern.

Wenn der Fall (1) ist, müssen Sie nicht einmal über Optimierung streiten. Aber wenn (2) der Fall ist, dann engagieren Sie sich in einer Trade-off Entscheidung. Dies ist eigentlich eine Entscheidung auf Unternehmensebene, keine rein technische Entscheidung. Sie müssen die Kosten der Optimierung gegen den Nutzen abwägen. Damit es überhaupt einen Nutzen gibt, muss die Ineffizienz in erster Linie ein Problem sein, entweder als schlechte Benutzererfahrung oder als signifikant erhöhte Kosten für Hardware oder andere Ressourcen.

JacquesB
quelle
Nun, ich stimme Ihrem ersten Satz voll und ganz zu. Ich bin mir jedoch ziemlich sicher, dass eine Software für den vorgesehenen Anwendungsfall "ärgerlich langsam" sein kann, ohne dass die Leistungsanforderungen ausdrücklich auf formelle Weise festgelegt wurden.
Doc Brown
@DocBrown: Natürlich, aber in jedem Fall entscheidet der Kunde, ob es zu langsam ist oder nicht, nicht der Entwickler.
JacquesB
Ich bin nie auf Geschäftsanforderungen gestoßen, in denen die Leistungsanforderungen explizit angegeben sind.
Errantlinguist
@errantlinguist: Meiner Erfahrung nach ist es in kundenorientierten Unternehmen wie Online-Shops ziemlich verbreitet. Bei Tools und Anwendungen für den internen Gebrauch in einem Unternehmen ist die Benutzererfahrung für den Projektbesitzer jedoch normalerweise kein Problem.
JacquesB
4

Ich denke, das vollständige Zitat im Kontext ist aufschlussreich. Ich werde einen Beitrag kopieren, den ich auf Reddit zum Thema gemacht habe:

Es besteht kein Zweifel, dass der Gral der Effizienz zu Missbrauch führt. Programmierer verschwenden enorm viel Zeit damit, über die Geschwindigkeit unkritischer Teile ihrer Programme nachzudenken oder sich Gedanken zu machen, und diese Effizienzversuche wirken sich bei der Prüfung von Debugging und Wartung stark negativ aus. Wir sollten kleine Wirkungsgrade vergessen, sagen wir in 97% der Fälle: Vorzeitige Optimierung ist die Wurzel allen Übels.

Dennoch sollten wir unsere Chancen bei diesen kritischen 3% nicht verpassen. Ein guter Programmierer wird durch solche Überlegungen nicht zur Selbstzufriedenheit gebracht, er wird klug sein, den kritischen Code sorgfältig zu betrachten. aber erst nachdem dieser Code identifiziert wurde.

- Donald Knuth, Structured Programming mit go to Statements , ACM Computing Surveys, Bd. 6, Nr. 4, Dezember 1974, S. 268

Der Punkt und die Implikation ist, dass es wichtigere Dinge gibt, über die Sie sich Sorgen machen müssen, als Ihre Aufmerksamkeit zu früh auf die Optimierung zu lenken. Natürlich sollten Sie Ihre Datenstrukturen und Algorithmen sorgfältig prüfen (dies liegt bei den 3%), aber Sie sollten sich keine Gedanken darüber machen, ob die Subtraktion schneller ist als das Modulo (dies liegt bei den 97%), bis klar wird, dass eine Optimierung auf niedriger Ebene vorliegt notwendig.

Ersteres ist nicht notwendigerweise Optimierung in dem Sinne, wie Ihre Kollegen denken, sondern Optimierung in dem Sinne, dass schlecht ausgewählte Algorithmen und Datenstrukturen nicht optimal sind .

greyfade
quelle
2
Man könnte hinzufügen, dass Knuth die Analyse der zeitlichen Komplexität von Algorithmen und das Treffen von Entwurfsentscheidungen auf dieser Basis eindeutig nicht für eine vorzeitige Optimierung hält.
Sdenham
3

Nach meiner Erfahrung beschweren sich die Leute nicht wirklich über die Optimierung , wenn Sie diese Art von Opposition gegen die Optimierung regelmäßig haben. Sie beschweren sich darüber, was Sie im Namen der Optimierung opfern. Dies ist normalerweise die Lesbarkeit, Wartbarkeit oder Aktualität. Wenn Ihr Code in der gleichen Zeit geliefert wird und genauso einfach zu verstehen ist, ist es den Leuten egal, ob Sie effizientere Datenstrukturen und Algorithmen verwenden. Mein Vorschlag in diesem Fall ist, daran zu arbeiten, Ihren Code eleganter und wartbarer zu machen.

Wenn Sie diese Art von Widerspruch in Bezug auf den Code anderer Leute erhalten, liegt dies normalerweise daran, dass Sie eine erhebliche Menge an Überarbeitungen vorschlagen. In solchen Fällen müssen Sie tatsächlich einige Messungen durchführen, um zu zeigen, dass sich die Mühe lohnt, oder Sie versuchen, sich früher in die Entwurfsphase einzumischen, bevor Code geschrieben wird. Mit anderen Worten, Sie müssen beweisen, dass es sich um die 3% handelt. Wenn wir den gesamten Code neu geschrieben hätten, der nicht genau so war, wie wir ihn mochten, hätten wir nie etwas erreicht.

Karl Bielefeldt
quelle
Leider habe ich tatsächlich den umgekehrten Fall gemacht, in dem ich z. B. eine Dequeaus der Java-Standardbibliothek verwende, um eine enorme Menge an Logik zu ersetzen, die um einen ArrayListals Stapel verwendeten Code herum aufgebaut ist Änderung in der Überprüfung. Mit anderen Worten, der Rezensent wollte mehr Code haben, der auch langsamer und fehleranfälliger ist, weil er damit nicht vertraut war Deque.
Errantlinguist
3
Etwas zu lernen, das seit 10 Jahren nicht mehr in Ihrer Sprache gesprochen wird, ist eine giftige Einstellung für einen Programmierer und ein viel tieferes Problem, als Sie ursprünglich beschrieben haben. Persönlich würde ich in dieser Situation den Rat ablehnen und ihn gegebenenfalls an das Management weiterleiten.
Karl Bielefeldt
5
@errantlinguist: Als Ihr Rezensent eine deutlich schlechtere (das heißt kompliziertere) Lösung als Ersatz für eine saubere und einfache vorschlug, sollten Sie darüber streiten. Streite nicht über Leistung! Im Ernst, benutze niemals das Wort "Leistung" in dieser Diskussion. Streiten Sie nur über Lesbarkeit und Wartbarkeit. Und wenn der Rezensent auf seinem schlechten Code besteht, eskalieren Sie.
Doc Brown
+1 Ich bin mir nicht sicher, warum diese Antwort Downvotes anstelle von Upvotes enthält und die akzeptierte Antwort ist. Es schlägt sowohl eine Möglichkeit vor, mit dem Problem umzugehen, als auch eine Analyse dessen, was das eigentliche zugrunde liegende Problem sein könnte (dh dass niemand erfahren möchte, dass sein Code radikal neu geschrieben werden muss).
Andres F.
2

Es gibt in der Tat viele Missverständnisse in Bezug auf dieses Zitat. Es ist daher am besten, einen Schritt zurückzutreten und sich das eigentliche Problem anzuschauen. Das Problem ist nicht so groß, dass Sie es niemals "optimieren" sollten. Es ist so, dass "Optimieren" niemals eine Aufgabe ist, die Sie sich vornehmen sollten. Du solltest niemals morgens aufwachen und dir sagen "Hey, ich sollte den Code heute optimieren!".

Dies führt zu unnötigem Aufwand. Einfach Code anschauen und sagen "Ich kann es schneller machen!" führt zu viel Aufwand, etwas schneller zu machen, das anfangs schnell genug war. Sie sind vielleicht stolz darauf, sich selbst zu sagen, dass Sie ein bisschen Code viermal schneller gemacht haben, aber wenn dieser Code eine Berechnung war, die bei einem Tastendruck stattgefunden hat, und es zunächst 10 ms gedauert hat, bevor einem menschlichen Benutzer niemand angezeigt wurde wird es egal sein.

Das ist die "vorzeitige" in "vorzeitige Optimierung". Wann ist es nicht "verfrüht"? Wenn Kunden Ihnen sagen, "das ist verdammt langsam, beheben Sie es!" Das ist, wenn Sie in den Code graben und versuchen, es schneller zu machen.

Dies bedeutet nicht, dass Sie Ihr Gehirn ausschalten sollten. Dies bedeutet nicht, dass Sie 10.000 Kundendatensätze in einer einfach verknüpften Liste aufbewahren sollten. Sie sollten immer die Auswirkungen Ihrer Aktivitäten auf die Leistung verstehen und entsprechend handeln. Aber die Idee ist, dass Sie nicht extra Zeit damit verbringen, es absichtlich schneller zu machen. Sie wählen einfach die performantere Wahl aus ansonsten gleichen Entscheidungen.

Gort den Roboter
quelle
Dies bedeutet nicht, dass Sie Ihr Gehirn ausschalten sollten. Dies bedeutet nicht, dass Sie 10.000 Kundendatensätze in einer einfach verknüpften Liste aufbewahren sollten. > Obwohl ich Ihnen zu 100% zustimme, habe ich tatsächlich verknüpfte Listen gesehen, die auf diese Weise verwendet wurden, und wurde angewiesen, sie nicht zu berühren.
Errantlinguist
Gute Informationen beantworten zwar nicht meine Frage, wie man mit Leuten zusammenarbeitet, die eine Diskussion in dem Moment blockieren, in dem es um Leistung geht.
Errantlinguist
3
Leider war die Sache mit der "einfach verknüpften Liste" kein zufälliges Beispiel, sondern etwas, auf das ich persönlich gestoßen bin.
Gort the Robot
1

Sie können entweder die Dinge falsch oder richtig machen.

Oft werden die Dinge falsch gemacht und der Code wird überarbeitet, damit er richtig gemacht wird. Wenn Sie neuen Code schreiben und wissen, dass Sie die Dinge richtig machen können, ohne eine große Strafe zu haben, würde ich mich einfach irren, wenn Sie es richtig machen. (Beachten Sie, dass sich nach Leistungstests usw. möglicherweise einige Dinge ändern müssen - aber das ist in Ordnung. Alternativ ist eine vollständig naive Implementierung selten, wenn überhaupt, richtig.)

Es ist nicht unbedingt eine vorzeitige Optimierung, wenn Sie a) wissen, dass dies in Zukunft hilfreich sein wird oder b) wissen, dass der suboptimale Pfad später zu Problemen führen wird. Es ist wirklich wie ein Schachspiel.

Ich denke, dass die Leute dazu neigen werden, Dinge richtig zu machen, anstatt sie falsch zu machen. Verwenden Sie dies, wenn Sie alternative Strategien mit Ihren Kollegen besprechen.

lunchmeat317
quelle
5
Es gibt niemals "den falschen Weg" oder "den richtigen Weg". Es gibt im Allgemeinen unendlich viele Wege, die in einem Kontinuum von "Mein Gott, wie läuft das überhaupt?" Ablaufen. zu "John Carmack und Donald Knuth konnten dies beim Pair Programming nicht verbessern".
Gort the Robot
@StevenBurnap Das ist wahr. Ich denke jedoch, dass es für Einzelpersonen im Allgemeinen ein paar richtige und viele falsche Wege gibt. (Wenn wir bessere Programmierer werden, beginnt sich dieses Spektrum zu verschieben - unsere alten "richtigen Wege" können manchmal zu unseren neuen "falschen Wegen" werden, während unsere neuen richtigen Wege besser sind als die alten.) Ich denke, es ist gut, Dinge zu tun der beste und richtigste Weg für Sie . Dies führt uns dazu, bessere Programmierer zu werden, bessere Teamkollegen zu werden (Mentoring!) Und besseren Code zu schreiben.
lunchmeat317
" Ich denke, dass die Leute dazu neigen werden, Dinge richtig zu machen, anstatt sie falsch zu machen " - Das Problem ist, dass es sehr unterschiedliche Meinungen darüber gibt, was richtig oder falsch ist. Einige beginnen sogar heilige Kriege darüber (im wörtlichen Sinne).
JensG
1

Dies scheint ein Kommunikationsproblem und kein Programmierproblem zu sein. Versuchen Sie zu verstehen, warum die Menschen so fühlen, wie sie es tun, und versuchen Sie herauszufinden, warum Sie denken, Ihr Weg wäre besser. Wenn Sie das getan haben, beginnen Sie keine Auseinandersetzung, in der es Ihr Ziel ist, anderen zu erklären, warum sie falsch liegen und Sie Recht haben. Erklären Sie Ihre Gedanken und Gefühle und lassen Sie die Leute darauf reagieren. Wenn Sie keinen Konsens erzielen können und der Meinung sind, dass dies ein wirklich kritisches Problem ist, haben Sie wahrscheinlich einige schwerwiegende Probleme im Team insgesamt.

Konzentrieren Sie sich mehr auf das eigentliche Programmieren, verschwenden Sie keine Zeit mit langen Auseinandersetzungen über etwas, bei dem Sie nur das Gefühl haben, dass es "schneller" ist. Wenn Sie in einer Web-App jemanden sehen, der eine Methode schreibt, die einmal pro Anfrage aufgerufen wird, und wenn Sie wissen, dass es sich tatsächlich um ein O (log (n)) -Zeitproblem handelt, ist dies sicher ein Klacks, mach weiter.

Seien Sie sich jedoch bewusst, dass wir Programmierer als Menschen wirklich schlecht (und ich meine schrecklich) darin sind, zu erraten, welche Teile unserer Anwendungen Engpässe verursachen werden. Eric Lippert schreibt über dieses interessante Thema in diesem Blogbeitrag. Bevorzugen Sie immer die Wartbarkeit. Eventuell auftretende Leistungsprobleme können dann einfach (relativ) behoben werden, wenn Sie weitere Informationen haben.

Sara
quelle
Ich habe die Antwort editiert und die Dinge ein bisschen mehr ausgearbeitet. Kann der Downvoter ein Feedback hinzufügen? :)
Sara
Obwohl ich nicht der Abwähler bin, geht Ihr erster Absatz genau auf die vorliegende Frage ein, aber der Rest beantwortet meine Frage nicht, wie man mit Leuten zusammenarbeitet, die eine Diskussion in dem Moment blockieren, in dem es um Leistung geht (obwohl es immer noch ein guter Rat ist).
Errantlinguist
Grundsätzlich möchte ich in den letzten beiden Absätzen verdeutlichen, dass "diese Optimierungen möglicherweise nicht einmal von Bedeutung sind". In diesem Fall ist es besser, deine Kämpfe auszusuchen.
Sara