Primero un poco de historia. Estoy codificando una búsqueda de Age -> Rate. Hay 7 corchetes de edad, por lo que la tabla de búsqueda es de 3 columnas (de | a | tasa) con 7 filas. Los valores rara vez cambian: son tasas legisladas (primera y tercera columnas) que han permanecido igual durante 3 años. Pensé que la forma más fácil de almacenar esta tabla sin codificarla es en la base de datos en una tabla de configuración global, como un único valor de texto que contiene un CSV (así que "65,69,0.05,70,74,0.06" es cómo se almacenarían los niveles 65-69 y 70-74). Relativamente fácil de analizar y luego usar.
Luego me di cuenta de que para implementar esto, tendría que crear una nueva tabla, un repositorio para envolverlo, pruebas de capa de datos para el repositorio, pruebas unitarias alrededor del código que desencadena el CSV en la tabla y pruebas alrededor de la búsqueda en sí. El único beneficio de todo este trabajo es evitar codificar la tabla de búsqueda.
Cuando se habla con los usuarios (que actualmente usan la tabla de búsqueda directamente, mirando una copia impresa), la opinión es más o menos que "las tasas nunca cambian". Obviamente, eso no es realmente correcto: las tasas solo se crearon hace tres años y en el pasado las cosas que "nunca cambian" han tenido la costumbre de cambiar, por lo que para programar defensivamente esto definitivamente no debería almacenar la tabla de búsqueda en la aplicación.
Excepto cuando pienso en YAGNI . La función que estoy implementando no especifica que las tarifas cambiarán. Si las tarifas cambian, todavía cambiarán tan raramente que el mantenimiento ni siquiera es una consideración, y la función no es lo suficientemente crítica como para que algo se vea afectado si hubiera un retraso entre el cambio de la tarifa y la aplicación actualizada.
Casi he decidido que no perderé nada de valor si codifico la búsqueda, y no estoy demasiado preocupado por mi enfoque de esta característica en particular. Mi pregunta es, como profesional, ¿he justificado adecuadamente esa decisión? La codificación de valores es un mal diseño, pero ir a la molestia de eliminar los valores de la aplicación parece violar el principio YAGNI.
EDITAR Para aclarar la pregunta, no me preocupa la implementación real. Me preocupa que pueda hacer algo rápido y malo y justificarlo diciendo YAGNI, o puedo adoptar un enfoque más defensivo y de alto esfuerzo, que incluso en el mejor de los casos tiene beneficios bajos. Como programador profesional, ¿mi decisión de implementar un diseño que sé que es defectuoso simplemente se reduce a un análisis de costo / beneficio?
EDITAR Si bien todas las respuestas fueron muy interesantes, ya que creo que esto se reduce a las opciones de diseño de un individuo, creo que las mejores respuestas fueron @ Corbin y @EZ Hart, ya que traen a colación cosas que no había considerado en la pregunta:
- la falsa dicotomía de "eliminar correctamente los valores codificados" moviéndolo a la base de datos versus "aplicar eficientemente YAGNI" utilizando codificación rígida. Había una tercera opción de poner la tabla de búsqueda en la configuración de la aplicación, que no incurre en la sobrecarga de la manera correcta y sin la eficiencia de YAGNI. Por lo general, no estamos limitados a ninguna de las decisiones, y luego se reduce a una decisión de costo / beneficio.
- la generación de código puede reducir la sobrecarga de mover los valores codificados a la base de datos, y de una manera que también elimina mi decisión de ingeniería excesiva de procesar un CSV en la tabla. Potencialmente, esto también agrega un problema de mantenimiento a largo plazo con el código generado si los requisitos básicos cambian para el método de búsqueda. Todo esto solo afecta el análisis de costo / beneficio, y es probable que si hubiera tenido esa automatización disponible, ni siquiera hubiera considerado codificar algo como esto.
Estoy marcando la respuesta de @ Corbin como correcta porque cambia mis supuestos del costo de desarrollo, y probablemente agregaré algunas herramientas de generación de código a mi arsenal en el futuro cercano.