Per me, Idiot Proofing significa semplicemente assicurarsi che l'utente non possa rompere un pezzo di software anche se ci provasse. Ad esempio, se un valore viene letto da una casella di testo e viene convertito in doppio, se il software sottostante è a prova di idiota, non si interromperà se l'utente digita un valore non doppio.

Di recente ho redatto un programma di sviluppo e uno degli elementi è stato chiamato "UI proof Idiot". Le persone che sto costruendo questo software hanno scherzato finto offesa al termine, ma posso vedere dove questo termine renderebbe davvero le persone arrabbiate.

Qual è un modo migliore per dirlo?

Se stai includendo "II proof UI" come elemento di pianificazione, stai solo cercando di aggiungere qualità al tuo software. Qualsiasi sistema ben progettato convaliderà i suoi input e fornirà una chiara guida agli utenti, ovviamente, non è qualcosa che viene inserito nel programma come un elemento discreto (che è quindi soggetto a rimozione quando l'inevitabile crunch colpisce).

In alternativa, se deve essere un elemento discreto (so come alcune organizzazioni pensano alla pianificazione), "UI proof idiot" dovrebbe essere modificato in "Input Validation Library" e spostato all'inizio della pianificazione.

Convalida dell'input dell'utente Avrei pensato che fosse un termine professionale. Tuttavia, non vedo nulla di male nell'impermeabilità se usato nei documenti interni.

Indurimento è una buona parola. Se qualcuno lo chiede, digli che il primo passaggio sul software è solitamente scritto per scenari ideali e, come per gli strumenti in acciaio, il software deve essere "indurito" verso un utilizzo quotidiano da parte dei clienti reali.

Robustificazione è un'altra buona parola per questo: stai rendendo il codice robusto per i tipi di sfide che i clienti reali dovranno affrontare.

Entrambe le parole suonano fredde e industriali, non incolpano gli utenti o i programmatori e capiscono il punto.

A proposito, ecco la vecchia mascotte di Metrowerks, Arnold, il ragazzo che ci aiutava a programmare Mac indurendo e rinforzando il nostro codice con una fornace per trattamento termico, una fucina, un'incudine e una piccola mazza:

Programmazione difensiva

È ciò che mi è stato insegnato. Ai tempi in cui dovevamo tagliare i nostri pezzi di legno.

Se vuoi essere un PC, chiamalo programmazione "anticipatoria".

Quando stavo imparando, lo chiamavamo a prova di proiettile .

Anche la maggior parte degli altri eufemismi che ho letto si applicano.

Che ne dite di sistema o interfaccia utente "Fault tolerant"?

"Idiot proofing" dovrebbe consistere in entrambi

• progettare l'interfaccia utente in modo che sia facile da usare e induca l'utente a inserire i dati nel modo previsto dai programmatori e

• testare l'interfaccia utente per determinare se l'interfaccia può essere rotta inserendo valori di dati imprevisti.

Entrambe le fasi potrebbero ragionevolmente apparire nel programma di sviluppo in cui il progetto viene esaminato da un esperto dell'esperienza utente e in cui il codice fornito viene verificato da un tester per garantire che i dati non validi vengano gestiti correttamente (per qualunque cosa "correttamente" significhi per la tua applicazione).

La prova dell'idiota implica molto più della semplice convalida dell'input. Non includerei nemmeno una cosa del genere nella sua definizione.

La convalida dell'input è un processo in cui si disinfettano e si convalidano i dati utente per eliminare valori illegali / senza senso. Questo dovrebbe sempre essere fatto con qualsiasi informazione proveniente dall'esterno del programma in modo da eliminare l'ovvio e proteggersi dagli attacchi (ad esempio attacchi di iniezione sql).

Considererei la prova dell'idiota come un insieme di logiche per impedire all'utente di causare accidentalmente danni ingenti a se stesso attraverso mezzi altrimenti legali.

Ad esempio, fare rmrifiutare il comando rm -rf /e chiudere le varianti non ha nulla a che fare con la convalida o la correttezza. È un comando perfettamente valido. Sfortunatamente, è un comando che potrebbe e può cancellare tutti i tuoi dati da tutti i tuoi dischi in Unix / Linux. A prova di idiota questo respingerebbe questo comando e suggerirebbe rm -rf --i-really-mean-this /, o se in modalità interattiva, di inserire una risposta affermativa dopo un avviso.

Tutto ciò che è distruttivo per il sistema dovrebbe essere a prova di idiota. Qualunque cosa che possa causare un potenziale imbarazzo potrebbe anche essere un candidato (ad esempio "sei sicuro di voler inviare questa email senza un allegato anche se ne hai menzionato uno nel tuo testo?" E "sei sicuro di voler inviare questa email al intera azienda? ")

Idiot proofing è una collaborazione tra QA (cercando di essere il miglior idiota) e sviluppo (cercando di anticipare tutti questi scenari e progettarli attorno).

Per quanto riguarda un sinonimo più amichevole , posso suggerire "analisi distruttiva del percorso del codice" o "abilitare il feedback degli utenti per operazioni critiche". Qualunque cosa tu possa chiamarlo, dovresti davvero avviarlo il più presto possibile nel processo di progettazione.

"Sanity Checking" tende a funzionare abbastanza bene abbastanza spesso ...

Chiamalo "aggiungere Poka-giogo all'interfaccia utente". http://en.wikipedia.org/wiki/Poka_yoke

"Gestione degli errori" o "convalida dell'input" sarebbero altri termini che userei per quello che descrivi. Bulletproof sarebbe un altro termine che potrei vedere essere usato in alcuni ambienti poiché l'idea qui è di rendere il software abbastanza robusto da gestire quasi tutto. Roccia solida sarebbe un'altra frase gergale che potrei immaginare qualcuno che voglia usare anche qui.

"Peggior scenario di casi". Perché, come sviluppatori, sappiamo tutti che se può essere fatto, allora sarà fatto . Quindi devi solo essere pronto a gestire la situazione peggiore con il tuo software.

Le misure di sicurezza non sono solo un modo per proteggere gli utenti da invasioni informatiche esterne, ma anche contro se stessi. Viviamo in un mondo imperfetto con utenti imperfetti.

La doratura è il termine educato (e dal suono molto positivo) che uso quando parlo del miglioramento dell'esperienza dell'interfaccia dell'utente finale in qualsiasi modo (GUI o altro).

La prova dell'idiota, come dici tu, è la parte più grande di quel processo, insieme ai miglioramenti del design o del flusso di lavoro (pensa al riconoscimento del feedback degli utenti finali).

L'idea qui è che puoi usare quel termine liberamente nell'ambiente di lavoro ed è visto come un processo prezioso (una volta completato) sia dalla direzione che dagli utenti, anche se potrebbe richiedere del tempo (e quindi in genere costa un po 'di denaro).

molti altri termini relativi a questo processo (spesso di fine ciclo) fanno sembrare questo processo:

• implica gli utenti (spesso la gestione ;-) sono stupidi
• è difficile da raggiungere
• ha poco valore netto

Associando l'oro al processo (di solito il metallo equivaleva a "valore" anziché "costo"), ho visto il processo trasformarsi da spesa in investimento in mentalità di alcuni manager.

È come affermare apertamente che fino a quando questo non viene fatto, quel grosso pezzo di acciaio non è ancora gioielli. Ma una volta placcato ... allora è prezioso.

Il più delle volte usando in relazione ai processi di produzione, ma penso che Poka-Yoke sia davvero adatto :

"[poka yo-ke] è un termine giapponese che significa" fail-safing "o" a prova di errore "

Originariamente era descritto come baka-yoke, ma poiché questo significa "a prova di sciocco" (o "a prova di idiota") il nome è stato cambiato in un poka-giogo più mite.

Più in generale, il termine può riferirsi a qualsiasi vincolo di modellizzazione del comportamento progettato in un prodotto per impedire operazioni errate da parte dell'utente. "

Un termine comune nei negozi più grandi è anche Quality Assurance (QA) .

È un termine generico e vago, che puoi modellare secondo il tuo significato specifico all'interno del tuo ciclo di rilascio.

Lo chiamiamo prova umana. Siamo tutti idioti.