¿Existen ventajas para codificar valores de datos en un programa?

13

Soy un programador autodidacta, novato, por lo que me disculpo si no clavo la jerga del programador.

Estoy trabajando en un proyecto en el que proporciono datos, que se actualizarán continuamente, a desarrolladores que esencialmente crearán una herramienta para generar informes a partir de consultas sobre los datos.

Parece que todos los involucrados piensan que necesitan codificar los valores de los datos (no el esquema, sino los dominios / valores mismos) en el programa de generación de informes.

Por ejemplo, supongamos que estamos informando sobre el personal; el informe se dividiría en categorías, con un encabezado para cada departamento, y luego debajo de cada encabezado del departamento habrá subtítulos de títulos de trabajo, y luego debajo de cada subtítulo habrá una lista de empleados. Los desarrolladores quieren codificar los departamentos y los títulos de trabajo. Por otro lado, pensaría que podrían / ​​consultarían esas cosas en tiempo de ejecución, ordenarían los registros por ellos y generarían encabezados de informes dinámicamente en función de los valores que hay.

Dado que la lista de valores potenciales cambiará con el tiempo (por ejemplo, se crearán / renombrarán departamentos, se agregarán nuevos títulos de trabajo), el código deberá actualizarse continuamente. Me parece que podríamos omitir los pasos de mantenimiento del código y organizar dinámicamente los informes.

Como no soy desarrollador, me pregunto qué me estoy perdiendo. ¿Qué ventajas podría tener codificar valores en una herramienta como esta? ¿Es así típicamente cómo se diseñan los programas?

design architecture architectural-patterns dynamic-data Tom
fuente
1
posible duplicado de Extracción de valores no modificables y diseño defensivo vs YAGNI
mosquito
¿Son tabulaciones cruzadas de informes, lo que significa que los valores en filas deben aparecer como columnas?
Tulains Córdova
1
@Brendan: si codifica los valores en el informe, deberá cambiar la lista en DOS lugares (fuente de datos y el informe), mientras que si el informe es dinámico, solo necesita cambiarlo en una ubicación (el informe) .
kwah
1
@Brendan, ¿por qué terminarías con tres ubicaciones? Quizás mi comprensión es incorrecta, pero estoy imaginando una consulta sql para obtener datos de una base de datos, la aplicación agregará / agrupará los valores devueltos por, por ejemplo, el departamento. Si está dispuesto a tener la sobrecarga de múltiples consultas db, puede seleccionar distintos departamentos / títulos de roles si realmente lo desea. En ningún momento los datos existen en más de una ubicación: el informe está siendo impulsado por los datos.
kwah
1
@Brendan También estoy en desacuerdo con su definición de estar en un solo lugar: la forma en que lo describe está en varias ubicaciones, dispersas en todo el código fuente.
kwah

Respuestas:

9

Wikipedia:

La codificación rígida (también codificación rígida o codificación rígida) se refiere a la práctica de desarrollo de software de incorporar lo que, tal vez solo en retrospectiva, puede considerarse una entrada o datos de configuración directamente en el código fuente de un programa u otro objeto ejecutable, o un formato fijo de los datos, en lugar de obtener esos datos de fuentes externas o generar datos o formatear en el propio programa con la entrada dada.

La codificación dura se considera un antipatrón.

Considerado un antipatrón, la codificación rígida requiere que el código fuente del programa se cambie cada vez que cambien los datos de entrada o el formato deseado, cuando podría ser más conveniente para el usuario final cambiar los detalles por algún medio fuera del programa.

A veces no puedes evitarlo, pero debería ser temporal.

Con frecuencia se requiere codificación rígida. Es posible que los programadores no tengan una solución de interfaz de usuario dinámica para el usuario final, pero aún así deben entregar la función o lanzar el programa. Esto suele ser temporal, pero resuelve, en un sentido a corto plazo, la presión para entregar el código. Más tarde, se realiza una codificación suave para permitir que un usuario pase parámetros que le dan al usuario final una forma de modificar los resultados o el resultado.

  • La codificación de mensajes dificulta la internacionalización de un programa.
  • Las rutas de codificación dificultan la adaptación a otra ubicación.

La única ventaja de la codificación rígida parece ser la entrega rápida de código.

Tulains Córdova
fuente
55
OK, pero la "única ventaja" es a menudo enormemente importante. Las decisiones de diseño en la programación a menudo se refieren a la compensación entre pruebas futuras y entrega rápida ahora, y como tal, la codificación rígida puede ser una opción perfectamente aceptable. A veces no codificación dura es una opción de diseño malo.
-1 No creo que esta sea una respuesta útil. Básicamente dice que 'incrustar valores en el código fuente de manera inapropiada' es inapropiado. Creo que el OP quiere orientación sobre cuándo las cosas pueden pertenecer al código fuente y, por lo tanto, quedan fuera de su definición de Wikipedia.
Nathan Cooper
La codificación rígida debería ser una parte vital de su proceso y considerarlo un antipatrón está desactualizado en la era de los microservicios, con el tutorial Angular Tour of Heroes como un ejemplo de alto perfil de una gran casa de software que codifica directamente o incluso exige Un paso intermedio. Además, cuando pasa a datos dinámicos, aún debe conservar algunos datos codificados como una reserva, tal vez controlada por una variable de entorno o incluso una alternancia booleana en el código mismo para que los errores y los problemas de seguridad puedan aislarse adecuadamente. línea.
¿Qué hay en una búsqueda de Google?
24

De Verdad? ¿No hay posibles casos de uso válidos?

Si bien estoy de acuerdo en que la codificación dura es generalmente un antipatrón o al menos un mal olor a código , hay muchos casos en los que tiene sentido:

  • simplicidad ( YAGNI ),
  • la entrada es realmente constante y nunca cambiará (es decir, representa una constante natural o comercial o una aproximación de uno. Por ejemplo, 0, PI, ...),
  • software incorporado (me vienen a la mente restricciones de memoria y asignación),
  • software seguro (estos valores no están disponibles y / o son fáciles de decodificar o aplicar ingeniería inversa, por ejemplo, tokens criptográficos y sales),
  • código generado (su preprocesador o generador es configurable, pero escupe código con valores codificados),
  • y probablemente algunas más.

¿Sigue siendo un antipatrón ? ¡Así es la sobre ingeniería ! ¡Se trata de la esperanza de vida de su software!

No es que esté diciendo que hay grandes razones, y en general me opondría a valores codificados. Pero algunos pueden obtener un pase fácilmente por razones válidas.

Y tampoco supervise el primero con respecto a la simplicidad / YAGNI pensando que es trivial: probablemente no haya razón para implementar un analizador loco y un verificador de valores para un script simple que haga un trabajo para un caso de uso limitado muy bien.

Es difícil encontrar el equilibrio. A veces no se prevé que un software crecerá y durará más que el simple script que comenzó. Sin embargo, a menudo es al revés: hacemos un diseño excesivo de las cosas y un proyecto se archiva más rápido de lo que puede leer el Programador pragmático. Perdiste tiempo y esfuerzo en cosas que un prototipo inicial no necesitaba.

Eso es lo malo de los antipatrones: están presentes en ambos extremos del espectro, y su apariencia depende de la sensibilidad de la persona que revisa su código.

haylem
fuente
Eso es divertido, porque lo probé yo mismo, y fue mucho más fácil, rápido y limpio para mí manejar los valores dinámicamente. Lo hice en Python, mientras que creo que el producto final se codificará en Java, si esto marca la diferencia. Se sintió sobredimensionado cuando codifiqué los valores, porque cada columna entrante tenía que rastrearse en varios lugares.
Tom
@Tom: ¿Estás diciendo que fue más fácil y rápido implementar (o incluso reutilizar) una biblioteca de búsqueda de configuración que usar un valor codificado? Bien por ti. Además, no veo cómo su última oración se ajusta a la definición de ingeniería excesiva. Se sentiría obviamente desordenado, y obviamente si está codificado y duplicado es aún peor (lo cual no era el punto de su pregunta, probablemente lo entendí mal, pero me pareció que quería decir que el valor no estaba codificado en su lugar) cada vez, pero en un solo punto del programa).
haylem
De todos modos, solo estoy señalando casos en los que sería válido. También estoy señalando que sería controvertido en mi última oración. No se puede complacer a todos y los equipos tienen personas con diferentes niveles de habilidad.
haylem
1
@ Tom, no te vendas demasiado corto. Definitivamente estás en algo. Parece más fácil y lleva menos tiempo escribir un algoritmo rápido para organizar los datos mirando los campos Departamento y Título del trabajo en lugar de codificación rígida Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. También sería mucho más difícil mantener la matriz codificada en caso de que se introdujera un nuevo Departamento o Título.
Chris G
1
Puede tener cosas más complejas que todavía son sensibles al hardcode. Uno que me viene a la mente que escribí hace unos años fue todas las posibles permutaciones de un conjunto de valores. Necesitaba encontrar una dirección válida aleatoria, elegir una permutación aleatoria y luego tomar el primer resultado válido fue, con mucho, la solución más eficiente y, dado que estaba en un bucle O (N ^ 3), la eficiencia importaba.
Loren Pechtel
4

Hay veces que está bien codificar valores. Por ejemplo, hay algunos números como 0, o uno o varios valores n ^ 2-1 para máscaras de bits que necesitan ser ciertos valores para fines algorítmicos. Permitir que tales valores sean configurables no tiene valor y solo abre la posibilidad de problemas. En otras palabras, si cambiar un valor solo rompería las cosas, probablemente debería estar codificado.

En el ejemplo que diste, no veo dónde sería útil la codificación rígida. Todo lo que menciona ya debería estar en la base de datos, incluidos los encabezados. Incluso las cosas que impulsan la presentación (como el orden de clasificación) se pueden agregar si no están allí.

JimmyJames
fuente
Gracias. El orden de clasificación era la única preocupación que tenía. Sin embargo, en nuestro caso no importa, y ni siquiera consideré que podría agregarse como otra tabla en la base de datos.
Tom
1
Debo señalar que administrar todo esto en la base de datos es una opción. También podría usar archivos de configuración u otras soluciones, pero la codificación rígida parece ser una mala elección. La opción DB a menudo se usa porque es fácil crear una interfaz para permitir que las opciones sean administradas por los usuarios. También hay herramientas como esta que están específicamente diseñadas para este propósito.
JimmyJames
-1

La implementación de una solución robusta que permita valores que de otro modo habrían sido codificados para que los usuarios finales puedan configurarlos, exige una validación sólida de esos valores. ¿Pusieron una cuerda vacía? ¿Pusieron algo no numérico donde debería haber sido un número? ¿Están haciendo inyección SQL? Etc.

La codificación rígida evita muchos de estos riesgos.

Lo que no quiere decir que la codificación dura sea siempre, o incluso a menudo, una buena idea. Este es solo uno de los factores a tener en cuenta.

Topher Eliot
fuente