Жесткое кодирование против общего кодирования: где провести черту?

Question

Я не совсем уверен, как это сказать, но я попробую.

Предположим, у вас есть некоторые настройки в какой-то части вашей программы, и ваши 80% уверены, что вам больше никогда не придется вносить изменения. Как вы знаете, где провести черту на изменяемом коде? Вы знаете, что перенести настройки полностью в пользовательский XML-файл - это излишне. Тем не менее, вы также знаете, что существует небольшая вероятность того, что эти настройки придется изменить позже, с небольшой вероятностью 20%, поэтому кодирование их в месте, где резина встречается с дорогой, также не является оптимальным.

Полагаю, я пытаюсь спросить, как далеко вверх по дереву абстракций вы должны позволить легко изменять вашу программу?

Одним из многих примеров является написание HTML-кода для веб-сайта вручную по сравнению с тем, когда программа его автоматически генерирует. Написание HTML-кода напрямую не занимает слишком много времени. Написание программы для автоматической генерации HTML-кода занимает гораздо больше времени.

Answer 1

Это хороший вопрос, но на него нет абсолютного ответа:

Как отметил Эйнштейн:

Сделайте вещи максимально простыми, но не проще.

Простота относительна. Принятие лучшего решения о количестве уровней абстракции в дизайне - вот что делает великого архитектора великим. Хороший архитектор должен всегда оценивать конкретную ситуацию и находить лучший компромисс. Там нет никаких серебряных пуль.

Answer 2

Я попробую, моя философия такова:

1 - Сохраняйте конфигурационный файл и класс / функцию синтаксического анализатора, которые чрезвычайно глупы и максимально просты, чтобы дать вам душевное спокойствие, что всякий раз, когда вам что-то нужно из этого, вы можете получить это без необходимости создавать смехотворно перегруженный XML хруст парсера конфигурационных файлов. Мой конфигурационный файл выглядит так:

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

Я извлекаю из него все, что мне нужно, используя статический вспомогательный метод (маленькие приложения) или одиночный экземпляр (большие приложения, управляемые MVC), сгенерированный моим другом-идиотом ConfigHelper, который настолько глуп, что не знает, как генерировать накладные расходы.

У меня возникает эта дилемма несколько раз в течение моего среднего рабочего дня: я должен поместить это в config.txt или сделать его константой класса? Мой ответ - я просто не знаю - пока намного позже. Если окажется, что его нужно было поместить в конфигурационный файл, ничто не сравнится с достойной IDE со стабильной реализацией 'Find & Replace In Projects' для смены ссылок.

3 - Конфигурационные файлы избавляют от кошмаров при развертывании приложений, когда разработка включает в себя тестирование сервера, а затем развертывание в производство - реальной практической альтернативы нет. Я понимаю, что разные экземпляры базы данных на разных компьютерах имеют разные IP-адреса в мире.

Одним из многих примеров является написание HTML-кода для веб-сайта вручную по сравнению с тем, как программа его автоматически генерирует

Это так верно. Хотя нам, как разработчикам, нравится создавать машины, мы, как правило, тратим много времени на сборку машин, чтобы создать машину, которую мы изначально собирались построить. Хотя это может быть чрезвычайно приятно, из своего опыта я могу сказать, что в большинстве ситуаций, чем больше у вас машин, чем больше систем вы должны поддерживать, тем больше точек отказа, тем больше хлопает рука от владельцев бизнеса - и это не весело. Кроме того, вы будете склонны сталкиваться с ситуациями, когда промежуточный генератор HTML не может дать желаемый результат. Так что же делать, тратить время на исправление ошибки в генераторе, тратить время на разработку обходного пути вуду или просто писать вручную HTML-код? Это действительно зависит от конкретных обстоятельств, но я предпочитаю последнее.

Было немного напыщенно, но надеюсь, что это помогло ответить на ваш вопрос, хотя бы немного.

Answer 3

За последние четыре года эта старая собака научилась новому трюку с TDD. Даже когда у меня нет времени, чтобы сделать «настоящий» TDD, я притворяюсь, что я делаю.

Поэтому я всегда пишу повторяющийся код. Что нормально, потому что я всегда рефакторинг потом. Это часть процесса написания кода, а не то, к чему можно будет обратиться позже. Так как я следовал TDD и написал только минимально необходимый код, и так как у меня есть автоматические тесты, доказывающие, что код работает, если я найду дублирование, я могу с комфортом реорганизовать его, зная, что буду снова запускать свои тесты во время и после рефакторинга. Это еще раз докажет, что я ничего не сломал.

Таким образом, я не размышляю о том, будет ли код повторно использоваться - я никогда не рефакторинг, пока он не будет повторно использован. Поскольку он создается в каждом экземпляре в соответствии с потребностями экземпляра, я знаю, что вызывающий код не искажен желанием сделать код универсальным. Вызывающие, в том числе модульные тесты, были написаны для удовлетворения их насущных потребностей. Отдельный проход рефакторинга обрабатывает более широкую потребность, чтобы не дублировать код.

Answer 4

Ваш вопрос был направлен на фактический дизайн кода, а не на то, помещать ли переменные в файл конфигурации или в константы. Я согласен с другими ответами относительно этих аспектов.

Но что касается написания обобщенного кода ...

По моему опыту, если вы будете писать код специально для решения поставленной задачи, вы обнаружите, что будете писать подобный код только в какой-то момент в будущем. Хорошо, если вы действительно сделаете задачу только один раз, все в порядке. Но я считаю, что в большинстве случаев это не так.

Если вы обнаружите, что повторяете задачу на всех , вам следует сделать шаг назад и подумать, что нужно сделать, чтобы автоматизировать ее в общем виде.

Также убедитесь, что кто-то еще этого не сделал. Если это не так, рассмотрите возможность публикации своего кода, каким бы маленьким или грубым он ни был. Кто-то может улучшить это для вас, бесплатно.

Answer 5

Два очка:

• Все константы должны быть общими, т. Е. Никогда не кодировать магические числа жестко, не помещая их в описательную константу.
• Реализуйте минимум, который вам действительно нужен, - жестко кодируйте его, пока вы не собираетесь дублировать жестко закодированный код более одного раза - в этом случае вы должны начать делать код универсальным. (Test Driven Development здесь просто потрясающий).

Answer 6

80%? Недостаточно хорош для жесткого кода, поместите его в файл конфигурации.

100%? Константа может сделать.