Пули и шипы: учимся использовать костыли по уму

Пули и шипы: учимся использовать костыли по уму

Продолжаем рассказ о костылях в коде: в первом посте мы поговорили о том, как делать не надо, а сегодня разберём, как использовать костыль по уму (и можно ли это вообще делать!).

Вопреки популярному убеждению о «костылях» как о ругательстве, мы должны признать: костыли спасают проекты от вечного этапа разработки. Если они сделаны обдуманно, это не слабость, а признак зрелости проекта.

Более того, многим гигантам IT именно костыли помогли выжить и вырасти. Чтобы не быть голословными, приведём несколько примеров.

Микросервисы у Amazon не появились как «гениальная архитектура». Сначала это были просто «заплатки», чтобы отделить узкие места от монолита. Со временем эти «костыли» превратились в архитектурное решение, которое стало индустриальным стандартом.

Еще один хороший пример: Facebook в начале 2000-х строился на обычном PHP. Когда стало понятно, что это не тянет, они сделали «костыльное» решение — JIT-компилятор HHVM, а потом язык Hack. Это подарило компании годы стабильной работы, прежде чем им удалось перейти на более фундаментальные оптимизации.

Когда костыль становится проблемой

Хороший костыль должен быть управляемым. Иначе он превращается в «технический цемент»:

Нет документации → через полгода все забывают, что это временное решение
Нет срока → «потом перепишем» растягивается на годы
Нет изоляции → костыль прилипает к бизнес-логике и его уже не вытащить

Может ли «костыль» быть правильным?

Конечно, если следовать общепринятым подходам формирования костылей. Расскажем подробнее про два из них.

Tracer Bullet Development: пули, которые показывают путь

Представьте трассирующую пулю: она не убивает, но показывает траекторию. Так и здесь — вместо идеального решения делаем рабочий сквозной путь.

Такой подход позволяет реализовать необходимую функциональность для запуска проекта и даёт время на тщательную проработку без ущерба бизнесу.

Простой пример: чтобы собрать форму регистрации на сайте, необходимо собрать и разработать несколько модулей, подключить базу данных, валидацию и так далее. А можно поступить проще:
Простая форма → отправка в API → сохранение в БД → мгновенный вход.
Да, нет подтверждения почты и сложной валидации, но пользователь уже может работать! А в этот момент остальная команда строит функционал вокруг этого ядра, не блокируя при этом работу всего сервиса.

Spike Solution: исследовательские шипы

Spike — одноразовый код для проверки гипотезы. Как тест-драйв автомобиля: не для поездки в отпуск, а чтобы понять, подходит ли он.

Такие шипы не сохраняют в проекте — они помогают быстро протестировать нужную фичу и идти дальше, к более детальной проработке. Главное — изолировать такой код от продакшена!

Отличие от tracer bullet:
Tracer bullet → остаётся и развивается
Spike → выбрасывается после получения ответа

Подведем итоги: костыли – не всегда зло, а обдуманные костыли помогают командам быстрее двигаться вперёд, проверять гипотезы на практике и запускать функционал без долгого проектирования.

Кстати, удивительно, но факт: в продакшне у Google, Amazon или Netflix костылей прямо сейчас живёт немало, но они — управляемые и документированные.

А вы сталкивались с костылями, которые спасли проект?