Soy un programador autodidacta y novato, así que me disculpo si no entiendo la jerga del programador.
Estoy trabajando en un proyecto en el que estoy proporcionando datos, que se actualizarán continuamente, a los 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 valores de datos (no el esquema, sino los propios dominios / valores) 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 de departamento habrá subtítulos de los 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. En el Por otro lado, pensaría que podrían consultar esas cosas en tiempo de ejecución, ordenar los registros por ellos y generar encabezados de informes dinámicamente en función de lo que valu hay.
Dado que la lista de valores potenciales cambiará con el tiempo (p. ej., se crearán / cambiarán de nombre los departamentos, se agregarán nuevos puestos 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í normalmente como se diseñan los programas?
Comentarios
- posible duplicado de Eliminando el código valores y diseño defensivo frente a YAGNI
- ¿Los informes son tablas cruzadas, lo que significa que los valores en las filas deben aparecer como columnas?
- @Brendan: si codifica los valores en el informe , ‘ tendrá que cambiar la lista en DOS lugares (la fuente de datos y el informe), mientras que si el informe es dinámico, solo tendrá que cambiarlo en una ubicación (el informe) .
- @Brendan, ¿por qué terminarías con tres ubicaciones? Quizás mi comprensión sea 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 de base de datos, puede seleccionar distintos departamentos / títulos de funciones si realmente lo desea. En ningún momento los datos existen en más de una ubicación; el informe se basa en los datos.
- @Brendan También estoy en desacuerdo con su definición de que está en un solo lugar, la forma en que lo describe ‘ s en varias ubicaciones, dispersos por todo el código fuente.
Respuesta
Wikipedia:
Difícil codificación (también codificación rígida o codificación fija) se refiere a la práctica de desarrollo de software de incrustar lo que puede, quizás solo en retrospectiva, considerarse una entrada o datos de configuración directamente en el código fuente de un programa u otro objeto ejecutable, o formato fijo del datos, en lugar de obtener esos datos de fuentes externas o generar datos o formatear en el programa en sí con la entrada dada.
La codificación dura se considera un antipatrón .
Considerado un n anti-patrón, la codificación rígida requiere que se cambie el código fuente del programa cada vez que cambien los datos de entrada o el formato deseado, cuando podría ser más conveniente para el usuario final cambiar el detalle por algún medio fuera del programa.
A veces no puede evitarlo, pero debería ser temporal.
La codificación dura es a menudo requerido. Es posible que los programadores no cuenten con una solución de interfaz de usuario dinámica para el usuario final, pero aún 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, la codificación se realiza para permitir que un usuario pase parámetros que le dan al usuario final una forma de modificar los resultados o el resultado.
- Codificación dura de mensajes dificulta la internacionalización de un programa.
- Las rutas de codificación rígidas dificultan la adaptación a otra ubicación.
La única ventaja de la codificación parece ser la entrega rápida del código.
Comentarios
- OK , pero la » única ventaja » es a menudo muy importante. Las decisiones de diseño en la programación a menudo tienen que ver con el compromiso entre las pruebas futuras y la entrega rápida ahora, y como tal, la codificación rígida puede ser una opción perfectamente aceptable. A veces, la codificación no es una mala elección de diseño.
- -1 No ‘ creo que esta sea una respuesta útil. Básicamente dice que ‘ incrustar valores en el código fuente de forma 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.
- La codificación dura debe ser una parte vital de su proceso y, considerando que un anti-patrón está desactualizado en el era de los microservicios, con el tutorial de Angular Tour of Heroes como un ejemplo de alto perfil de una enorme casa de software que codifica directamente o incluso exige como paso intermedio. Es más, cuando pasa a datos dinámicos, aún debe retener algunos datos codificados de forma rígida como una alternativa, tal vez controlados por una variable de entorno o incluso un conmutador booleano en el código mismo para que los errores y los problemas de seguridad se puedan aislar adecuadamente en el línea.
Responder
¿En serio? ¿No hay casos de uso válidos posibles?
Si bien estoy de acuerdo en que la codificación fija es generalmente una anti-patrón o al menos un olor de código muy malo, hay muchos casos en los que tiene sentido. Aquí hay algunos.
-
Simplicity / YAGNI .
-
Constantes reales que en realidad nunca cambian.
es decir, la constante representa un natural o negocio constante, o una aproximación de uno. (p. ej., 0, PI, …)
-
Restricciones ambientales de hardware o software
En el software integrado, me vienen a la mente las limitaciones de memoria y asignación.
-
Software seguro
Estos valores no están disponibles y / o no son fáciles de decodificar o realizar ingeniería inversa, por ejemplo tokens y sales criptográficas. (Tenga en cuenta que mantenerlos codificados también tiene desventajas obvias …)
-
Código generado
Su preprocesador o generador es configurable, pero escupe código con valores codificados. No es inusual para el código que se basa en motores de reglas o si tiene una arquitectura basada en modelos.
-
Código de alto rendimiento
En cierto modo, esto es » generado » , aunque aún más especializado. p.ej. una tabla de cálculo / búsqueda predeterminada con cambios poco probables. Esto no es inusual en la programación de gráficos, por ejemplo.
-
Configuración y alternativas
Tanto en su código real como en sus archivos de configuración, es probable que tenga valores de configuración y alternativas para varios casos (cuando la configuración no está disponible, cuando un componente no responde como esperado, etc …). Aún así, generalmente es mejor mantenerlo fuera de su código y buscarlo, pero puede haber casos en los que desee absolutamente tener un valor / reacción específicos a una acción / problema / situación específicos.
-
Y probablemente algunos más …
Sigue siendo un Anti-Pattern ¿a>? ¡También lo es sobreingeniería ! ¡¡Se trata de la esperanza de vida de su software !!
No es que yo esté diciendo existen todas las razones importantes y, en general, me resistiría a los valores codificados de forma rígida. Pero algunos pueden obtener fácilmente un pase por razones válidas.
Y no supervise la primera con respecto a la simplicidad / YAGNI ya sea pensando que es trivial: probablemente no hay razón para implementar un analizador loco y un verificador de valores para un script simple que hace un trabajo para un caso de uso limitado. bueno.
Es difícil encontrar la bola ance. A veces no se prevé que un software crezca y dure más que el simple script con el que comenzó. A menudo, sin embargo, es al revés: diseñamos demasiado las cosas y un proyecto se archiva más rápido de lo que usted puede. leer el Programador pragmático. Perdiste tiempo y esfuerzo en cosas que un prototipo temprano no necesitaba.
Eso es lo malo de los Anti-Patrones: están presentes en ambos extremos del espectro, y su apariencia depende de la sensibilidad de la persona que revisa su código.
Personalmente, siempre tendré a seguir la ruta genérica, tan pronto como veo que algo podría cambiar o si «He tenido que hacerlo más de una vez. Pero un enfoque más preciso sería evaluar cuidadosamente el costo de codificar en forma rígida frente a generar o generar su código para esa situación específica.Es lo mismo que determinar si vale la pena automatizar una tarea en lugar de hacerlo manualmente. Solo tenga en cuenta el tiempo y el costo.
Comentarios
- Eso ‘ es gracioso, 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ó sobrecargado cuando codifiqué los valores, porque cada columna entrante tenía que rastrearse en varios lugares.
- @Tom: ¿’ estás diciendo que era más fácil y rápido implementar (o incluso reutilizar) una biblioteca de búsqueda de configuración que usar un valor codificado? para ti. Además, ‘ no veo cómo tu última oración se ajusta a la definición de ingeniería excesiva. anguila obviamente desordenada, y obviamente si ‘ está codificada y duplicada ‘ es aún peor (que no era el punto de tu pregunta pregunta, probablemente no entendí bien, pero me pareció que querías decir que el valor no estaba codificado en su lugar cada vez, sino en un solo punto del programa).
- De todos modos, yo ‘ m solo señala los casos en los que ‘ d sea válido. Yo ‘ también estoy señalando que ‘ sería controvertido en mi última oración. No puede ‘ complacer a todos y los equipos tienen personas con diferentes niveles de habilidad.
- @Tom, don ‘ t venderse demasiado corto. Definitivamente estás ‘ en algo. Parece más fácil y requiere menos tiempo escribir un algoritmo rápido para organizar los datos mirando los campos Departamento y Título del trabajo en lugar de la codificación rígida
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. También sería mucho más difícil mantener la matriz codificada de forma rígida en el caso de que se introdujera un nuevo Departamento o Título. - Puede tener cosas más complejas que aún sean sensibles a la codificación rígida. Una 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 era, con mucho, la solución más eficiente y, dado que estaba en un bucle O (N ^ 3), la eficiencia importaba.
Respuesta
A veces es correcto codificar valores de forma rígida. Por ejemplo, hay algunos números como 0, uno o varios valores n ^ 2-1 para las máscaras de bits que deben ser ciertos valores para propósitos algorítmicos. Permitir tales valores en el configurable no tiene ningún 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 dio, 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 títulos. Incluso los elementos que impulsan la presentación (como el orden de clasificación) se pueden agregar si no están allí.
Comentarios
- Gracias. El orden de clasificación fue la única preocupación que tenía. Sin embargo, en nuestro caso no ‘ no importa, y yo ‘ ni siquiera consideré que podría ser agregado como otra tabla en la base de datos.
- Debo señalar que administrar todo esto en la base de datos es una opción. También puede usar archivos de configuración u otras soluciones, pero la codificación parece ser una mala elección. La opción se usa a menudo porque ‘ es fácil de crear una interfaz para permitir que los usuarios administren las opciones. También hay herramientas como este que están diseñados específicamente para este propósito.
Respuesta
Implementando una solución robusta que permite valores que de otro modo podrían haber sido codificados para que sean configurables por las demandas de los usuarios finales validación robusta 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 fija evita muchos de estos riesgos.
Lo que no quiere decir que la codificación fija es siempre, o incluso a menudo, una buena idea. Esto es solo uno de los factores a tener en cuenta.