¿Cuál es su actitud hacia la codificación difícil?

Question

El mío es este:

¡La codificación dura es la manera! Todos mis problemas desaparecen. Simplemente codifíquelo uno por uno. Y los problemas vuelven a matar tu día.

absolutamente lo odiaba, pero el hecho es "gente de negocios" tienden a gustar porque se necesita menos tiempo para conseguir lo que querían. Y como un desarrollador de software que trabaja especialmente en un entorno corporativo, la mayoría de la gente dirá: "sí, ¿para qué molestarse, simplemente codificarlo?". ¿Cuál es su actitud hacia la codificación dura?

Answer 1

La codificación rígida es algo que debe evitarse tanto como sea posible.

Si hardcode algo en su código será completamente "destruir" la portability de su código en gran medida. Incluso con una plataforma de idiomas independientes, no podrás decir "Compilar una vez, ejecutar en cualquier lugar". Como no es una buena práctica de ingeniería de software, creo que es mejor evitar los códigos rígidos.

Pero sé que en algunos casos necesitamos eso, especialmente para depurar los códigos. La forma en que sugiero es: primero desarrollar el código con códigos duros, hacerlo estable y eliminar los códigos duros, entonces ...

Y puede haber algunos casos en los que necesitemos hardcoding, debido a problemas de seguridad, etc. :). es posible que no se le permita usar el registro, los archivos de configuración ni nada porque pueden aumentar la superficie de ataque. Pero creo que es un caso raro.

Answer 2

Por lo general, intento poner valores en un archivo de configuración en lugar de en un código. Si un valor debe estar codificado, creo una constante con el valor codificado y en todas partes del código se hace referencia a la misma constante. Si el valor necesita cambiar, se puede hacer en un solo lugar.

Para las constantes de toda la aplicación, normalmente creo una clase y creo constantes en eso.

Answer 3

¡La codificación dura es el camino a seguir!

Pero como mencionó Anthony, puse los valores configurables en su propia clase. De esta forma son configurables en tiempo de compilación, pero sin las complejidades añadidas que vienen con tener un archivo xml/txt externo para la configuración.

Solo uso archivos xml/txt para la configuración cuando sea absolutamente necesario. De lo contrario, estás sobre-ingeniería que puede ser igual de mala, si no peor que la codificación difícil. Sin mencionar que hay muchas cosas que la gente pone en archivos de configuración que no quieres que el cliente cambie.

Si necesita configuraciones diferentes para clientes diferentes, no hay problema, coloque los valores codificados en su propio ensamblado/dll y despliegue diferentes ensamblados de configuración por cliente.

Como Ayende dice, hard coding everything es la clave para permitir el cambio.

Answer 4

Como alguien que ha tenido alguna experiencia con la codificación rígida en mis primeros días (no se lo digas a nadie), puedo confiadamente decirte que volverá para perseguirte. Hay esta aplicación que hice (que I no se habla ahora) que tenía que ser completamente reescrito porque tenía un montón de contenido codificado. Eso fue en 1998 mate.

No lo haga a menos que no desee admitir ese cliente en el futuro. El tiempo que ahorre ahora, será el tiempo dedicado a arreglarlo más tarde.

Answer 5

Hay varios factores involucrados que difícilmente hacen una afirmación que cubrirá todos los casos.

Si se trata de un proyecto largo con varios ciclos, entonces si inicia la codificación difícil, es probable que vuelvan a aparecer pronto. Entonces, en estos casos, es mejor solucionarlo con una solución adecuada.

Pero si tiene un proyecto con un ciclo corto, o con un cronograma predefinido y tiene que enviar el producto de todos modos, la mayoría de los clientes estarán satisfechos si el producto funciona, no se preocuparán por las partes internas. Pero en estos casos prefiero codificar una solución, pero dejo abierta la ruta para que en el futuro sea fácil hacer una solución adecuada.

La codificación dura es mala de todos modos, pero si documenta correctamente puede hacer la vida de la siguiente persona mucho más fácil, y probablemente no lo maldecirá, al menos no mucho;).

Pero desde mi experiencia comencé a evitar el código duro desde el principio, y solo los uso cuando no tengo otra opción, y siempre documentando esos casos para luego poder arreglarlo correctamente cuando tengo tiempo.

Answer 6

¡No hay nada de malo en la codificación, siempre que se haga bien por las razones correctas!

"Hacerlo bien" significa concentrar toda su codificación dura en uno o dos módulos.

Para C define todos los valores en a codes.h para Java tiene una clase codes.java que está llena de constantes públicas.

Existen varias "razones correctas" para la codificación difícil.

• simplicity.
• compatibilidad: si sus valores están en un archivo de configuración externo, no puede protegerse contra configuraciones estúpidas y no puede probar todas las configuraciones posibles; si está codificado, entonces sabrá a qué se enfrenta.
• Rendimiento.
• legibilidad. ¡Puedes ver todo lo que necesitas saber en tu sesión de edición!

También hay varias razones para evitar archivos de configuración complejos. Si tiene suficientes parámetros y opciones, acaba programando en un lenguaje no muy bueno.

Answer 7

toma menos tiempo para obtener lo que querían.

Eso es casi como decir: "Me gusta escribir mi código sin comentarios porque lleva menos tiempo obtener lo que quería".

Por supuesto, eso no quiere decir que la codificación dura es siempre una muy mala cosa. (Quiero decir, sería una especie de estúpido almacenar, por ejemplo, una constante matemática como π, e, o la constante de Planck en un archivo de configuración. Además, la codificación difícil de una tabla de búsqueda para, por ejemplo, los valores seno/coseno probablemente ser mucho más eficiente que cargarlo desde un archivo.) Pero los datos de codificación difícil puramente por el bien de la conveniencia no son una buena idea.Es inflexible y hace que modificar los datos más tarde sea mucho más problemático de lo que debe ser.

Además, la codificación rígida puede hacer que la localización sea extremadamente difícil, si no imposible en muchas situaciones. Si se trata de una aplicación interna para alguna empresa, entonces supongo que realmente no importa en cierta medida, pero eso no la convierte en una buena práctica de desarrollo de software en general.

Answer 8

Conceptualmente, no me gusta demasiado el código rígido.

Pero en la práctica tiendo a codificar algunos valores. Las principales razones para codificar son:

• Por especificación debería ser exactamente este valor, no se debe cambiar. Hacerlo cambiable podría hacer que el software sea inestable.
• El valor probablemente podría cambiarse más tarde, pero no se sabe quién lo hizo y cómo, por lo que no se sabe a dónde pertenece. Podría pertenecer al archivo de configuración, los archivos de recursos, la base de datos, el registro o en otro lugar. Ponerlo en el lugar equivocado es peor que codificarlo con dificultad.

hay algunas "codificación dura mejores de la praxis" Creo que son, no exceso de ingeniería:

• valores no modificables siempre deben ser declaradas en un lugares centrales en las constantes.
• Incluso si un valor está codificado, aún se debe pasar como argumento a los componentes, que no tienen que importar de dónde viene el valor. Hace que tu componente sea reutilizable.

Esto hace posible mover los valores codificados a otro lugar más adelante.

Answer 9

Las balas de plata no existen en TI.

• Hazlo si es inteligente.
• No lo hagas si es tonto.

Si alguien le dice que haga algo tonto, guarde la secuencia de correo electrónico y guarde su J.O.B.

Answer 10

Si necesito una char * para que apunte a 12 caracteres, puedo escribir de forma segura malloc(12) porque sizeof(char) siempre será 1. Si necesito una int * a señalar las 12 en números enteros, escribo malloc(12 * sizeof(int)).

Hardcode las pocas cosas que se absoluta y positivamenteNunca cambio. Para todo lo demás, toma dos segundos extra, ¿por qué no seguir adelante y hacerlo?

Answer 11

Creo que dura la codificación de los valores por defecto es el camino a seguir por todo lo que podría ser necesaria para ser configurable:

En nuestro código de interfaz gráfica de usuario (cliente-servidor) usamos una búsqueda de tres pasos: pedimos nuestras preferencias instancia para una preferencia con un valor predeterminado. Pero este valor predeterminado pasado es anulado por un archivo de configuración, si existe.

De esta manera tenemos dos opciones más adelante.Si un cliente quiere algo diferente, podemos cambiarlo en el archivo de configuración. Y también podemos configurar nuestro diálogo de configuración para que el usuario pueda configurarlo.

Así que efectivamente tenemos códigos duros, que pueden ser reemplazados por configuración, que pueden ser reemplazados por las preferencias del usuario.

El único problema es documentar todas las claves de preferencias ...

Answer 12

Si-codificación duro se hace correctamente, puede ser una ventaja. Por ejemplo, si ha codificado los tamaños de matriz en lugar de asignarlos dinámicamente, facilita la depuración, ya que sabe exactamente dónde reside la matriz en la memoria. Sin embargo, esto supone que realmente quieres saber cosas como estas.

Answer 13

Por lo general, se gasta más tiempo y dinero manteniendo el código que al escribirlo originalmente. El 80% del total gastado en el código generalmente se gasta durante el período de mantenimiento. Por lo tanto, cualquier cosa que haga que el mantenimiento sea más difícil eventualmente costará más que hacerlo bien la primera vez. La codificación estricta es definitivamente una de las cosas que dificulta el mantenimiento y, en consecuencia, es una mala idea.

Answer 14

En software embebido y crítica, hardcoding tiene dos ventajas principales:

• es más rápido
• es más simple

Esto significa menos carga de la CPU, es decir, menos consumo de energía, menos o no hay asignación de memoria dinámica, menos complejidad algorítmica, es decir, depuración más fácil, ...

Por lo general, los datos codificados se colocan en un solo archivo de cabecera para más mantenimiento nabilidad.

Además, la flexibilidad es proporcionada por una generación automática de este archivo de encabezado desde una base de datos.

Answer 15

Siempre creo una constante, pero lo más cerca posible/sensible de dónde debe estar su "único" uso.

Si luego lo necesito en otro lugar de la unidad, se mueve a la parte superior de la unidad.

Si es necesario en otra unidad, la constante se mueve a una unidad de configuración.

Si alguien quiere que cambiable que se trasladó a la unidad de configuración (si no está ya), y estableció a partir de un archivo de configuración, etc.

Al final del día, el nombre que le asigne la cosa es su documentación, al menos significa que no te mezclarás con otros 73. Si ves lo que quiero decir.

Answer 16

En cuanto a cadenas codificadas en C/C++; Por lo general, los defino como la forma más simple de evitar la codificación difícil (aunque en cierto sentido todavía está codificada). La razón es que un identificador definido que está mal escrito será capturado por el compilador, mientras que cualquier cosa entre comillas no lo hará.

Answer 17

Mi actitud hacia la configuración? Con demasiada frecuencia, se hace de manera deficiente y con demasiada informalidad, lo que aumenta el TCO a medida que los usuarios intentan conseguir cientos de valores configurables. Agregue configurabilidad (codificación suave) solo cuando se demuestre que es necesario.

Cuando es necesario ... Un valor configurable debe tratarse con la misma desconfianza que la entrada del usuario y proporcionar mensajes de error lúcidos cuando la entrada es incorrecta.La mayoría de los componentes deben aislarse de la infraestructura de configuración, al igual que aislar la mayoría de los componentes de cualquier infraestructura de acceso a datos. Una vez aislado de la infraestructura de configuración, puede y debe probar cómo el componente maneja varias "entradas" desde el sistema de configuración. Lo más importante, el programa debería funcionar bien con un mínimo absoluto de configuración.

Sin embargo, este tipo de anti-patrón es muy común:?.

File.Open(configuration["widgetsFileStorage"] + "/" + widgetImage) 

O esto (¿Alguna vez poner la entrada del usuario directamente en un href yo no De alguna manera, mucha gente confía en los valores de configuración ahora demasiado).

LinkWriter.href=configuration["supportUrl"] 

Al configurar? Como demuestras que necesitas hacerlo. Una buena separación de preocupaciones facilitará la configuración de un valor en un momento posterior. Dejaría la responsabilidad de ubicar un archivo en un localizador de archivos.

File.Open(new WidgetFileLocater().GetUncPath(widgetImage)) 

En algún lugar detrás de mi localizador de archivos podría o no referirme a un archivo de configuración, una base de datos. Probablemente empiece a codificar de manera dura en un directorio de "imágenes" en el directorio de la aplicación. La configuración viene cuando tenemos un caso de uso para la flexibilidad (¿alguien quiere ponerlo en SAN?) Pero no antes. De todos modos, la mayor parte de la aplicación no debería estar configurada o no. Probablemente usaría alguna inyección de dependencia en el localizador de archivos para verificar que manejaba correctamente la entrada incorrecta del archivo de configuración.

También: La configuración casi siempre está vagamente tipada, no compilada y, por lo tanto, es mucho más peligrosa que el código. Este riesgo rara vez es respetado por los desarrolladores (pero muy respetado por los administradores de sistemas). He debatido sobre el uso de un lenguaje de script como python/ironpython/boo para las necesidades de configuración. Tendría la capacidad de cambiar cosas después de la compilación, con una sintaxis y verificación de tipos mucho más libre que xml o texto.

Advertencias: Mi actitud asume un ciclo de lanzamiento iterativo. Si tiene un ciclo de lanzamiento de 2 a 10 años, como Microsoft, querrá inclinarse a favor de configurar muchos más valores.