Сначала немного фона. Я кодирую поиск по возрасту -> Оценить. Есть 7 возрастных скобок, поэтому таблица поиска состоит из 3 столбцов (От | До | Оценить) с 7 строками. Значения редко меняются - это законодательные нормы (первый и третий столбцы), которые остаются неизменными в течение 3 лет. Я подумал, что самый простой способ сохранить эту таблицу без жесткого кодирования - это использовать ее в базе данных в глобальной таблице конфигурации, в виде единого текстового значения, содержащего CSV (так как "65,69,0.05,70,74,0.06" уровни 65-69 и 70-74 будут сохранены). Относительно легко разобрать, затем использовать.
Затем я понял, что для реализации этого мне нужно будет создать новую таблицу, репозиторий для ее обертывания, тесты уровня данных для репозитория, модульные тесты вокруг кода, который раскрывает CSV в таблицу, и тесты вокруг самого поиска. Единственное преимущество всей этой работы - избегание жесткого кодирования таблицы поиска.
Говоря с пользователями (которые в настоящее время используют таблицу поиска напрямую - просматривая печатную копию), в значительной степени складывается мнение, что «ставки никогда не меняются». Очевидно, что это на самом деле не правильно - ставки были созданы только три года назад, и в прошлом вещи, которые «никогда не менялись», имели привычку меняться - поэтому для меня, чтобы защитно программировать это, я определенно не должен хранить таблицу поиска в приложение.
За исключением случаев, когда я думаю, что ЯГНИ . Функция, которую я реализую, не указывает, что ставки будут меняться. Если тарифы меняются, они все равно будут меняться настолько редко, что обслуживание даже не рассматривается, и эта функция на самом деле не настолько критична, чтобы что-то могло повлиять на задержку между изменением тарифа и обновленным приложением.
Я в значительной степени решил, что ничего ценного не будет потеряно, если я жестко закодирую поиск, и я не слишком обеспокоен моим подходом к этой конкретной функции. У меня вопрос, как профессионал, правильно ли я обосновал это решение? Жесткое кодирование значений - это плохой дизайн, но попытка удаления значений из приложения, похоже, нарушает принцип YAGNI.
РЕДАКТИРОВАТЬ Чтобы уточнить вопрос, я не беспокоюсь о фактической реализации. Я обеспокоен тем, что я могу сделать что-то быстрое, плохое и оправдать это, сказав YAGNI, или я могу использовать более оборонительный подход, требующий больших усилий, который даже в лучшем случае в конечном итоге приносит мало пользы. Как профессиональный программист, мое решение реализовать дизайн, который, как я знаю, ошибочно, сводится просто к анализу затрат / выгод?
РЕДАКТИРОВАТЬ Хотя все ответы были очень интересными, так как я думаю, что это сводится к выбору индивидуального дизайна, я думаю, что лучшие ответы были @ Corbin's и @EZ Hart's, поскольку они затрагивают вещи, которые я не учел в вопросе:
- ложная дихотомия «правильного удаления жестко запрограммированных значений» путем перемещения их в базу данных против «эффективного применения YAGNI» с помощью жесткого кодирования. Существовал третий вариант размещения таблицы соответствия в конфигурации приложения, которая не влечет за собой лишних затрат правильного способа и без эффективности YAGNI. Мы, как правило, не ограничиваемся ни одним из решений, и затем все сводится к решению по соотношению цена / качество.
- генерация кода может уменьшить накладные расходы на перемещение жестко закодированных значений в базу данных, а также устраняет мое чрезмерно сложное решение обработать CSV в таблице. Потенциально это также добавляет проблему долгосрочного обслуживания сгенерированного кода, если основные требования изменяются для метода поиска. Все это только влияет на анализ затрат / выгод, и, вероятно, если бы у меня была такая автоматизация, я бы даже не подумал о жестком кодировании чего-то подобного.
Я помечаю ответ @ Corbin как правильный, потому что он меняет мои предположения о стоимости разработки, и я, вероятно, добавлю некоторые инструменты генерации кода в свой арсенал в ближайшем будущем.