Codificación rígida vs Codificación genérica: ¿Dónde dibujar la línea?

Question

No estoy seguro de cómo decir esto, pero lo intentaré.

Suponga que tiene algunos ajustes en alguna pieza de su programa, donde el 80% seguro de que no siempre tiene que modificar de nuevo. ¿Cómo sabes dónde trazar la línea en un código modificable? Usted sabe que llevar la configuración hasta un archivo XML definido por el usuario es excesivo. Sin embargo, también sabe que hay un 20% de posibilidades de que estas configuraciones necesiten cambiarse más adelante, por lo que codificarlo en el lugar donde la goma se encuentra con la carretera tampoco es óptimo.

Creo que lo que estoy tratando de hacer es, hasta qué punto el árbol abstracción debe permitir que su programa sea fácilmente cambiable?

Uno de los muchos ejemplos es escribir el código HTML de una página web de forma manual vs tener el programa automáticamente genera. Escribir el código HTML directamente no toma demasiado tiempo. Escribir un programa para generar automáticamente el código HTML lleva mucho más tiempo.

Answer 1

Esta es una buena pregunta, pero no hay una respuesta absoluta para ello:

Como se ha señalado por Einstein:

hacer las cosas lo más simple posible, pero no más simple.

simplicidad es relativa. Tomar la mejor decisión sobre la cantidad de capas de abstracción en un diseño es lo que hace que un gran arquitecto sea genial. Un buen arquitecto siempre debe evaluar la situación particular y hacer el mejor intercambio. No hay balas de plata

Answer 2

80%? No es lo suficientemente bueno como para codificarlo, ponerlo en el archivo de configuración.

100%? Una constante puede hacer.

Answer 3

dos puntos:

• Todas las constantes deben ser genérico, es decir, no siempre difícil que el código números mágicos sin ponerlo en un descriptiva constante .
• implementar el mínimo que realmente necesita - difícil que el código hasta que esté a punto de duplicar el código modificable más de una vez - en ese caso, usted debe comenzar a hacer el código genérico. (El desarrollo impulsado por prueba es increíble aquí).

Answer 4

Su pregunta se orientó hacia el diseño de código real que si se colocan variables en el archivo de configuración o en constantes. Estoy de acuerdo con las otras respuestas con respecto a esos aspectos.

Pero con respecto a si escribir código generalizada ...

En mi experiencia, si escribe código específicamente para hacer frente a la tarea en cuestión, sólo se encuentre escribiendo código similar en algún momento en el futuro. Ok, si realmente solo harás la tarea una vez, está bien. Pero me parece que la mayoría de las veces este no es el caso.

Si se encuentra repitiendo una tarea en total, entonces debería dar un paso atrás y considerar lo que llevaría automatizarlo de manera general.

También verifique que alguien no lo haya hecho ya.Si no lo han hecho, considere publicar su código, sin importar cuán pequeño o áspero sea. Alguien podría mejorarlo por ti, gratis.

Answer 5

En los últimos cuatro años, este viejo perro ha aprendido el nuevo truco de TDD. Incluso cuando no tengo tiempo para hacer una TDD "real", finjo que sí.

Así que I siempre escriba código duplicado. Lo cual está bien, porque yo siempre lo refactorizo ​​luego. Esto es parte del proceso de escribir el código, no es algo a lo que recurrir luego. Como seguí TDD y solo escribí el código mínimo necesario, y dado que tengo pruebas automáticas que prueban que el código funciona, si encuentro duplicación, puedo refactorizarla con comodidad, sabiendo que volveré a hacer las pruebas. durante y después de la refactorización. Esto demostrará una vez más que no he roto nada.

De esta forma, no especulo si el código será reutilizado - Nunca refactorizo ​​hasta que sea reutilizado. Dado que se crea en cada instancia de acuerdo con las necesidades de la instancia, sé que quien llama al código no se ha deformado por el deseo de hacer que el código sea genérico. Las personas que llamaron, incluidas las pruebas unitarias, se escribieron para satisfacer sus necesidades inmediatas. El pase de refactorización separado maneja la necesidad más amplia de no duplicar el código.

Answer 6

Voy a dar a este un tiro, mi filosofía es la siguiente:

1 - Mantener un archivo de configuración & clase analizador/función que están muy dumbed y simple como sea posible para darle la tranquilidad de que cada vez que necesite algo de él, puede obtenerlo sin tener que crear una instancia de un analizador de archivos de configuración de crujido XML ridículamente sobresalido. Mi archivo de configuración es el siguiente:

DBHostname -> XX.XX.XXX.XX 
DBUsername -> foomonger 
DBName -> fooDb 
DBPassword -> xxxxx 
ImageUploadsDir -> /uploads/images/ 
... 

extraigo lo que necesito de ella usando un método estático helper (pequeñas aplicaciones) o una instancia singleton (grandes MVC aplicaciones de tracción) generada por mi amigo idiota ConfigHelper, que es tan tonto, él no sabe cómo generar gastos generales.

Tengo este dilema varias veces en mi día laboral promedio: ¿debo poner esto en config.txt o debería hacerlo una constante de clase? Mi respuesta es que simplemente no lo sé, hasta mucho más tarde. Si resulta que debe colocarse en el archivo de configuración, nada supera a un IDE decente con una implementación estable 'Buscar & Reemplazar en proyectos' para cambiar las referencias.

3 - Los archivos de configuración eliminan la pesadilla de la implementación de la aplicación cuando el desarrollo implica un servidor de prueba seguido de la implementación en la producción; no existe una alternativa práctica real. Diferentes instancias de bases de datos en diferentes máquinas tienen diferentes direcciones IP en el mundo que entiendo.

Uno de los muchos ejemplos es escribir el código HTML de una página web de forma manual vs tener el programa automáticamente generarla

Esto es tan cierto. Si bien nosotros, como desarrolladores, disfrutamos de la construcción de máquinas, tendemos a perder mucho tiempo construyendo máquinas para construir la máquina que inicialmente pretendíamos construir. Aunque esto puede ser extremadamente gratificante, por experiencia puedo aventurarme a decir que en situaciones más cuantas más máquinas tenga, cuantos más sistemas tenga que admitir, más puntos de falla, más golpes de mano obtendrá de los propietarios de la empresa - y eso no es divertido. Además, tenderá a encontrarse con situaciones en las que el generador intermedio de HTML no puede producir el resultado deseado. Entonces, ¿qué haces, perder el tiempo arreglando el error en la cosa del generador, perder el tiempo ideando una solución vudú, o simplemente escribir a mano el HTML?Realmente depende de la circunstancia particular, pero prefiero lo último.

Fue un poco una farsa, pero espero que ayudó a responder a su pregunta, al menos un poco.