Спочатку трохи тла. Я кодую пошук із Age -> Rate. Існує 7 вікових дужок, тому таблиця пошуку - 3 колонки (від | до | оцінювання) з 7 рядками. Значення рідко змінюються - це законодавчі норми (перший і третій стовпці), які залишаються однаковими протягом 3 років. Я зрозумів, що найпростіший спосіб зберігати цю таблицю без жорсткого кодування - це в базі даних в таблиці глобальної конфігурації, як єдине текстове значення, що містить CSV (так "65,69,0.05,70,74,0.06" - це як 65-69 та 70-74 рівні зберігатимуться). Порівняно простий розбір, а потім використання.
Тоді я зрозумів, що для реалізації цього мені доведеться створити нову таблицю, сховище, яке потрібно обернути навколо неї, тести рівня даних для репо, одиничні тести навколо коду, який розкручує CSV в таблицю, і тести навколо самого пошуку. Єдиною перевагою всієї цієї роботи є уникання жорсткого кодування таблиці пошуку.
Під час розмови з користувачами (які в даний час використовують таблицю пошуку безпосередньо - дивлячись на паперовій копії), думка майже в тому, що "ставки ніколи не змінюються". Очевидно, що це насправді не правильно - ставки були створені лише три роки тому, і в минулому речі, які "ніколи не змінюються", мали звичку змінюватися - тому для мене, щоб захисно програмувати це, я точно не повинен зберігати таблицю пошуку в додаток.
За винятком випадків, коли я думаю про ЯГНИ . Функція, яку я реалізую, не вказує, що ставки будуть змінюватися. Якщо ставки змінюються, вони все одно змінюватимуться настільки рідко, що технічне обслуговування навіть не враховується, і ця функція насправді не є достатньо критичною, щоб на що-небудь вплинути, якщо буде затримка між зміною курсу та оновленим додатком.
Я майже вирішив, що нічого цінного не буде втрачено, якщо я жорстко кодую пошук, і я не надто стурбований своїм підходом до цієї особливості. Моє запитання: як професіонал я правильно обґрунтував це рішення? Значення жорсткого кодування - це погана конструкція, але проблематика видалення значень із програми, здається, порушує принцип YAGNI.
EDIT Щоб уточнити питання, я не переймаюся фактичною реалізацією. Я стурбований тим, що я можу або зробити швидку, погану справу, і виправдати це, сказавши YAGNI, або я можу скористатися більш захисним підходом до великих зусиль, який навіть у кращому випадку має низькі переваги. Як професійний програміст, моє рішення реалізувати дизайн, який, на мою думку, є хибним, просто зводиться до аналізу витрат / вигод?
EDIT Хоча всі відповіді були дуже цікавими, тому що я думаю, що це зводиться до вибору дизайну індивідуума, я думаю, що найкращі відповіді були у @ Corbin та @EZ Hart, оскільки вони відображають речі, які я не враховував у питанні:
- помилкова дихотомія "правильного видалення жорстко закодованих значень" шляхом переміщення її до бази даних проти "ефективного застосування YAGNI" за допомогою жорсткого кодування. Був третій варіант введення таблиці пошуку в конфігурацію програми, яка не несе накладні витрати правильним чином і без ефективності YAGNI. Ми, як правило, не обмежуємось чи /, ні рішеннями, і це зводиться до рішення витрат / вигод.
- генерація коду може зменшити накладні витрати на переміщення твердо кодованих значень у базу даних, і таким чином, це також видалить моє надмірно розроблене рішення обробити CSV в таблицю. Потенційно це також додає проблему тривалого обслуговування згенерованого коду, якщо основні вимоги змінюються для методу пошуку. Все це впливає лише на аналіз витрат і вигод, і, ймовірно, що якби у мене була така автоматизація, я б навіть не вважав жорстким кодуванням щось подібне.
Я відзначаю відповідь @ Корбіна як правильну, оскільки це змінює мої припущення щодо вартості розробки, і я, мабуть, додаю кілька інструментів генерації коду до свого арсеналу найближчим часом.