– Алло, это хардкор?
– Алло, это харткот?
– Техническая поддержка, здравствуйте! Время пришло.
Пожалуй, да, настало время, и этот одноименный анти-паттерн программирования, послуживший основой для названия нашей компании, стал достоин отдельной статьи.
Проведя небольшой опрос среди наиболее осведомленных клиентов, коллег и соискателей, что же они понимают под термином “Хардкод” (Hard coding), я получил множество самых неожиданных ответов. Удивительно, но оказалось и сами разработчики не всегда понимают глубинный смысл хардкода – даже считают его некачественным кодом и путают с “говнокодом”.
Не будем отбирать хлеб у википедии, копируя определение хардкода, а поговорим о его практическом смысле и применении. Статья предназначена для людей, далеких от программирования, поэтому, на мой взгляд, проще всего понять смысл термина на простом примере (на котиках), насколько это возможно, не погружаясь в технические детали.
Речь, конечно же, пойдет о сайтах и решении повседневных задач. Но для начала давайте определимся с критериями качества задач, чтобы разница в подходах была максимальна заметна. Ниже минимальный список требований, актуальный для любого проекта и задачи.
Стоимость разработки.
Нет, здесь я не буду говорить о ценообразовании – это отдельная история. Сегодня я ваш капитан-очевидность и со всей ответственностью заявляю: “Цена – это критерий номер раз!”
Сроки выполнения работ.
Достойным продолжением в списке требований является дедлайн. Задача должна быть выполнена в срок, пока ее не реализовали конкуренты или того хуже — пока идея морально не устарела и стала ненужной. Итог один – можно расходиться.
Работоспособность.
Результат должен в точности выполнять поставленную задачу в заранее оговоренных условиях. Иными словами, корректно работать.
Дальнейшая поддержка кода.
Как говорится “last but not least – последний, но от этого не менее важный”, и, к несчастью, это самый недооцененный фактор.
Говорит он о возможности через полгода-год без особого труда продолжить работу с проектом и, что не менее важно, с новыми сотрудниками/техподдержкой/командой.
С людьми, не принимавшими участие в разработке первых версий. Этот фактор актуален для более или менее объемных задачах, разработка которых, ввиду затраченных усилий, сроков и стоимости не позволяет выбросить результат в помойку.
Хардкод «на котиках»
Представьте, у вас есть интернет-магазин, где все расчеты (купоны, акции, налоги, прайсы поставщиков, услуги доставки, т.д.) ведутся в рублях.
И вот появляется задача – проверить спрос на ваш ассортимент в ближайших странах-соседях, куда проще всего осуществить доставку.
Для этого цены в магазине должны быть как минимум в долларах и евро.
Вы встречаетесь с рабочей группой для обсуждения деталей технического задания.
Оказывается, система управления вашего магазина не имеет готовых решений для использования нескольких валют, и банк не предоставляет данные курсов валют в удобном формате, что обеспечивает многократное увеличение сроков и стоимости разработки конвертации.
Что делать? Надо спешить, пока никто еще не поставляет эти уникальные товары на зарубежные рынки, ведь так важно оказаться первым.
И вот через два месяца с новым магазином или доработанным старым вы получаете:
- — несколько тысяч тщательно задокументированных строк кода.
- — инструкцию по настройке для администратора, пользователей.
- — ежедневную синхронизацию с несколькими банками.
- — возможность указать корректирующие коэффициенты для любой валюты.
Но, к сожалению, слухи о высоком спросе на данный ассортимент разлетелись очень быстро, и ваш магазин встал в очередь из ему подобных, да еще с ценой выше средней по рынку, ведь появились дополнительные расходы на разработку.
Искренне сочувствую, если эта история вам знакома и напомнила о былых неудачах. Это как раз тот самый случай, где оптимальным решением может стать хардкод. А именно – конкретно в данном примере достаточно жестко прописать курс валюты непосредственно в коде или максимум с одним единственным полем для его ручного редактирования по мере необходимости, без автоматической интеграции.
Сплошная польза и очевидный профит.
Стоимость, сроки.
Технически такое решение занимает на порядок меньше строк кода, задача выполняется в разы быстрее, стоит дешевле.
Работоспособность.
Очевидно, для посетителей нет разницы, как это работает внутри, если они так же могут совершать покупки.
Дальнейшее сопровождение, доработки.
Ввиду того, что мы говорим не о халатности, а об одном из вариантов подхода к решению задачи, я не рассматриваю случай, когда разработчик поленился оставить комментарии к внесенным изменениям, после чего не понятно, с какой стороны подойти к еще недавно полноценному интернет-магазину.
Значит, ничто не мешает в случае успеха проверки вашей бизнес-гипотезы заменить несколько строк кода, обозначенных комментариями, для пересчета стоимости товара на более гибкое, функциональное решение.
В этом весь смысл правильного хардкода, когда его используют во благо. И, как бы странно это не прозвучало, но хардкод может быть действительно качественным и эффективным решением. Если вы ограничены по времени или существует риск, что функция не будет востребована, то такой подход сэкономит вам значительное количество сил и средств. Ведь главное – это своевременно ответить на вопрос конечного потребителя, выполнить поставленную задачу и оправдать его ожидания.