Windows Confidential: Ursachenforschung wird überbewertet
Wenn Sie in einem Programm auf rätselhaftes Verhalten stoßen, überlegen Sie sich ganz einfach, was Sie dagegen unternehmen können.
Raymond Chen
Fragen der Logik, wie etwas funktioniert lösen nicht alles. Es kann nur auf diese Weise beendet. Jedes Stück Software, vom einfachen zum komplexen, umfasst unzählige Entwicklungsstörungen Informationen. Manchmal nehmen diese Details Form von willkürlichen Entscheidungen.
Betrachten Sie z. B. einen Befehl, der zwei Parameter wie z. B. einen Benutzernamen und Dateinamen akzeptiert. Wenn Sie einen ungültigen Benutzernamen und einen ungültigen Dateinamen übergeben zufällig, ist es eine Platzwahl, die welche man als Fehler gemeldet werden. Wenn der Code geschieht, überprüfen zunächst den Benutzernamen ein, erhalten Sie wahrscheinlich einen Fehler "Ungültiger Benutzername".
Was ist die Begründung für die Wahl der Benutzername vor dem Dateinamen überprüfen? Es gibt wahrscheinlich nicht ein. Es ist gerade wie Dinge geschehen geschrieben worden. Es könnte auch einfach anders herum geschrieben worden sein.
Gelegentlich erhalten wir eine Anfrage von einem Kunden, die ein bestimmtes Verhalten wie diese beobachtet. Wenn sie feststellen, dass es verwirrend oder unerwünscht, sie werden sich Fragen: "Was ist der Grund für dieses Verhalten?"
Da Sie bereits Software-Ingenieure verstehen, dass ein bestimmtes Verhalten für eine beliebige Anzahl von Gründen existieren könnte. Es könnte ein Codefehler. Es könnte ein Entwurf versehen sein. Es könnte sein, etwas das engineering Team anders machen wollte, aber konnte nicht aus Gründen der Zeit, Ressourcen, Risiko oder Priorität. Es könnte auch eine vorsätzliche Entscheidung sein. Nur wenn das Verhalten in dieser letzten Kategorie fällt wird es jemals eine Begründung geben.
Wenn es fertig ist, geht
Sobald ein Produkt geliefert hat, ist jede Unterscheidung der Vernunft oder Logik weitgehend irrelevant. Das Produkt verhält sich, wie dies der Fall ist. Fragen Sie nach Änderungen in zukünftigen Versionen, aber die aktuelle Version ist beschlossene Sache. Eine Erklärung, warum das Produkt, wie verhält es tut (falls eine solche Erklärung überhaupt existiert) ändert nicht das Produkt oder dessen Verhalten. Alles, was sie tun kann ist zu besänftigen (oder sogar Wutanfall) Sie. Es beantwortet eine Frage, aber nicht lösen.
In vielen Fällen gibt es mehr zu, wenn ein Kunde stellt sich die Frage, "Was ist der Grund für dieses Verhalten?" Mehr als oft nicht, es ist wirklich nur Kurzform für, "Ich lief in einige Verhaltensweisen, die ich nicht erwartet hätte und es frustriert mich."
Besagt, dass Sie ein bestimmtes Verhalten frustrierend gefunden, ist viel nützlicher als für die Beweggründe für dieses Verhalten einfach zu Fragen. Es ist sogar nützlich, wenn Sie die Situation, die beschreiben zu entdecken das verwirrende oder unerwünschte Verhalten, das Sie frustriert geführt. Dieses Feedback könnte ein Entwurf versehen zu klären oder ein Codefehler aufmerksam machen. Es könnte sogar davon überzeugen, das engineering-Team, um zusätzliche Ressourcen zur Bewältigung dieser bestimmten Problems in Zukunft widmen ihre Prioritäten zu ändern.
Für die Beweggründe für ein Problem Fragen trägt die Unschuldsvermutung, die jedes Problem sollte behandelt werden, es sei denn, dass ein wichtiger Grund für etwas anderes zu tun. Das ist einfach nicht wie geschäftliche Entscheidungen erfolgen. Jede Änderung an ein vorhandenes Produkt muss die Risiken, Vorteile, Kosten und Priorität der Änderung auszugleichen.
Was ist der Grund für die Bildschirm-Herkunft wird in der oberen linken Ecke des Monitors? Was ist die Begründung dafür, dass nicht Sie \\server\ schreiben... \otherserver\share? Die Antwort ist eine sorgfältig begründeten Erklärung oder so etwas wie, "Weil ich schläfrig, war" ist nicht wirklich wichtig. Sie auftritt Ihr Problem immer noch.
Antwort angefordert
Es ist billig und einfach die Frage stellen, aber es stellt die Belastung der teuren höflich Antworten auf andere Menschen. Und die Leute raten, ob Ihre Frage ein passiv-aggressiv Feature-Request oder lediglich Neugier ist.
In beiden Fällen kann es dauern, eine enorme Menge an Zeit und Mühe, das Problem zu erforschen. Jemand müssen in den Archiven graben und finden Menschen vertraut mit der ursprünglichen Absicht des Features, die sich erinnern die Ergebnisse der Usability-Studien oder Untersuchungen der Kompatibilität (was für Features, die mehrere Jahre alt sind durchaus eine Herausforderung sein können). Dies könnte alles sich vergebliche Mühe sein, denn keine dieser Informationen wirklich ist, was Sie in erster Linie wollte.
Es ist weit mehr klar und sinnvoll zu erklären, die Ausgabe, die Sie gefunden und das Szenario, die dazu geführt haben, so dass Ihr Antrag auf eine Änderung im Verhalten besser verstanden werden kann. Andernfalls kann Ihre Anfrage nach einer Erklärung des Denkprozesses, die in ein bestimmtes Verhalten ging als pingelig Frage stoßen, die machen Leute fragen, ob es dann auch reagiert der Mühe Wert sein.
.jpg)
Raymond Chender Web-Site, The Old New Thing, und identisch mit dem Titel Buch (Addison-Wesley, 2007) befassen sich mit der Geschichte von Windows, Win32-Programmierung und Masse-Quellen Traum-Analyse.