Слово "хардкод" часто используют как универсальное ругательство. В результате прототип начинают проектировать как промышленную систему еще до того, как понятна сама идея. Это замедляет эксперименты и создает архитектуру для сценариев, которые могут исчезнуть завтра. Мы предпочитаем другой вопрос: что именно мы фиксируем жестко и сколько времени это решение должно прожить.
В эксперименте скорость важнее универсальности
Если мы проверяем композицию одного hero-блока, совершенно нормально временно задать конкретную высоту, текст, координату или набор демонстрационных данных. Ценность кода в этот момент - быстро показать гипотезу.
Попытка сразу построить универсальный движок для всех будущих hero-блоков может занять больше времени, чем сама проверка. Если концепция не сработает, эта архитектура окажется дорогим мусором.
Опасный хардкод начинается там, где скрывается правило
Проблема появляется, когда одно и то же решение повторяется по проекту, но продолжает существовать как десяток независимых значений. Цвет интерфейсной поверхности, основной радиус, системный отступ, брейкпоинт, типографический масштаб - это уже не локальные детали.
Если значение является частью языка продукта, его полезно вынести в переменную, токен или общий компонент еще до перехода к полноценной разработке.
Контент и состояние лучше отделять раньше
Текст конкретной демонстрационной карточки можно временно записать прямо в разметке. Но если карточек становится двадцать и они отличаются только данными, продолжать копировать HTML - плохой сигнал. То же относится к состояниям.
Как только мы понимаем, что элемент существует как повторяемая сущность, полезно отделить его структуру от конкретного экземпляра. Это не обязательно требует сложного фреймворка. Важен сам принцип.
Хардкод не должен маскировать интерактивную логику
Особенно осторожно стоит относиться к поведению, которое зависит от случайных координат, размеров или положения конкретного элемента. Такой прототип может идеально работать на одном разрешении и развалиться при малейшем изменении контента.
Если интерактив должен стать частью продукта, его правила лучше формулировать через сущности и состояния, а не через "если курсор дошел до 742 пикселя".
Перед передачей проекта нужен отдельный проход
Мы не пытаемся запрещать временные решения во время прототипирования. Вместо этого перед передачей в разработку проводим другой тип работы: ищем повторяющиеся значения, одинаковые компоненты, скрытые зависимости, временные данные и локальные исключения.
После такого прохода становится понятно, что можно оставить как особенность прототипа, а что уже превратилось в знание о продукте и должно быть формализовано.
Технический долг - это не любой компромисс
Компромисс становится долгом, когда известно, что решение придется переделывать, но цена этой переделки откладывается на будущее. В прототипе многие жесткие решения вообще не обязаны переезжать в продукт, поэтому называть их долгом преждевременно.
Полезнее фиксировать границу: этот код демонстрационный, а этот уже считается частью будущего поведения.
Хардкод сам по себе не делает прототип плохим. Плохим его делает отсутствие различия между временной декорацией и системным решением. Пока команда понимает эту границу, можно быстро экспериментировать и при этом не тащить случайности в производственный код.