Vie secrète de Windows : La raison est fortement surestimée
Si vous remarquez quelque chose de curieux dans un produit, choisissez correctement votre façon de réagir.
Raymond Chen
Poser des questions sur la logique de fonctionne de quelque chose ne résolvent rien. Il pourrait ont juste fini de cette façon. N'importe quel morceau de logiciel, du simple au complexe, comprend d'innombrables Détails du développement. Ces détails prennent parfois la forme de choix arbitraires.
Prenons, par exemple, une commande qui accepte deux paramètres, un nom d'utilisateur et nom de fichier. S'il vous arrive de passer un nom d'utilisateur non valide et un nom de fichier non valide, c'est un toss-up dont l'un sera signalé comme une erreur. Si le code arrive à vérifier en premier lieu, le nom d'utilisateur, puis vous obtiendrez probablement une erreur « nom d'utilisateur non valide ».
Quelle est la justification d'avoir choisi vérifier le nom de l'utilisateur avant le nom de fichier ? Il n'est probablement pas une. C'est juste comment les choses arrivées ont été rédigés. Il pourrait tout aussi facilement ont été écrits le sens inverse.
Nous recevrons occasionnellement une demande d'un client qui observe un certain comportement comme ça. Si ils le trouvent déroutant ou indésirables, ils vont demander, « quelle est la justification de ce comportement? »
Comme les ingénieurs en logiciel, vous avez déjà comprennent qu'un comportement particulier pouvait exister pour diverses raisons. Il pourrait être une erreur de code. Il pourrait être un oubli de la conception. Il pourrait être quelque chose de l'équipe d'ingénieurs voulais faire différemment, mais n'a pas pu pour des raisons de temps, de ressources, de risque ou de priorité. Il pourrait également être une décision intentionnelle. Seulement si le comportement tombe dans cette dernière catégorie va y avoir une raison d'être.
Quand c'est fait, c'est fait
Une fois qu'un produit est expédié, toute distinction de la raison ou justification est largement hors de propos. Le produit se comporte comme il le fait. Vous pouvez demander des changements à l'avenir versions, mais la version actuelle est un fait accompli. Une explication de pourquoi le produit comporte de la façon dont il le fait (si une telle explication existe encore) ne modifie pas le produit ou son comportement. Tout cela pourrait faire est apaiser (ou même faire enrager) vous. Il répond à une question, mais ne résout pas un problème.
Dans bien des cas, il ya plus à lui lorsqu'un client pose la question, « Quelle est la justification de ce comportement? » Plus souvent qu'autrement, c'est vraiment juste raccourci pour, « je suis tombé sur un comportement que je ne m'attendais pas, et il frustré moi. »
Indiquant que vous avez trouvé un comportement particulièrement frustrante est beaucoup plus utile que de simplement demander la raison de ce comportement. Il est encore plus utile si vous décrivez la situation qui a conduit à découvrir le comportement déroutant ou indésirable qui vous frustré. Cette rétroaction pourrait clarifier une surveillance en matière de conception ou attirer l'attention sur une erreur de code. Il pourrait même convaincre l'équipe d'ingénieurs à modifier leurs priorités afin de consacrer des ressources supplémentaires pour régler ce problème à l'avenir.
Demandant la raison d'être un problème porte la présomption que chaque question soit adressée à moins que des principales raisons de faire autrement. C'est tout simplement pas comment les décisions d'affaires sont prises. Tout changement à un produit existant doit équilibrer les risques et avantages, coût prioritaire d'apporter le changement.
Quelle est la justification de l'origine de l'écran dans le coin supérieur gauche de l'écran ? Quelle est la justification pour ne pas permettre d'écrire \\server\... \otherserver\share ? Si la réponse est une explication soigneusement motivée ou quelque chose comme, "Parce que j'étais endormie," peu importe. Vous ressentez toujours votre problème.
Réponse requise
Il est bon marché et facile à poser une question, mais il met à la charge des réponses polies chers sur d'autres personnes. Et ces gens doivent deviner si votre question est une demande de fonctionnalité passif-agressif ou simplement ralentie curiosité.
Dans les deux cas, il peut prendre énormément de temps et d'efforts à la recherche du problème. Quelqu'un devra fouiller dans les archives et trouver des personnes familières avec l'intention initiale de la fonctionnalité qui se souviennent des résultats des études ou enquêtes de compatibilité (qui peuvent être un défi de taille pour les fonctionnalités qui sont vieux de plusieurs années). Cela peut tous se pour révéler gaspillage d'efforts parce qu'aucun de ces renseignements est vraiment ce que tu voulais au départ.
Il est beaucoup plus claire et utile pour expliquer le problème que vous avez trouvé et le scénario qui a eu pour conséquence, si votre demande de changement de comportement peut être mieux compris. Dans le cas contraire, votre demande pour obtenir une explication du processus de réflexion qui est entré dans un comportement particulier peut apparaître comme une question de dire qui va rendre les gens me demande si ça va encore être vaut la peine de répondre.
.jpg)
Raymond ChenWeb site, The Old New Thing et même intitulée livre (Addison-Wesley, 2007) traitent de l'histoire Windows, programmation Win32 et analyse des rêves de foule de source.