it-swarm-es.com

¿Qué errores hacen los errores y cómo puede actualizar su solicitud para manejarlos?

De hecho, esta pregunta es sobre las precauciones que deben tomarse para mejorar la experiencia del usuario de la calidad y reducir las llamadas de apoyo evitables.

12
Maniero

La falta de validación de insumos adecuada es una de esas cosas que tiende a conducir con bastante rapidez a los usuarios que realizan cosas "malas" con su solicitud, cuando realmente debe ser manejado por el programador.

He visto aplicaciones heredadas donde los usuarios han sido entrenados para:

  • no entrar a apóstrofes en los nombres
  • no ingrese ningún símbolo que no sea a-z0-9,
  • asegúrese de que no haya espacios antes o después del texto que hayan ingresado
  • compruebe que se está ingresando una dirección de correo electrónico correctamente formateada en el campo email, de lo contrario, los correos posteriores a ese usuario usarán lo que esté en el campo y fallará
  • cerciorarse "http:// "se pone antes de las direcciones web

etcétera etcétera

Todos los problemas anteriores son los que deben ser manejados por un desarrollador de aplicaciones. Cuando su validación de entrada es esencialmente "Asegúrese de que el usuario sepa en qué formato debe estar en este campo y confiar en lo que han ingresado es correcto", las cosas inesperadas están obligadas a encontrar su camino en la aplicación. Aparte de las implicaciones de seguridad obvias, los usuarios cometen errores. Como programadores, a menudo producimos nuestros mejores productos al inclinarse sobre el revés para asegurarse de que el usuario no puede ¡Hágalo mal, sin importar qué tan difícil intenten!

25
ConroyP

Una vez recibí una llamada de atención al cliente porque mi aplicación simplemente desapareció. Resultó que abrieron otra aplicación encima de ella.

... Decidí no asegurarme de que no volvería a suceder, ya que era el analfabetismo informático de los usuarios que causó el problema, no la aplicación. Cualquier cosa que pueda haber hecho para arreglarlo habría llevado a una experiencia de usuario deficiente para otros.

7
John MacIntyre

Casi todos los programas que escribo se invocan estrictamente de la línea de comandos. También he escrito algunas cosas más fantasías que comenzaron a medida que CLI interfaces y se convirtió rápidamente en algo más cáscara que nada.

Entonces, puedo hablar solo por lo que sé. Aquí hay algunos problemas comunes con los programas de línea de comandos:

manera demasiadas opciones

A menos que esté escribiendo un compilador o un editor de líneas, intente mantener las opciones limitadas a una pantalla llena en un búfer de marco 80x25 cuando --help o /? se pasa. Está perfectamente bien tener más opciones que eso, pero romperlas en subcategorías. Por ejemplo

foo --help

foo --help option_name

sin opciones largas

Es mucho más fácil recordar foo --attach_to [argument] --volatile --verbose de lo que es recordar foo -a [arg] -v +V. Esto no siempre es posible, pero en la mayoría de los casos, es.

sin validación de entrada

Casi todas las plataformas tienen múltiples bibliotecas que se prueban, probadas y verdaderas cuando se trata de analizar y validar argumentos. Casi todas las plataformas tienen un lexer probado, probado y verdadero que valida la entrada de una CLI. Use uno, el otro o ambos. Si su programa SEGFAULTS o se divide por cero debido a algo que se proporciona un usuario, eso es simplemente embarazoso.

Es posible que no necesite algo tan complejo como un lexer, quizás pueda perfeccionar la cadena si está esperando cosas en un orden determinado con ciertas cosas en ciertos lugares.

En realidad, recibí un informe de errores una vez que se esperaba un entero y alguien escribió f*** my life en las cotizaciones. No escribí ese programa, tuve la desgracia de heredarla.

no 'mando' verbocity '

Permitir que los usuarios experimentados descubran fácilmente cómo obtener más ruido de su programa de lo que la mayoría de las personas lo tolerarían, pero solo se imprima solo cosas serias y críticas. No puedo decirle cuántas veces tuve que disparar strace solo para darse cuenta de que algo segado por cil destinado porque funcionó en un flujo de archivos nulos.

También puede envolver las afirmaciones para que los rechazarlos a través de Ndebug u otros medios aún resultan en algo impreso o registrado para el usuario para encontrar.

Hablando de archivos de registro, intente asegurarse de que cualquier cosa que coloques haga (al menos un poco) con alguien que no sea usted. Si el inicio de cada entrada es una fecha de época de UNIX, va a comprobar la frustración en alguien que realmente quiere ayudarlo a reproducir el error.

no 'Bugdy Buddy' en modo de depuración

Muchos programas ofrecen algún tipo de interruptor de 'depuración' que ofrece charlas adicionales con respecto a lo que está sucediendo con el programa, pero muy pocas ofrecen lo siguiente:

  • Una forma de enviar automáticamente un informe a través de http/https y obtener algún tipo de número de referencia de servicio
  • Una forma de volcar la información útil a un archivo que podría ser enviado como un archivo adjunto a una solicitud de soporte

O, quizás le guste escuchar a las personas lean lo siguiente por teléfono:

Dice una condición inesperada en Zero Eff oh Four Zero Oh ... ok Lemme leíale eso de vuelta a usted ...

archivos de configuración excesivamente complejos

No justifique la necesidad de analizar una configuración como una excusa para obtener un zumbido en un montón de azúcar sintáctico. Trate de usar un formato que la gente realmente sepa, incluso si significa trabajo adicional al analizar. Intento usar el INI Siempre que sea posible. Se sorprenderá de lo que puede quitar con un diccionario de clave simple-> valor.

sin archivos de configuración

No haga que la gente escriba scripts de Shell o archivos por lotes solo para usar su programa, a menos que se pretendiera que sea una herramienta para cualquiera de las tareas. Dame un medio para señalar un archivo que contenga mis opciones habituales y proporcione solo algunos argumentos adicionales.

No 'Signos' Suelo mojado '

Si alguna función podría poner en peligro al usuario (quizás esté allí para usuarios avanzados), marquelo claramente como tal. Además, si alguien gordas los dedos aportan u olvida algo, ¿debe programar imprimir un enlace muy amigable a la documentación en línea? Puede estar tratando con alguien que esté utilizando su programa a través de KVM y no se puede cortar y pegar.

Cuando sea posible, (esto coincide con la validación de entrada) Use el Google Apporach:

¿Quisiste decir foo --bar filenme, escribiste solo foo --bar

ofrezca una salida a las instrucciones destructivas

El objetivo es decirle al usuario por qué no funcionó y hacer que intenten unas cuantas veces más, mientras se aseguran de que no hagas nada potencialmente destructivo a menos que parezca que el usuario realmente quiere que hagas eso. Permita un interruptor que desactiva 'Nagging', por ejemplo -Y o /Y Pero de lo contrario, permite una salida para alguien que simplemente tiene "fingeres gorras".

Probablemente estoy olvidando algunos punteros. Me ocupo de esto con frecuencia, ya que es muy difícil hacer que la interfaz "bajo nivel" para algo intuitivo lo suficiente para que la mayoría de las personas eviten cometer errores.

7
Tim Post

No tengo ganas de obtener ejemplos específicos de interrupciones/reparaciones es tan importante como si se data de la realización de esto:

  • Los usuarios no leen su manual, o vean sus tutoriales. Ellos aprenden su software a través de la exploración.

Si a través de esa exploración rompe algo, como programador, es su trabajo advertirles sobre el peligro o evitar que suceda en primer lugar. No puedo recordar dónde lo vi ahora, sino en la parte de atrás de mi mente, siempre intento " hacer que hacer lo correcto sea fácil "para el usuario de mi software.

Si insistes en los ejemplos:

  • El usuario pudo ingresar un nombre en minúsculas que rompió el código de integración/fijado al realizar la validación de entrada
  • El usuario pudo hacer clic en el botón incorrecto después de realizar una acción/fija solo mostrando los botones correctos.
  • El usuario pudo hacer x accidentalmente/arreglado al advertirles que están a punto de hacer X.

¿Ves a dónde va esto? :)

3
mpeterson

Aquí hay uno que escuché esta semana. Un usuario solicita una función "Envíeme una notificación cuando ocurra un evento". Lo suficientemente simple y el desarrollador sigue adelante e implementa. Claro, la primera pregunta debería haber sido "¿Qué están tratando de abordar esta notificación?". No voy a entrar en eso. Pocos días después, el usuario se detiene por el desarrollador y le pregunta "Tengo esta notificación. ¿Qué se supone que debo hacer con eso?".

Recordé este cómic Dilbert y sugerí al desarrollador "Escribir una aplicación para averiguar qué debe hacer el usuario con esa notificación".

Como dijo MPETERSON, el usuario es muy competitivo en su área de especialización. Simplemente no piensan como un desarrollador de software o diseñador.

3
James

"¿Está seguro de que desea eliminar este archivo/registro? Sí/No". Hizo clic en Sí y luego recibió una llamada que "erróneamente" hizo clic en el botón Red Eliminar y necesita ese DATOS ATRÁS :)

3
Quamis