Однажды клиент открыл код прототипа, который мы сделали для проверки его идеи, и пришёл в ужас. Там были жёстко прописанные значения, упрощённая проверка прав, пара мест, где вместо красивого алгоритма стояло честное «если так, то так». Он спросил, не обманываем ли мы его, ведь это же костыли. Я ответил, что да, это костыли, и что именно за них он нам и платит. Разговор вышел долгий и, по-моему, полезный для обоих. Я хочу пересказать его здесь, потому что этот страх перед костылями в первой версии встречается постоянно, и он стоит бизнесу намного дороже, чем сами костыли.
Строительные леса
Ни один нормальный человек не пугается, увидев строительные леса вокруг нового дома. Все понимают: леса нужны, чтобы построить здание, а когда здание будет готово, их снимут. Никто не требует, чтобы леса были из мрамора. Никто не говорит, что дом плохой, потому что сейчас вокруг него некрасивые доски и сетка. Костыли в первой версии продукта это те же леса. Они позволяют быстро возвести конструкцию, проверить, стоит ли она, и понять, нужен ли этот дом вообще.
Проблема в том, что в софте леса невидимы для того, кто не читает код, и поэтому их пугаются, когда находят. Или, наоборот, о них забывают, и через пять лет дом всё ещё стоит в лесах, которые уже срослись со стенами. Обе крайности плохи. Но первая, страх, обычно убивает проект раньше, чем вторая успевает навредить.
Великие продукты тоже начинались на костылях
Первый iPhone, вышедший в 2007 году, не умел копировать и вставлять текст. Эту функцию добавили только через два года. Ранний Twitter так часто падал под нагрузкой, что картинка с китом, которую сервис показывал при сбое, стала мемом, а потом значительную часть системы пришлось переписывать. Это не истории провалов, это истории успеха. Команды выпустили продукт, который работал достаточно хорошо, чтобы люди начали им пользоваться, и уже на живых пользователях поняли, что действительно надо укреплять. Если бы Twitter сначала строил архитектуру на сотни миллионов пользователей, он, скорее всего, не дожил бы до первого миллиона.
Идеальная архитектура для продукта, которым никто не пользуется, это самый дорогой способ ничего не построить.
Почему костыли неизбежны
Первая версия создаётся в момент максимальной неопределённости. Вы ещё не знаете, какие функции окажутся главными, сколько будет пользователей, какие сценарии они выберут, какие данные окажутся важными. Строить «правильную» архитектуру в такой ситуации всё равно что проектировать мост, не зная, через какую реку он пойдёт. Можно, конечно, построить универсальный мост на все случаи жизни, но он будет стоить как десять обычных, и всё равно окажется не там. Костыль это честное признание: здесь мы пока не знаем, как правильно, поэтому делаем просто, чтобы узнать.
Хорошие и плохие костыли
Но не все костыли одинаковы, и вот здесь начинается ремесло архитектора. Есть несколько правил, которые я соблюдаю сам и требую от команды.
- Костыли ставят на периферии, а не в фундаменте. Интерфейс, отчёты, интеграции можно делать на скорую руку. А вот модель данных надо продумать сразу, потому что данные переживают любой код. Переписать экран это день работы. Перенести годы накопленных данных в новую структуру это отдельный проект с риском потерь.
- Каждый костыль записан. Хотя бы одной строкой: что упрощено, почему и что сделать, когда придёт время. Незаписанный костыль это мина. Записанный это долг с понятным графиком погашения.
- Долг планируется к погашению. Технический долг похож на кредит: брать его нормально, жить в нём вечно разорительно. После того как гипотеза подтвердилась, часть времени каждого цикла идёт на то, чтобы снимать леса.
- Нет ничего более постоянного, чем временное. Эту поговорку надо помнить всегда. Если костыль простоял год и никто о нём не вспомнил, возможно, он стал частью здания, и это надо решить осознанно, а не по инерции.
Как это устроено у нас
Мы в Ingello решаем проблему костылей отчасти за счёт технологии. В Fractal схема данных описывается на языке SFL, экраны на IFL, сценарии на ISFL, а генератор порождает из этого код, базу, API и админку. Это значит, что фундамент, модель данных, описан аккуратно с первого дня, а многие периферийные костыли со временем просто исчезают: мы меняем описание и генерируем систему заново, вместо того чтобы годами латать вручную написанный код. Ручные заплатки остаются только там, где действительно нужна уникальная логика, и они видны, потому что живут отдельно от сгенерированного.
Тому клиенту, кстати, я в итоге показал список всех костылей прототипа с пометками, какие из них нужно будет убрать при переходе к рабочей версии и сколько это займёт. Он успокоился не потому, что костылей стало меньше, а потому, что увидел: мы знаем, где они, и знаем, что с ними делать. Страшны не костыли. Страшны костыли, о которых никто не знает.
Что сделать завтра
Если Вы сейчас делаете первую версию, разрешите себе костыли, но заведите для них отдельный список. Проверьте, что фундамент, модель данных, продуман без спешки. А если у Вас уже есть работающий продукт, найдите в нём три самых старых «временных» решения и честно решите: снимаем леса или признаём их частью дома. Любой из ответов лучше, чем молчание.
