Valores predeterminados: ¿son buenos o malos?


12

La pregunta sobre los valores predeterminados en general: valores de función de retorno predeterminados, valores de parámetros predeterminados, lógica predeterminada para cuando algo falta, lógica predeterminada para manejar excepciones, lógica predeterminada para manejar las condiciones de borde, etc.

Durante mucho tiempo consideré que los valores predeterminados eran algo "puro malvado", algo que "oculta la catástrofe" y resulta muy difícil de encontrar errores. Pero recientemente comencé a pensar en los valores por defecto como una especie de deuda técnica ... lo cual no es algo malo pero algo que podría proporcionar algo de "financiamiento a corto plazo" para que sobrevivamos al proyecto (cuántos de nosotros podríamos pagar comprar una casa sin sacar la hipoteca?

Cuando digo un "corto plazo", no quiero decir, "haga algo rápidamente primero y refactorícelo más tarde antes de que llegue a la producción". No, estoy hablando de confiar en valores predeterminados codificados en un software de producción. Por supuesto, podría causar algunos problemas, pero ¿qué pasaría si solo causara un solo problema en todo un año?

Una vez más, estoy hablando del software convencional "promedio" aquí (no un software para una estación de energía nuclear), el sitio web promedio o una aplicación de interfaz de usuario para el software de contabilidad, lo que significa que las vidas de las personas no están en juego, ni millones de dólares .

Una vez más, desde mi experiencia, los usuarios comerciales preferirían vivir con el software que "funciona de alguna manera", en lugar de esperar por uno perfecto. Y el uso de valores predeterminados ayuda mucho si desarrolla un software en un estilo RAD. Pero, una vez más, las sesiones de depuración más largas que he pasado se debieron a los errores introducidos por un valor predeterminado que dejó de ser "predeterminado" en el camino o porque recientemente se actualizó un pequeño subsistema y, como resultado de esta actualización, no manejar el valor predeterminado correctamente (por ejemplo, lista vacía vs nulo, o cadena nula vs cadena vacía).

Entonces mi pregunta es: ¿los valores predeterminados son buenos o malos? Y si son una deuda técnica, ¿cómo puede calcular cuánto puede pedir prestado para poder pagar los reembolsos?

Realmente agradecería cualquier aporte.

Salud.

EDITAR:

Si estoy usando los valores predeterminados como una forma de cortar las esquinas durante el desarrollo, y si el corte de las esquinas resulta en errores y problemas, ¿cuál es la metodología para recuperarse de estos problemas?

Respuestas:


23

El concepto de Convención sobre Configuración es imposible sin valores predeterminados razonables . La palabra clave aquí es "sensible". Los valores predeterminados tienen que tener sentido para al menos el 80% (si no más) de todos los usos de una biblioteca / servicio / marco.

Reglas generales generales:

  • Si un valor es sensible para 80% o más usos, debe ser un valor predeterminado
  • Si no hay valores que se usan para la mayoría de los casos, no use los valores predeterminados.
  • Los valores predeterminados evitan errores estúpidos del código de configuración. Si los valores predeterminados son razonables para la mayoría de los casos, menos personas se meten con la configuración de trabajo.
  • Las configuraciones no estándar son más visibles cuando utiliza valores predeterminados.
  • Los valores predeterminados incorrectos son peores que ninguno .

Esencialmente, una vez que aprende cómo funciona la configuración predeterminada, puede tomar decisiones informadas sobre cómo / cuándo hacer configuraciones no estándar.


Gracias por señalarme al concepto "Convención sobre configuración". Lo usé sin saber que tiene un nombre. ¿Puede explicar esta regla: "Las configuraciones no estándar son más visibles cuando utiliza valores predeterminados". Por favor.

3
@ Andrew si hay una docena de llamadas Foo()y una llamada a Foo("bar"), esa llamada tiende a destacarse y, por lo tanto, es más visible.
Matthew Scharley

1
Correcto, y si la mayoría de los usos de un servicio FTP utiliza new FtpService()el que establece un puerto alternativo, se destacará ( service.SetPort(12345)).
Berin Loritsch

43

Tomemos, por ejemplo, una biblioteca que implementa el protocolo FTP. Por defecto, se espera que FTP opere en el puerto 21. Ahora estaría muy irritado si tuviera que especificar usar el puerto 21 cada vez que construya un objeto de una clase FTP aleatoria. Si necesito un puerto diferente, déjame especificar.

Los valores predeterminados están perfectamente bien cuando son valores razonables.


21
+1. ¿Cuándo fue la última vez que escribiste http://programmers.stackexchange.com:80/questions/?sort=newest&pagesize=50en una barra de direcciones?
Jörg W Mittag

1
Entonces, ¿cómo se mide / estima / ect un nivel de cordura de la variable predeterminada.

55
Cuánto tiempo lleva pensar en un valor predeterminado razonable.
Alexander Gessler

1
@ Andrew, mira mi respuesta a continuación. Si un valor es bueno para 80% o más usos, es un buen valor predeterminado.
Berin Loritsch

2
@Berin Loritsch: Si el valor predeterminado se usa para fallar de manera segura, podría argumentar que es bueno incluso cuando se usa solo el 1% del tiempo.
oosterwal

18

Probablemente esté utilizando una distribución de teclado predeterminada con asignaciones de teclas predeterminadas, asignaciones de botones de mouse predeterminadas, el navegador predeterminado, escribiendo en el idioma predeterminado del sistema, iniciando desde el sistema operativo predeterminado en el cargador de arranque, menús posicionados predeterminados, esquema de color predeterminado, fuente predeterminada ancho / alto / cara / estilo, juego de caracteres por defecto, resolución de monitor por defecto, por defecto ... ya tienes la idea.

Pero con toda seriedad, creo que la preocupación que tienes no es con los valores predeterminados sino con otra cosa. El comportamiento predeterminado no oculta errores inherentemente. La mayoría de las veces su código se ejecutará en condiciones comunes de todos modos, independientemente de si establece o no los valores predeterminados. Los casos extremos no controlados son cosas que querrá asegurarse de evitar independientemente (presumiblemente a través de pruebas adecuadas y adecuadas), para cuando se cambian los valores predeterminados o ocurre un escenario poco común.

Además, el manejo de excepciones "general" es posiblemente un defecto de diseño en lugar de cualquier cosa que se pueda llamar "predeterminado".


OK, "catch-all" en realidad es un buen ejemplo. Sí, está causando mucho dolor cuando algún día algo sale mal por alguna razón desconocida, y estos "algunos" son desconocidos en gran parte porque la verdadera excepción se perdió en un bloque general. Entonces es algo malo, ¿verdad? Por otro lado, sin un bloque general, el software podría estar muriendo por completo (si no se maneja la excepción) o requeriría una lógica complicada de manejo de errores (al menos tendría que registrar la excepción e inicializar algunos datos con un valores predeterminados).

Entonces, para agregar a mi pregunta original, si estoy usando los valores predeterminados como una forma de reducir las esquinas durante el desarrollo, y si el corte de las esquinas resulta en errores y problemas, ¿cuál es la mejor manera de recuperarse de estos problemas?

1
En cuanto a las excepciones, hay un artículo que dice que debería haber una excepción general por hilo , si es que hay alguna. Se usaría para informar errores, por lo que está viendo el programa como una "cosa" única de la misma manera que el SO vería un proceso. Dado que tiene al usuario final (y con suerte a los desarrolladores) en el bucle, en realidad no está "tragándose" la excepción, así que todo está bien. Artículo aquí: codeproject.com/KB/architecture/exceptionbestpractices.aspx
Rei Miyasaka

1
En cuanto al uso de valores predeterminados para evitar errores, ¿qué tal si usas un comentario coherente para controlar + f / mac + f? Por ejemplo, Visual Studio realmente muestra cualquier comentario que comience TODO: or TEMP:en la lista de tareas. Si alguna vez estoy cortando una esquina por el bien del desarrollo, trato de ser extremadamente cuidadoso para asegurarme de poner un TODO allí; luego, de vez en cuando, haré un "encontrar todo" para regresar y asegurarme nada de eso entra en ninguna construcción importante.
Rei Miyasaka

Vaya, quise decir usar valores codificados para ayudar al desarrollo. Por cierto, me acabo de dar cuenta de que "valores codificados" es probablemente la palabra que estás buscando, en lugar de "valores predeterminados".
Rei Miyasaka

3

Los valores predeterminados se deben usar cuando evitan que el usuario o desarrollador realice tareas repetitivas. Nunca deben usarse para enmascarar errores o excepciones. No es una mala práctica usarlos para evitar errores, pero solo mientras la prevención no oculte que algo malo está sucediendo. Los valores predeterminados son una herramienta como todo lo demás. Si se usan correctamente, pueden ahorrarle mucho dolor de cabeza y tiempo. Si se usan incorrectamente, pueden derribar toda la casa.


Algo así como C ++ volando toda la pierna ...
Mateen Ulhaq

1
@muntoo: Hola, Lisp me dio una cojera en el '03.
Joel Etherton el

3

La causa raíz de los problemas que usted cita no son los valores predeterminados per se, sino los problemas de integración debido a cambios en los contratos de interfaz, malentendidos de interpretación y / o suposiciones inválidas. Básicamente, todos estos (ejemplos específicos) parecen ser el resultado de una comunicación inadecuada , entre el cliente y el desarrollador, o entre diferentes desarrolladores / equipos. Es justo que estos problemas puedan manifestarse como valores predeterminados no válidos, pero también en innumerables formas.

Maneje la causa raíz, no el síntoma.

Y tenga en cuenta también que, como otros han señalado con excelentes ejemplos, los valores predeterminados, cuando se usan con prudencia, pueden facilitar significativamente la vida de los usuarios. Y ese es en última instancia nuestro objetivo, ¿no?


La "comunicación inadecuada" podría ser la causa raíz, pero ¿no es la causa raíz de casi nada? Y dado que "mi objetivo final" es entregar un software "suficientemente bueno" a tiempo en un entorno con costos limitados, quería saber cómo distinguir los valores predeterminados malos / malos de los buenos.

@ Andrew, la comunicación (o la falta de ella) es un factor importante en el éxito / fracaso de un proyecto, pero lejos de ser el único. Sin embargo, cuando es el culpable, debe tratarse adecuadamente, de lo contrario, su proyecto seguramente estará condenado. No conozco ninguna herramienta mágica para separar los valores predeterminados malos de los buenos: en mi humilde opinión, se requiere un análisis cuidadoso del dominio del problema, casos de uso, etc. y, bueno, mucha comunicación.
Péter Török

1

Los valores predeterminados que no forman parte del protocolo / convención de comunicación son malos. Al ser "no una parte" quiero decir que no están documentados donde el protocolo es estricto, o simplemente no se espera, donde el protocolo está suelto.

Si el valor predeterminado está documentado / esperado, aún puede ser malo, pero también puede salvar vidas. Depende del área de dominio. Es muy frecuente que puedan ser muy peligrosos (por ejemplo, la dosis de medicamento predeterminada, el piso del elevador predeterminado, la dirección de movimiento predeterminada del automóvil), y a veces puede ser peligroso no tenerlos (por ejemplo, la dirección de movimiento predeterminada del automóvil, el tiempo predeterminado de reunión).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.