Dies ist hauptsächlich auf Antworten auf SQL-Fragen zurückzuführen. UDFs und Unterabfragen werden aufgrund der Leistung absichtlich weggelassen. Ich habe Zuverlässigkeit nicht eingeschlossen, nicht, dass es als selbstverständlich betrachtet werden sollte, aber der Code muss funktionieren.
Steht Leistung immer an erster Stelle? So viele Antworten werden mit der Leistung als Hauptpriorität zur Verfügung gestellt. Meine Benutzer scheinen sich mehr darum zu kümmern, wie schnell der Code geändert werden kann. Ein Bericht dauert also 15 Sekunden anstatt 12 Sekunden. Sie können damit leben, solange ich keine Ausreden dafür mache, keine Lösungen zu bieten.
Offensichtlich, wenn aus den 15 Sekunden 15 Minuten werden, gibt es ein Problem, aber die Benutzer wollen die Funktionalität. Sie möchten, dass sich die Anwendung an die Geschäftsregeländerungen und Erweiterungsanforderungen anpasst. Ich möchte in der Lage sein, den Code in 6 Monaten zu sehen und in der Lage zu sein, die Änderung in einem leicht identifizierbaren Punkt zu machen und nicht alle jene Orte zu verfolgen, die Code kopiert und eingefügt haben, weil sie eine andere Funktion oder Unterroutine oder UDF angaben Leistung behindern.
Alles was gesagt wird, würde ich bestellen: Wartbarkeit (Veränderung ist eine Tatsache des Lebens.), Leistung (Niemand mag es, auf die Sanduhr zu starren.), Wiederverwendbarkeit (Schwer zu bestimmen, welcher Code wieder verwendet werden sollte.).
1. Wartbarkeit: Wenn der Code nicht lesbar ist, ist er nutzlos, egal wie schnell er ist. Und es wird definitiv nicht wiederverwendet werden.
2. Wiederverwendbarkeit: Nicht jeder Code ist wiederverwendbar, aber eine Menge davon ist. Wenn Sie können, machen Sie Ihren Code auf jeden Fall einfacher. Am einfachsten ist das Teilen und Herrschen. Erstellen Sie beispielsweise einfache Komponenten, die Sie immer wieder verwenden. UI-Widgets sind am häufigsten. Aber es ist das gleiche mit Versorgungsunternehmen. Außerdem hilft das Erstellen einer Struktur / eines Frameworks für Ihren Code. Fehlerüberprüfungscode usw.
3. Leistung: Im Allgemeinen ist der meiste Code performant genug. Und wenn nicht, verwenden Sie einen Code-Profiler. Häufiger als der Engpass werden kleine Codeoptimierungen, die Sie auf Kosten von Lesbarkeit oder Wiederverwendbarkeit hätten vornehmen können, bei weitem überwiegen.
Ich glaube, Sie haben einen aus der Liste verpasst: Zuverlässigkeit;
Also meine Bestellung ist
Es spielt keine Rolle, wie schnell der Code ist, wenn er nicht stimmt. Erstens muss der Code zuverlässig sein.
Die Leistung befindet sich am Ende der Liste. Optimiere niemals zu früh und verbessere nur die Leistung, wenn die Leistung ein Problem darstellt.
Ich habe an Echtzeitsystemen gearbeitet, einschließlich der Flugsimulation, und selbst in dieser Umgebung wird die Leistung berücksichtigt, ist aber kein vorrangiges Anliegen 1 .
Ich würde sagen, dass ich meiner Erfahrung nach immer nur weniger als 1% des Codes, den ich geschrieben habe, optimieren musste.
1 manchmal ist etwas nicht schnell genug, und natürlich wird die Leistung beim Entwerfen und Codieren berücksichtigt, es steht einfach nicht an der Spitze der Liste.
Die Antwort des Saugers ist natürlich "es kommt darauf an".
Bei Geschäftsanwendungen muss die Antwortzeit für die betreffende Aktivität umgekehrt proportional zur Häufigkeit sein, mit der sie ausgeführt wird. Wenn es eine Funktion ist, auf die die Benutzer 4 oder 5 Mal pro Stunde zugreifen müssen, ist es besser, schneller zu sein als diesen Monatsendbericht zu lesen.
Ich denke, bis zu einem gewissen Grad haben Sie Ihre eigene Frage beantwortet und einige recht gute Gründe dafür angegeben. Der einzige, den du verpasst hast, ist Zuverlässigkeit - und genau hier kommt die Analogie der NASA ins Spiel. Wenn du Code für die NASA oder für ein Finanzinstitut schreibst, war es verdammt gut - besser, robust und zuverlässig ... und Ich denke, das wäre die erste Priorität.
Ich bin ein NASA-Auftragnehmer und entwickle und pflege Software hauptsächlich für Verwaltungszwecke wie das Ausführen von Berichten und das Verfolgen von Projekten.
Ich arbeite seit etwa 1,5 Jahren dort, und ich glaube, ihr Hauptanliegen ist Wartbarkeit und wie schnell können Sie die neue Funktion oder das Modul einsetzen?
Wie Guinness in der Frage sagt, solange die Software keine außergewöhnliche Zeit benötigt, scheint es ihnen nichts auszumachen.
Die andere Hauptsorge, die sie zu haben scheinen, ist Usability. Die Anwendung muss einfach und unkompliziert zu verwenden sein.
Zusammenfassend scheint Maintenability, Usability und Performance NASA's Hauptanliegen für interne Reporting- und Tracking-Tools zu sein.
Sie müssen in der Lage sein, diese Prioritäten je nach Projekt neu anzuordnen, und das Schwierige kann sein, das Verhalten schnell zu ändern, wenn Sie zwischen Projekten oder sogar verschiedenen Codeabschnitten wechseln. Ich arbeite an drei Anwendungen mit sehr unterschiedlichen Profilen.
Eins ist Echtzeit und es wird viel Arbeit darauf verwendet, sicherzustellen, dass seine Leistung vorhersehbar ist (nicht unbedingt blitzschnell), aber die Änderung ist kein großes Problem, sie ändert sich nur dann signifikant, wenn die IETF den RFC ändert oder veraltet Es gibt wenig Anzeichen dafür. (Das heißt, ich bin ziemlich stolz auf das Niveau der Wartbarkeit).
Eine andere App hat manchmal 16 Stunden gebraucht, um 1 Tag Daten zu verarbeiten. Unnötig zu erwähnen, dass die absolute Leistung schnell zur obersten Priorität wurde. Aber auch innerhalb dieser App variiert die Betonung der Leistung dramatisch, von "nicht wichtig" im pro-Batch-Code über pro-Client-Code, pro-Task-Code, pro Datei-Code, pro-Datensatz-Code, pro -field-code zu 'extrem wichtig' im per-byte-code.
Die letzte App enthält viel von der Geschäftslogik, Leistung ist nie ein Problem, Wartbarkeit und Agilität sind Schlüssel sind und diese App profitiert am meisten von allen modischen Methoden, wenn ich nur Wochen oder Monate verbracht habe Refactoring für die Leistung ist es sehr schwer zu schreiben "string1 + string2 + string3 + string4" auch wenn das am besten lesbar ist und die Leistung ist irrelevant.
Bearbeitet 2010-03-02 : Die Frage hat ursprünglich begonnen:
Arbeitet jeder für die NASA? Steht Leistung immer an erster Stelle? So viele Antworten ...
Nein, die meisten von uns arbeiten nicht für die NASA.
Nein: Zuverlässigkeit und Wartungsfreundlichkeit stehen der Leistung voraus. Wiederverwendbarkeit ist auch gut.
In weiten Grenzen ist Leistung nicht wichtig.
Das ist eine interessante Frage und die Antworten sind ziemlich interessant genug. Die Priorität hängt von der Implementierung ab. Ich möchte eines der Beispiele vorstellen, bei denen Benutzer die Leistung nicht für Wartbarkeit oder Wiederverwendbarkeit opfern würden. Ja, es gibt einen Faktor der Zuverlässigkeit - es sollte einen Bug / Fehler geben. Also, wenn wir Wartbarkeit, Leistung und Wiederverwendbarkeit vergleichen.
Einer unserer Kunden hatte eine Online-Trading-Site. Unter Spitzenlasten würde eine durchschnittliche Transaktion etwa 14 ms benötigen, um auf Middleware-Ebene abgeschlossen zu werden. Einige Zeit später verschlechterte sich die Leistung der Anwendung (aus einigen Gründen) und die durchschnittliche Zeit der Transaktionen stieg auf 24 ms. Jetzt, als normaler Entwickler, denken wir, dass 10 ms nicht so alarmierend kritisch sind. Aber wenn wir aus geschäftlicher Sicht denken, ist es alarmierend. Wie? Lassen Sie uns analysieren:
Nehmen wir an, dass die Ressourcen bei Lastspitzen voll ausgelastet sind und wir mit 14ms 100 Transaktionen durchführen konnten. Jetzt mit der Verschlechterung der Leistung nehmen die Transaktionen 10ms extra, das ist 71,42% zusätzliche Zeit. Dies würde bedeuten, dass wir nur noch 28,58 Transaktionen statt 100 Transaktionen bedienen können. Dies bedeutet ernsthafte Verluste für Unternehmen.
Tatsächlich gibt es eine Menge Literatur über die Bedeutung der Anwendungsleistung. Es gibt ein sehr schönes Buch "Quantitative Approach to Computer Architecture", das erklärt, wie die Faktoren Leistung, Wartbarkeit, Zuverlässigkeit, Verfügbarkeit in Business / User-Begriffen quantifiziert werden können.
Ich werde die Wichtigkeitsreihenfolge nicht angeben, da sie kontextspezifisch ist.
Sie dachten, eine andere Funktion oder Unterroutine oder UDF nennen würde Leistung behindern
Das ist falsches Denken.
Ich würde bestellen: Wartbarkeit, Leistung, Wiederverwendbarkeit.
Manchmal (normalerweise IMO) Wiederverwendbarkeit ist Wartbarkeit: es ist, weil Sie etwas wiederverwenden, dass Sie in der Lage sind, die Änderung an einem leicht identifizierbaren Ort zu machen und nicht alle jene Orte zu verfolgen, die Code kopiert und eingefügt haben ".
Leistung kommt nicht an erster Stelle, auch nicht bei der NASA! Bei der NASA, wenn der Code nicht korrekt und zuverlässig ist, sterben Menschen.
Nach meiner Erfahrung ist es sogar, wenn Leistung wertvoll ist, bis zu einem gewissen Punkt; Normalerweise gibt es ein Leistungsniveau, bei dem es keinen oder nur einen geringen Mehrwert gibt. Im Gegensatz dazu gibt es einen zusätzlichen Wert bei der Verbesserung der Korrektheit, unabhängig davon, wie zuverlässig ein Stück Code ist; Ein Codeabschnitt kann nicht wirklich zu oft wie erwartet funktionieren.
Für mich wäre die Reihenfolge:
In einer isolierten Antwort wird Performance fast immer an erster Stelle stehen.
Wir wissen nicht, ob Sie diesen Code millionenfach hintereinander schreiben werden, daher ist die Leistung standardmäßig ein Problem. Wir wissen nicht, ob unser wertvolles Code-Snippet zum Engpass Ihrer Anwendung wird, da wir nicht wissen, wie es interagiert. (Das Gleiche passiert beim Schreiben von Bibliothekscode: Ich weiß nicht, wie dies verwendet wird. Ein Grund, warum IMO-Code wiederverwendet wird, ist nicht einfach "ähnlichen Code zu einer geteilten Einheit zu bewegen".)
Wartbarkeit wird noch stärker dadurch beeinflusst, wie der Code mit dem uns unbekannten Code interagiert. Die Antwort wird das Problem in dem von Ihnen festgelegten Umfang lösen: Sie können nach SQL oder SQL Server oder MySQL fragen oder sie markieren. Den Rest wissen wir einfach nicht: Wie viele ähnliche Codepfade hast du? Wie oft ändert sich dieser Code während der Laufzeit des Projekts? Bleiben Sie zehn Jahre bei dieser bestimmten Version des Datenbankservers oder werden Sie häufig aktualisiert?
Das Lösen von Wartbarkeit ist weitgehend Ihre Aufgabe: Ist die Frage, die Sie stellen, eine Entität, die isoliert werden sollte?
Lesbarkeit ist meistens erledigt, der Rest ist Ihre Aufgabe.
Bei der Beantwortung sind wir in der Regel daran interessiert, die Antwort zu verstehen, so dass sie zumindest für Sie lesbar sein muss. Wenn Sie diesen Code in Ihren Code kopieren und einen // That weird query -Kommentar darauf schreiben, ist das nicht mehr mein Problem.
Dazu kommt die Tatsache, dass Performance einfacher zu verstehen ist: Aus zwei funktional äquivalenten Antworten wird immer diejenige gewählt, die sagt "wie Joes antworten, aber ein bisschen schneller", sofern es nicht große Fehler in der M + R-Abteilung macht.
Wenn man dies jetzt schreibt, sieht es so aus, als ob eine vorzeitige Optimierung verlockend ist. Diese ist aus mehreren Gründen die falsche Priorität.
Die niedrige Priorität für Optimierungen hat jedoch zwei Hauptgründe:
Korrektheit ist wichtiger als Wartbarkeit, Wiederverwendbarkeit oder Leistung. Wenn Sie auf Korrektheit zielen, werden Sie wahrscheinlich die anderen drei dazu bekommen.
Hier sind die Ergebnisse basierend auf Tag Count:
Was bedeutet das: Leistung muss wichtig sein? Die Leistung ist schwieriger, deshalb werden mehr Fragen gestellt. Leistungsfragen sind spezifischer / approach auf dieser Seite zu fragen?
Ich mache bei der NASA. Jedoch, ich führe (oder entwickle überhaupt nicht) Echtzeit-Code oder irgendwas, das all das Performance-kritisch ist. Die meiste Software, die bei der NASA gemacht wurde, ist es wahrscheinlich nicht. Nachdem ich zu meiner Zeit einen entsetzlichen Code gesehen habe, werde ich Jonathans Antwort auf Zuverlässigkeit und Wartungsfreundlichkeit geben, gefolgt von Performance und Wiederverwendbarkeit für die meisten Anwendungen.
Eines meiner Lieblingszitate stammt von SICP ...
"Computerprogramme sind so konzipiert, dass sie von Menschen gelesen werden können und zufällig von Computern ausgeführt werden."
Ich bewerte alle diese Aspekte meiner Arbeit; aber Lesbarkeit (einige verwenden den Begriff Ausdruckskraft) meines Codes und diejenigen, mit denen ich arbeite, stehen ganz oben auf meiner Liste der Wichtigkeit.
Nur meine 2c, ein schönes Wochenende!
Tags und Links performance maintenance code-reuse