Windows-informazioni riservate: La logica è altamente sopravvalutata
Se si presenta un aspetto problematico con un prodotto, è opportuno effettuare la scelta più produttiva nella modalità di intervento.
Raymond Chen
Chiedendo la logica come qualcosa funziona non risolve nulla. Potrebbe avere appena concluso in questo modo. Qualsiasi pezzo di software, dal semplice al complesso, comprende innumerevoli dettagli sullo sviluppo. A volte quei dettagli assumono la forma di scelte arbitrarie.
Si consideri, ad esempio, un comando che accetta due parametri come ad esempio un nome utente e nome del file. Se vi capita di passare un nome utente non valido e un nome file non valido, si getta-in su che uno sarà riportato come errore. Se il codice accade per verificare il nome utente in primo luogo, allora probabilmente si otterrà un errore "nome utente non valido".
Qual è la motivazione per la scelta di verificare il nome utente prima del nome del file? Non c'è probabilmente uno. È proprio come le cose successo sono state scritte. Si potrebbe altrettanto facilmente sono stati scritti l'altro senso intorno.
Noi riceverai occasionalmente una richiesta da un cliente che osserva un certo comportamento come questo. Se lo trovano confusione o indesiderato, ti chiedono, "Che cosa è la motivazione per questo comportamento?"
Come ingegneri del software, hai già capiscono che un particolare comportamento potrebbe esistere per qualsiasi numero di motivi. Potrebbe essere un difetto del codice. Potrebbe essere una svista di design. Potrebbe essere qualcosa del team di progettazione ha voluto fare in modo diverso, ma non poteva per ragioni di tempo, risorse, rischio o priorità. Potrebbe anche essere una decisione intenzionale. Solo se il comportamento rientra in tale ultima categoria ci sarà mai una spiegazione logica.
Quando è fatto, è fatto
Una volta che un prodotto ha spedito, alcuna distinzione di ragione o logica è in gran parte irrilevante. Il prodotto si comporta come lo fa. È possibile chiedere cambiamenti in futuro versioni, ma la versione attuale è un affare fatto. Una spiegazione del perché il prodotto si comporta il modo lo fa (se esiste anche una spiegazione di tale) non cambia il prodotto o il suo comportamento. Tutto quello che potrebbe fare è mollify (o anche imbestialire). Esso risponde a una domanda, ma non risolve un problema.
In molti casi, non c'è più ad esso quando un cliente chiede la domanda, "Qual è il razionale per questo comportamento?" Più spesso, è davvero solo stenografia per, "mi sono imbattuto in alcuni comportamenti che non mi aspettavo e frustrato me."
Affermando di aver trovato un particolare comportamento frustrante è molto più utile di semplicemente chiedendo le motivazioni di tale comportamento. È ancora più utile se si descrive la situazione che ha portato a scoprire il comportamento confusionario o indesiderato che voi frustrati. Che il feedback potrebbe chiarire una svista di design o attirare l'attenzione su un difetto del codice. Potrebbe anche convincere il team tecnico di alterare le loro priorità per dedicare risorse aggiuntive per affrontare quel particolare problema in futuro.
Chiedendo la logica dietro una questione trasporta la presunzione che ogni problema deve essere affrontato a meno che non vi è un'importante ragione per fare altrimenti. Che è non solo come vengono prese le decisioni aziendali. Qualsiasi cambiamento di un prodotto esistente deve bilanciare il rischio, benefici, costi e priorità di apportare la modifica.
Qual è la motivazione per l'origine dello schermo essendo all'angolo superiore sinistro del monitor? Che cosa è la motivazione per non consente di scrivere \\server\... \otherserver\share? Se la risposta è una spiegazione accuratamente motivata o qualcosa di simile, "Perché ero assonnato," davvero non importa. Che stai ancora vivendo il tuo problema.
Risposta necessaria
È economico e facile da fare una domanda, ma si mette l'onere di costose gentile risposte su altre persone. E quelle persone hanno di indovinare se la tua domanda è una richiesta di funzione passivo-aggressivo o semplicemente folle curiosità.
In entrambi i casi, può prendere una quantità enorme di tempo ed energie alla ricerca del problema. Qualcuno dovrà scavare negli archivi e trovare persone familiari con l'intento originale della caratteristica che ricorda i risultati di usabilità studi o indagini di compatibilità (che possono essere abbastanza una sfida per le caratteristiche che sono parecchi anni). Questo potrebbe tutti risultano per essere fatica sprecata perché nessuna di queste informazioni è davvero quello che si voleva in primo luogo.
È molto più chiaro e utile per spiegare il problema che hai trovato e lo scenario che ha condotto ad esso, così la richiesta di un cambiamento nel comportamento può essere meglio compresa. In caso contrario, la richiesta per una spiegazione del processo di pensiero che è andato in un particolare comportamento può venire attraverso come una domanda pignoli che renderà persone chiedo se sarà ancora vale la pena di rispondere.
.jpg)
Raymond Chendi Web site, The Old New Thing e identicamente intitolato libro (Addison-Wesley, 2007) trattare con storia di Windows, programmazione Win32 e folla di origine sogno analisi.