Was verursacht schlechte Leistung in Consumer-Apps? [geschlossen]

32

Mein Comcast-DVR benötigt mindestens drei Sekunden, um auf jeden Tastendruck auf der Fernbedienung zu reagieren. Dadurch wird die einfache Aufgabe, fernzusehen, zu einem frustrierenden Erlebnis beim Drücken von Tasten. Mein iPhone benötigt mindestens fünfzehn Sekunden, um Kurzmitteilungen anzuzeigen, und stürzt ¼ der Versuche ab, die iPod-App aufzurufen. Das einfache Empfangen und Lesen einer E-Mail dauert oft länger als eine Minute. Sogar das Navcom in meinem Auto hat matschige und nicht reagierende Bedienelemente, die häufig aufeinanderfolgende Eingaben verschlucken, wenn sie weniger als ein paar Sekunden voneinander entfernt sind.

Dies sind alles Geräte für Endverbraucher mit fester Hardware, für die die Benutzerfreundlichkeit von größter Bedeutung sein sollte, und dennoch scheitern sie alle an der grundlegenden Reaktionsfähigkeit und Latenz. Ihre Software ist einfach zu langsam .

Was steckt dahinter? Ist es ein technisches Problem oder ein soziales? Wer oder was ist verantwortlich?

Liegt es daran, dass diese alle in verwalteten, müllsammelbaren Sprachen und nicht in nativem Code geschrieben wurden? Haben die einzelnen Programmierer die Software für diese Geräte geschrieben? In all diesen Fällen wussten die App-Entwickler genau, auf welche Hardwareplattform sie abzielen und welche Funktionen sie hatten. Haben sie das nicht berücksichtigt? Ist es der Typ, der wiederholt: "Optimierung ist die Wurzel allen Übels", hat er sie in die Irre geführt? War es eine Mentalität von "Oh, es sind jedes Mal nur zusätzliche 100 ms", bis sich all diese Millisekunden auf Minuten summieren? Ist es meine Schuld, dass ich diese Produkte überhaupt gekauft habe?

Dies ist eine subjektive Frage, ohne einzelne Antwort, aber ich bin frustriert oft so viele Antworten hier , um zu sagen : „Oh, nicht über Code Geschwindigkeit sorgen, Leistung spielt keine Rolle“ , wenn klar irgendwann es tut Sache der Endbenutzer, der mit einer langsamen, nicht reagierenden, schrecklichen Erfahrung feststeckt.

Wann ist also bei diesen Produkten ein Fehler aufgetreten? Was können wir als Programmierer tun, um diesen Schmerz nicht unseren eigenen Kunden zuzufügen?

Crashworks
quelle
4
Sie gehen davon aus, dass etwas schief gelaufen ist. Irgendwann sagte jemand "das ist gut genug" und verschickte sein Produkt. Wenn Endbenutzer es akzeptieren, ist es da. (Ich sage nicht, dass es richtig ist, aber es muss ein Gleichgewicht zwischen Schiff es jetzt und Schiff es nie geben.)
Michael Todd
3
@Michael: Das scheint mit "meiner Schuld, diese Geräte gekauft zu haben" oder allgemeiner "unserer Schuld als Verbraucher, dieses Maß an Schlamperei zu akzeptieren" in Einklang zu stehen.
Crashworks
3
@ Crashworks: Ja, ziemlich genau. Die Leute würden Crapware nicht weiter verkaufen, wenn wir sie nicht weiter kaufen würden.
Mason Wheeler
4
Sie wurden in modernen, nicht müllsammelnden Unternehmen entwickelt.
2
Anstelle von "Liegt es daran, dass diese alle in verwalteten, vom Müll gesammelten Sprachen geschrieben wurden?" Ich lese "Liegt es daran, dass diese alle in Müllsprachen geschrieben wurden, die von Managern ausgewählt wurden?"
Carlos Campderrós

Antworten:

27

Gute Frage. Was ich täglich sehe, ist das.

Die Leute arbeiten an großformatigen Apps. Während sie arbeiten, schleichen sich Leistungsprobleme ein, genau wie Fehler. Der Unterschied ist - Bugs sind "schlecht" - sie schreien "finde mich und repariere mich". Leistungsprobleme sitzen einfach da und werden schlimmer. Programmierer denken oft: "Nun, mein Code hätte kein Leistungsproblem. Stattdessen muss das Management mir eine neuere / größere / schnellere Maschine kaufen."

Tatsache ist, wenn Entwickler regelmäßig nach Leistungsproblemen suchen (was eigentlich sehr einfach ist ), können sie diese einfach beseitigen.

Stattdessen lautet der "Stand der Technik":

  1. Verlassen Sie sich auf Aphorismen wie "Vermeiden Sie vorzeitige Optimierung" und 90/10 hoo-haw.
  2. Sprechen Sie mutig über die Profilerstellung und versuchen Sie es manchmal tatsächlich, oft mit enttäuschenden Ergebnissen, wie Sie in allen SO-Fragen dazu sehen.
  3. greife auf gute alte Vermutungen zurück, die als Erfahrung und Wissen getarnt sind.

Aber das ist wirklich negativ. Positiv ist zu vermerken, dass diese Methode fast immer funktioniert und nicht einfacher sein kann. Hier ist ein detailliertes Beispiel .

Mike Dunlavey
quelle
3
Mike, eines Tages werden Sie und ich zusammen ein Buch über Profilerstellung schreiben müssen. Es wird die "Kathedrale und der Basar" der Performance-Programmierung sein.
Crashworks
@ Crashworks: Das würde Spaß machen. Wenn Sie es ernst meinen, schreiben Sie mir eine Nachricht.
Mike Dunlavey
@Mike Sicher, aber später im Sommer denke ich - ich habe einen riesigen Rückstand an Artikeln und Papieren, die ich bereits der GDC, #AltDevBlogADay und meinem eigenen Arbeitgeber schulde!
Crashworks
Ich stimme im Allgemeinen zu. Aber trotz des Missbrauchs durch Leute, die sich nicht einmal Gedanken über die Komplexität der Berechnungen machen, sind Sprüche wie "vorzeitige Optimierung ist die Wurzel allen Übels" (jeder, der dies jemals zitiert, sollte die Vollversion lesen) und die 90/10-Regel don Sag nicht "nicht optimieren", sondern "effizient optimieren". Niemand hat etwas davon, sich eine Millisekunde vor dem Initialisierungscode zu rasieren. Das Schreiben von Code mit der Absicht, jede einzelne Zeile so performant wie möglich zu machen, führt nur zu einem nicht zu wartenden Durcheinander, das vom Lösen der relevanten Leistungsprobleme usw.
@delnan: Das erste Mal, dass ich Zufallspausen verwende, ist um 1978, auf einem Raytheon Mini mit "Stopp" - und "Schritt" -Tasten. Ich kann mich nicht erinnern, jemals gedacht zu haben, es gäbe einen anderen Weg. Obwohl es auf Big-O ankommt, ist es mir ein Rätsel, wie man Optimierungen in echter Software diskutieren kann, ohne dass das Programm selbst sagt, wo man sich konzentrieren soll.
Mike Dunlavey
16

Dies ist kein technisches Problem, sondern ein Marketing- und Managementproblem.

Du verdrehst an dieser Stelle vielleicht die Augen, aber bitte trage es mit mir.

Was ein Unternehmen verkauft, ist sein "Produkt", und die Leute, die das definieren, sind "Produktmanager". In Technologiefirmen wiegen viele andere Leute darauf - Experten für Benutzererfahrungen, yadda yadda. Letztendlich sind die Produktmanager jedoch dafür verantwortlich, die Spezifikationen für das zu schreiben, was der Benutzer erhalten soll.

Nehmen wir also Ihren Comcast-DVR. Im Idealfall würden die Dinge so funktionieren:

  1. Der Produktmanager schreibt in einer Spezifikation: "Wenn ein Benutzer eine Taste auf der Fernbedienung drückt und sich innerhalb eines Abstands von 25 Fuß zum DVR befindet, muss der DVR innerhalb von 250 Millisekunden auf die Presse antworten."
  2. Die technischen Leute bauen die Hardware, schreiben die eingebettete Software usw.
  3. Die QA-Tester bestätigen entweder, dass das System die Spezifikation erfüllt, oder leiten es zur Behebung an das technische Team zurück.

Natürlich kann vieles schief gehen:

  • Der Produktmanager kann die Tastenreaktion nicht in die Spezifikation einfügen
  • Die QA-Leute machen einen mittelmäßigen Test gegen die Spezifikation
  • Jemand wählte Technologien aus, die es nicht zulassen, dass die Spezifikation erfüllt wird, damit die Anforderung erfüllt wird
  • Das technische Personal ist unterbesetzt, oder jemand hat den Zeitplan beschleunigt, und ein Manager sagt: "Vergessen Sie die Reaktionsfähigkeit - machen Sie diese andere Funktion fertig."
  • Der Produktmanager veröffentlicht die Reaktionsanforderungen erst zu einem so späten Zeitpunkt im Spiel, dass sie zum Versanddatum nicht mehr erfüllt werden können
  • Das Management beschließt, bis dahin nichts für QS-Tests einzureichen. Eine Beschleunigung des langsamen Codes würde das Produkt destabilisieren

Hast du all die schwachsinnigen Programmierer dort gesehen? Es gab keine.

Ich sage nicht, dass wir überhaupt keine Verantwortung für schlechte Leistung tragen - oft ist es genauso einfach und schnell, guten, robusten und effizienten Code zu schreiben wie Junk.

Aber wirklich, wenn das Produktmanagement und die QS-Mitarbeiter alle am Steuer schlafen, können wir Programmierer das nicht wettmachen.


FWIW, ich stimme den abgrundtiefen Schnittstellen der meisten Konsumgüter voll und ganz zu. Ich schreibe jetzt seit ungefähr 25 Jahren UI-Code und strebe nach Eleganz und Einfachheit. Es ist eigentlich ein Problem, weil ich so viel darüber nachdenke, dass ich es heute nicht mehr gut finde, schlecht gestaltete Benutzeroberflächen zu finden, sodass meine arme Frau die meisten Geräte in unserem Media Center laufen lässt.

Bob Murphy
quelle
+1 - Probleme (Fehler oder Leistung) mit Endprodukten können niemals Programmierern angelastet werden. Wenn ein Produkt die verschiedenen erforderlichen Teststufen bestanden hat, hat der Programmierer seine Arbeit korrekt ausgeführt. Wenn ein Produkt die Tests besteht und es Probleme gibt, ist der Test / die Spezifikation schuld.
Qwerky
5
+1 Gut geschrieben, vor allem über Produktmanagement usw. Allerdings bin ich nicht einverstanden über die Verantwortung. Ich habe es den Leuten anvertraut, die Programmierer ausbilden, was dazu führt, dass Programmierer nicht wirklich wissen, wie sie Leistungsfehler finden (und wie einfach es ist, im Vergleich zu Korrektheitsfehlern).
Mike Dunlavey
1
@ Mike: Ganz richtig. In meiner ersten Hauptrolle war einer meiner Berichte ein Typ, der gerade einen MSCS von Stanford bekommen hatte, dem nur beigebracht worden war, "richtigen" Code zu schreiben, und der meinte, ich sei sehr seltsam, auch eine einfache zweistufige verschachtelte Schleife zu erwarten in einem kommerziellen Multitasking-Produkt die CPU nicht auf den Knien lassen und nach Sauerstoff schnappen. Dort musste ein wenig Mentoring durchgeführt werden. :-)
Bob Murphy
11

Weil Programmierer nicht perfekt sind.

Ich bin ein Programmierer von eingebetteten Dingen. Ein Teil meines Codes ist nicht perfekt. Der größte Teil meines eingebetteten Codes ist schnell.

Leistungsprobleme am Ende eines Projekts zu beheben, ist sehr schwierig.

Manchmal schichten wir Dinge, um die Dinge einfach zu halten (und damit testbar, entwicklungsfähig in realistischer Zeit, nicht tödlich fehlerhaft), wie die Remote-Eingabe für einen "Dienst", der nicht Teil der Hauptanwendung ist. Endergebnis, Latenz. Die Alternative besteht darin, alles in eine monolithische Anwendung zu packen, was in C oder C ++ (den beiden am häufigsten vorkommenden eingebetteten Sprachen) eine fehlerhafte Katastrophe darstellt.

Manchmal verfügt Ihr Embedded-Gerät über einen Prozess-Scheduler, der nicht das tut, was Sie als Benutzer wünschen. Verdammt schwer zu reparieren als Embedded-Entwickler.

Die Komplexität verursacht die Verzögerung aufgrund der Latenz beim Schichten. Sie haben nach den Funktionen gefragt. Probieren Sie ein wirklich altes Nokia aus, wie das alte 3210. Zippy fast UI. Nicht viele Funktionen.

Ich behaupte, dass Entwickler nicht schlauer werden, so dass schnellere Hardware von Abstraktionen absorbiert wird, um zu verhindern, dass sich Features gegenseitig umbringen. (Oder nicht, im Falle Ihres iPhone)

Die Leistung der Benutzeroberfläche muss eine Anforderung sein, die Sie im Verlauf des Entwurfs testen müssen.

Wenn es nicht spezifiziert ist, wird sich der Entwickler daran gewöhnen. Das machen wir alle. "Mein Baby ist nicht hässlich"

Und es sind nicht die GC-Sprachen; Embedded Realtime Java ist so schnell, dass es unheimlich ist. (Embedded Python hingegen ist ein totaler Hund)

Ich schreibe ein Programm, das beim Lesen digitale Eingänge als UI einschaltet. Der Schalter muss noch entprellt werden, so dass ein sehr schnelles Betätigen des Schalters nicht funktioniert, da der Entprellvorgang einige Ebenen höher ist. Idealerweise würde ich die Entprelllogik am unteren Rand des Firmware-Stacks haben, aber so funktioniert die Hardware nicht.

Einige DVD-Player führen einfach ein "Auswurf" -Skript aus, um den Auswurf durchzuführen. Ihr DVR hat diesen Ansatz möglicherweise gewählt, um die Entwicklungskosten in Grenzen zu halten. Dann spart man CPU oder RAM und es nervt.

Tim Williscroft
quelle
1
+1 Vor allem für "Mein Baby ist nicht hässlich" und das Entprellen Zeug. Ich habe vor langer Zeit einige eingebettete Arbeiten gemacht (in Pascal, glauben Sie es). Einmal zeichnete es Fließkommazahlen auf ein Video und war schmerzlich langsam dabei. An einem Wochenende habe ich den ICE angeschlossen, einen Stapelschuss (in hex) gemacht und ihn verwirrt. Es befand sich im Gleitkomma-Emulator und wurde von einer Routine aufgerufen, die jede Ziffer durch Teilen, Abschneiden, Multiplizieren, Subtrahieren usw. abschält. Und das war natürlich mein Code . (Ich fand einen besseren Weg, um es zu tun.)
Mike Dunlavey
3

Liegt es daran, dass diese alle in verwalteten, müllsammelbaren Sprachen und nicht in nativem Code geschrieben wurden?

Langsamer Code funktioniert trotzdem schlecht. Sicher, eine bestimmte Sprache kann bestimmte Problemklassen hervorrufen, während andere gelöst werden. Gute Programmierer sind jedoch durchaus in der Lage, Problemumgehungen zu finden, wenn genügend Zeit zur Verfügung steht.

Haben die einzelnen Programmierer die Software für diese Geräte geschrieben?

Teilweise. In vielen Fällen ist es sehr wahrscheinlich, dass zumindest ein Faktor dazu beiträgt. Dies ist ein bedauerlicher Nebeneffekt einer Branche, in der gute Programmierer stark nachgefragt werden und das Angebot knapp ist. Auch die Kluft zwischen verschiedenen technischen Fähigkeiten kann recht groß sein. Es liegt also auf der Hand, dass manchmal die Programmierer, die mit der Implementierung bestimmter Software beauftragt wurden, nur dazu beglückwünscht werden konnten, dass sie zum Laufen gebracht wurden.

In all diesen Fällen wussten die App-Entwickler genau, auf welche Hardwareplattform sie abzielen und welche Funktionen sie hatten. Haben sie das nicht berücksichtigt?

Teilweise. Zunächst einmal ist die genaue Hardwareplattform wahrscheinlich nicht bekannt, da diese bei der Softwareentwicklung häufig mit verschiedenen Herstellern parallel ausgehandelt wird. Tatsächlich kann es nach der Erstveröffentlichung sogar zu geringfügigen (aber nicht unbedingt unbedeutenden) Änderungen an der zugrunde liegenden Hardware kommen. Ich stimme jedoch zu, dass die allgemeinen Fähigkeiten bekannt sein werden.

Ein Teil des Problems ist, dass Software wahrscheinlich nicht auf der Hardware entwickelt wird, sondern in Emulatoren. Dies macht es schwierig, die tatsächliche Geräteleistung zu berücksichtigen, selbst wenn die Emulatoren zu 100% genau sind - was nicht der Fall ist.

Dies rechtfertigt natürlich nicht wirklich unzureichende Tests auf der entsprechenden Prototyp-Hardware vor der Veröffentlichung. Diese Schuld liegt wahrscheinlich außerhalb der Kontrolle von dev / qa.

Ist es der Typ, der wiederholt: "Optimierung ist die Wurzel allen Übels", hat er sie in die Irre geführt?

Nein, ich bin mir ziemlich sicher, dass sie ihm sowieso nicht zuhören. sonst würde er nicht so oft falsch zitiert (das soll " vorzeitige Optimierung ..." sein). :-D

Es ist wahrscheinlicher, dass zu viele Programmierer hinsichtlich der Optimierung eines von zwei Extremen annehmen.

  • Entweder ignorieren sie es komplett.
  • Oder sie sind von Kleinigkeiten besessen, die nichts mit den tatsächlichen Leistungsanforderungen zu tun haben. Der Nettoeffekt ist, dass das Budget knapp wird und der Code zu verschleiert ist, um die tatsächlichen Leistungsprobleme sicher zu optimieren .

War es eine Mentalität von "Oh, es sind jedes Mal nur zusätzliche 100 ms", bis sich all diese Millisekunden auf Minuten summieren?

Möglicherweise. Wenn Sleep(100)als Äquivalent Tissue-Papier verwendet wurde, um das Ausbluten einer abgetrennten Extremität zu verlangsamen, sind natürlich Probleme zu erwarten. Ich vermute jedoch, dass das Problem subtiler ist.

Die Sache ist, dass moderne Computerhardware (einschließlich eingebetteter Geräte) viel schneller ist, als man ihnen zuschreibt. Die meisten Leute, selbst "erfahrene" Programmierer, wissen nicht, wie schnell Computer sind. 100 ms sind eine lange Zeit - eine sehr lange Zeit . Und wie es passiert, schneidet diese "sehr lange Zeit" zwei Wege:

  • Zum einen sorgen sich Programmierer unnötig um die Dinge, die ein Computer extrem schnell erledigt. (Es ist so, dass es nur eine Sorge war, " 300-mal pro Sekunde einen Wert zu erhöhen ", die mich hierher geführt hat.)
  • Der zweite Grund ist, dass sie manchmal keine angemessene Besorgnis zeigen, wenn die Dinge sehr lange dauern (auf der Rechenzeitskala). So:
    • wenn sie die Auswirkungen der Latenz bei der Kommunikation über ein Netzwerk oder mit einem Speichergerät ignorieren;
    • wenn sie die Auswirkungen eines blockierten Threads ignorieren und auf einen anderen Thread warten;
    • Wenn sie das vergessen, weil Computer so schnell arbeiten, ist es sehr gut in der Lage, eine Aufgabe viel häufiger zu wiederholen, als es sollte, ohne dass sich der Entwickler eines Problems bewusst ist
    • ... wenn eine Kombination solcher Versehen auftritt, wird eine Routine unerwartet sehr langsam ausgeführt (auf der Rechenzeitskala). Ein paar Wiederholungen und es wird sogar von Menschen bemerkt werden - aber es kann schwierig sein, es festzunageln, weil Hunderte von miteinander verbundenen Dingen von selbst schnell laufen.

Ist es meine Schuld, dass ich diese Produkte überhaupt gekauft habe?

Ja definitiv. Nun, nicht Sie persönlich, sondern die Verbraucher im Allgemeinen. Produkte werden über Feature-Checklisten verkauft (und gekauft ). Zu wenige Verbraucher fordern eine bessere Leistung.

Um meinen Standpunkt zu verdeutlichen: Als ich das letzte Mal ein Handy kaufen wollte, konnte der Laden nicht einmal ein Demomodell zum Spielen im Laden anbieten. Alles, was sie hatten, waren Plastikhüllen mit Aufklebern, die zeigten, wie der Bildschirm aussehen würde. Sie können nicht einmal ein Gefühl für das Gewicht bekommen - geschweige denn Leistung oder Benutzerfreundlichkeit. Mein Standpunkt ist, dass wir nur einen kleinen Schritt in die richtige Richtung gehen würden , wenn genügend Menschen Einwände gegen dieses Geschäftsmodell erheben und mit ihren Geldbörsen abstimmen würden, um ihren Einwand zu äußern .

Aber sie tun es nicht, also sind wir es nicht. und jedes Jahr laufen neue Handys auf schnellerer Hardware langsamer.

(Die Fragen nicht gestellt.)

  • Sind Marketing-Leute schuld? Teilweise. Sie benötigen Veröffentlichungstermine. Und wenn das besagte Datum bevorsteht, ist die Wahl zwischen "Lass es funktionieren" und "Mach es schneller" ein Kinderspiel.
  • Sind Verkäufer schuld? Teilweise. Sie wollen mehr Funktionen in der Checkliste. Sie übertreiben Feature-Listen und ignorieren die Leistung. Sie machen (manchmal) unrealistische Versprechungen.
  • Sind Manager schuld? Teilweise. Unerfahrene Manager können viele Fehler machen, aber selbst sehr erfahrene Manager können (zu Recht) Zeit opfern, um Leistungsprobleme zugunsten anderer Bedenken zu lösen.
  • Sind Spezifikationen schuld? Teilweise. Wenn etwas außerhalb der Spezifikation liegt, ist es viel einfacher, es später zu "vergessen". Und wenn es nicht ausdrücklich angegeben ist, was ist das Ziel? (Obwohl ich persönlich der Meinung bin, dass ein Team, das stolz auf seine Arbeit ist, sich trotzdem um die Leistung sorgen würde.)
  • Ist Bildung schuld? Vielleicht. Bildung wird wahrscheinlich immer im Rückstand sein. Ich missbillige mit Sicherheit "Bildung", die Anfänger mit einem oberflächlichen Verständnis für Softwareentwicklung schnell aus dem Konzept bringt. Eine Ausbildung, die mit Theorie untermauert ist und eine Lernkultur vermittelt, kann jedoch nicht schlecht sein.
  • Sind Upgrades schuld? Teilweise. Neue Software, alte Hardware ist wirklich verlockend. Noch vor der Veröffentlichung von Version X ist X + 1 in Planung. Die neue Software ist kompatibel, aber ist die alte Hardware schnell genug? Wurde es getestet? In der neuen Software ist möglicherweise eine bestimmte Leistungsverbesserung enthalten, die zu einem unsachgemäßen Software-Upgrade führt.

Grundsätzlich glaube ich, dass es viele Faktoren gibt, die dazu beitragen. Leider gibt es keine Silberkugel, um das Problem zu beheben. Das heißt aber nicht, dass es düster und düster ist. Es gibt Möglichkeiten, zur Verbesserung der Dinge beizutragen.

Wann ist also bei diesen Produkten ein Fehler aufgetreten?

IMHO können wir keinen einzelnen Punkt wirklich identifizieren. Es gibt viele Faktoren, die sich im Laufe der Zeit entwickelt haben.

  • Bohnenzähler: Kostensenkung, Market Timing. Aber hätten wir die erzielten Fortschritte auch ohne Druck gemacht?
  • Hohe Nachfrage und geringes Angebot an Fachkräften in der Branche. Nicht nur Programmierer, sondern auch Manager, Tester und sogar Verkäufer. Mangel an Fähigkeiten und Erfahrung führt zu Fehlern. Andererseits führt es auch zum Lernen.
  • Spitzentechnologie. Bis eine Technologie ausgereift ist, wird sie regelmäßig auf unerwartete Weise beißen. Andererseits bot es in erster Linie häufig eine Reihe von Vorteilen.
  • Komplizierte Komplikation. Im Laufe der Zeit hat sich die Branche weiterentwickelt: Hinzufügen weiterer Tools, Technologien, Ebenen, Techniken, Abstraktionen, Hardware, Sprachen, Variationen und Optionen. Dies macht es etwas unmöglich, ein "vollständiges" Verständnis für moderne Systeme zu haben. Dadurch sind wir aber auch in der Lage, in viel kürzerer Zeit viel mehr zu leisten.

Was können wir als Programmierer tun, um diesen Schmerz nicht unseren eigenen Kunden zuzufügen?

Ich habe einige Vorschläge (sowohl technische als auch nichttechnische), die helfen können:

  • Soweit möglich - verwenden Sie Ihr eigenes Produkt. Es gibt nichts Besseres als die Erfahrung aus erster Hand, um Dinge aufzudecken, die umständlich, langsam oder unbequem sind. Sie müssen jedoch bewusst vermeiden, dass Mängel aufgrund von "Insiderwissen" umgangen werden. Wenn Sie beispielsweise keine Probleme beim Synchronisieren von Kontakten haben, weil Sie dies mit einem Backdoor-Python-Skript tun, verwenden Sie "das Produkt" nicht. Welches bringt den nächsten Punkt auf ...
  • Hören Sie Ihren Benutzern zu (vorzugsweise aus erster Hand, aber mindestens aus zweiter Hand über den Support). Ich weiß, dass Programmierer (im Allgemeinen) es vorziehen, versteckt zu bleiben und menschliche Interaktionen zu vermeiden. Dies hilft Ihnen jedoch nicht dabei, die Probleme zu erkennen, die andere Personen bei der Verwendung Ihres Produkts haben. Sie bemerken möglicherweise nicht, dass die Menüoptionen langsam sind, da Sie alle Verknüpfungen kennen und diese ausschließlich verwenden. Auch wenn das Handbuch alle Verknüpfungen vollständig dokumentiert, bevorzugen einige Benutzer die Menüs - obwohl sie unerträglich langsam sind.
  • Bemühen Sie sich, Ihre technischen Fähigkeiten und Kenntnisse kontinuierlich zu verbessern. Entwickeln Sie die Fähigkeit, alles, was Sie lernen, kritisch zu analysieren. Überprüfen Sie Ihr Wissen regelmäßig. In einigen Fällen sollten Sie vergessen, was Sie zu wissen glaubten. Welches bringt auf ...
  • Einige Technologien / Techniken können sehr knifflig sein und zu subtilen Missverständnissen und falschen Implementierungen führen. Andere, die durch die Weiterentwicklung des Allgemeinwissens oder der verfügbaren Tools entstanden sind, können sich als günstig oder ungünstig erweisen (z. B. Singletons). Einige Themen sind so knifflig, dass sie eine Reihe von "Hokuspokus-Experten" hervorbringen, die eine Vielzahl von Fehlinformationen verbreiten. Ein besonderer Bugbear von mir ist die Fehlinformation rund um Multithreading. Eine gute Multithread-Implementierung kann das Benutzererlebnis erheblich verbessern. Leider werden viele falsch informierte Ansätze zum Multithreading die Leistung erheblich reduzieren, fehlerhafte Bugs verstärken, Deadlock-Risiken erhöhen, das Debuggen erschweren usw. Denken Sie also daran: Nur weil ein "Experte" es gesagt hat, ist es nicht wahr.
  • In Besitz nehmen. (Nein, im Ernst, ich spiele kein Boardroom-Bingo.) Verhandeln Sie mit Managern, Produktbesitzern und Verkäufern über Leistungsmerkmale, die Vorrang vor einigen Checklistenelementen haben. Fordern Sie bessere Spezifikationen. Nicht kindisch, sondern durch Fragen, die zum Nachdenken über Leistung anregen.
  • Seien Sie ein anspruchsvoller Verbraucher. Wählen Sie das Telefon mit weniger Funktionen, das jedoch schneller ist. (Nicht schneller CPU, schneller UI.) Dann prahlen Sie damit ! Je mehr Verbraucher anfangen, nach Leistung zu verlangen, desto mehr Bohnenkostenzähler planen dies ein.
Desillusioniert
quelle
Dies ist eine wirklich gründliche, durchdachte Antwort! Zufälligerweise habe ich das gleich gelesen, nachdem ich von einer Teambesprechung zurückgekommen war, in der das Thema lautete "# 1 A-Priority Bug in diesem Zyklus: Latenz> 60 ms, es muss 33 ms sein, ZOMG !!! 1!"
Crashworks
1

Ihr erster Fehler und wahrscheinlich der Grund, warum Sie eine Ablehnung erhalten haben, verdient die offensichtliche Übertreibung. Erwarten Sie wirklich, dass iPhone und iPad so schlecht sind?

Letztendlich ist der Kunde verantwortlich. Es kommt auf die Kosten an und darauf, was der Kunde bereit ist zu zahlen und was er dafür erhält. Wenn sie Merkmale vor Geschwindigkeit wählen, erhalten sie diese. Wenn sie den Preis der Geschwindigkeit vorziehen, wird das gebaut und verkauft. Wenn Markenimage wichtiger ist ..... Letztendlich entscheidet der Kunde mit seiner Geldbörse, was wichtig ist und was nicht. Sie haben die Wahl, eine Markenhure zu sein und Produkte zu kaufen, weil alle anderen es tun, oder Sie sind ein unabhängiger Denker, schauen hinter den Glanz- und Marketing-Hype und kaufen etwas, das Ihren Bedürfnissen entspricht.

Sie beschuldigen die Programmierer. Sicher, sie haben den Code geschrieben, aber sie haben die Kundenanforderungen, die Hardware, die Stücklistenkosten, die F & E-Kosten und das Marketingbudget nicht definiert und sollten sie auch nicht definieren , das ist keine Software.

Die verwendeten Technologien, verwendeten Sprachen usw. haben damit nichts zu tun. Schlechte gegen gute Entwickler, nichts damit zu tun. Jeder halbwegs anständige Programmierer kann einen Teil des Codes schneller ausführen, reaktionsschneller sein und das Ultimative bieten. Meine Erfahrung ist, dass anständige Programmierer das Geschäft nicht ruinieren, wenn sie die Entscheidungen treffen müssen, während halb anständige sich darüber beschweren, wie viel "besser" es sein sollte.

mattnz
quelle
2
Meine iPhone-Nummern sind nicht übertrieben. Ich habe sie erhalten, indem ich die Sekunden laut gezählt habe, während ich mein eigenes Telefon benutzt habe. Unter youtube.com/watch?v=Pdk2cJpSXLg finden Sie eine humorvolle (wenn auch weniger extreme) Darstellung dieses Problems . Auch mein Handy war in Ordnung, als ich es kaufte! Ich habe die Leistung bei der Auswahl der Telefone sorgfältig bewertet. Mit jedem Firmware-Update von Apple wurde es jedoch langsamer und langsamer, bis es unbrauchbar wurde. Ich vermute, es könnte mein Fehler bei der Installation der Apple-Updates sein.
Crashworks
Ich beschuldige die Programmierer in hohem Maße - ich sehe die ganze Zeit kommerzielle Apps mit Fehlern und schrecklichen Anwendungsfällen, die kein Entwickler mit Kompetenz oder Stolz in seiner Arbeit jemals veröffentlichen würde, unabhängig davon, für wen er arbeitet - diese Leute sind eine Schande für unseren Beruf.
Vector
1

Eine vorzeitige Optimierung ist manchmal schlecht, jedoch nicht, wenn dies für eine gute Benutzererfahrung oder eine gute Akkulaufzeit in einem ausreichend eingeschränkten System erforderlich ist. Der Fehler liegt darin begründet, dass dem sauberen, wartbaren Software-Engineering eine höhere Priorität beigemessen wird als dem Kochen, um zu Beginn eines Projekts eine gute Benutzererfahrung und eine angemessene Batterielebensdauer zu gewährleisten Schaltet einen sauber strukturierten Software-Stack und eine Methodik ein.

Wenn Sie ein iPhone 3G besitzen, hat Apple einige Betriebssystem-Updates veröffentlicht, die nur für neuere Geräte optimiert wurden. Spätere Betriebssystemupdates für das 3G bieten möglicherweise eine etwas bessere Leistung für das 3G.

hotpaw2
quelle
1
"Vorzeitige Optimierung ist manchmal schlecht, aber nicht, wenn es für eine gute Benutzererfahrung erforderlich ist", dann ist es keine vorzeitige Optimierung
Carlos Campderrós
1
Manchmal müssen Sie mit der Optimierung vieler Dinge beginnen, bevor Sie Messdaten zu den tatsächlichen Engpässen haben, die optimiert werden müssen. Andernfalls wird das System aufgrund einer Nachoptimierung, die den Zeitplan und die Leistung erfüllt, falsch aufgebaut.
hotpaw2
0

Der DVR benötigt so viel Zeit, um die Kanäle zu wechseln, da zuerst die gepufferten Daten ausgegeben und dann ein weiterer Puffer mit Daten für den neuen Kanal in die Warteschlange gestellt werden muss, den Sie gerade ansehen. Dieser Puffer wird höchstwahrscheinlich auf der Festplatte gespeichert, sodass diese Vorgänge einige Zeit in Anspruch nehmen (außerdem kann er den Puffer nur in Echtzeit füllen). Mit einem DVR sehen Sie niemals "Live" -Programme, es ist immer verzögert (nicht zufällig, es ist zeitgleich mit Ihrer wahrgenommenen Verzögerung beim Umschalten von Kanälen verzögert). Dies kann leicht überprüft werden, indem Sie ein Sportprogramm gleichzeitig mit dem Radiohören ansehen.

Dave Nay
quelle
Dies ist nicht ganz das, worauf ich mich bezog - mein Problem mit meinem DVR ist, dass es einige Sekunden dauert, bis eine Reaktion auf eine Operation angezeigt wird, auch auf die in seinen Menüs. Wenn ich zum Beispiel durch das Hauptmenü navigiere (keine Sendung anschaue) und auf der Fernbedienung die Taste NACH UNTEN drücke, dauert es einige Sekunden, bis sich die Bildschirmmarkierung um einen Punkt nach unten bewegt. Wenn ich beim Anschauen einer Sendung auf "Pause" drücke, gibt es eine Verzögerung von fünf Sekunden, bevor die Sendung pausiert. Wenn ich eine Aufnahme programmiere und in der Anleitung nach oben und unten blättere, dauert jeder Tastendruck viele Sekunden, um die Anzeige zu registrieren und zu ändern.
Crashworks
Ich bin mit dieser Aussage nicht einverstanden. Ich habe gerade von AT & T Uverse zu Comcast gewechselt und festgestellt, dass der DVR für Comcast im Vergleich zur Uverse-Box unglaublich langsam ist. Das mag ein Grund für eine Verzögerung sein, aber das bedeutet nicht, dass es der einzige Grund ist, warum die Box langsam ist.
Jetti
-2

Ich denke, der Grund dafür ist, dass die meisten Consumer-gesteuerten Apps von Leuten gesteuert und vermarktet werden, die nichts über Software wissen und Entwickler auf der Grundlage ihrer Lebensläufe oder der Empfehlungen eines No-nothing-Managers einstellen, im Gegensatz zu ihren tatsächlichen Fähigkeiten und Kenntnissen .

Vektor
quelle
2
Ohne eine Erklärung kann diese Antwort für den Fall unbrauchbar werden, dass jemand anders eine gegenteilige Meinung äußert. Wenn zum Beispiel jemand eine Behauptung aufstellt wie "Apps werden von großartigen Leuten kontrolliert und vermarktet, die großartige Entwickler einstellen" , wie würde diese Antwort dem Leser helfen, zwei gegensätzliche Meinungen zu ermitteln? Überlegen Sie , ob Sie es in eine bessere Form bringen
möchten