Выбор стека через proof of concept

Выбор технологии, защищённый фразой «мы это умеем», иногда верен и никогда не проверяем. PoC делает его проверяемым — но только если его ведут как процедуру принятия решения, а не как раннюю версию продукта.

00 / PoC — это вопрос со сроком

От прототипа его отличают три вещи: вопрос, на который разрешено ответить «нет», критерий, согласованный до первой строки кода, и дата, когда он заканчивается. Уберите любую — и PoC тихо становится первой версией системы: демо уезжает в продакшен, вопрос никто не перечитывает, а стек оказывается выбран невозвратными затратами.

Вопрос должен уметь провалиться. «Сможем ли мы сделать это на X?» не умеет: ответ всегда «да», было бы время. «Во что нам обойдётся X на том участке, которого мы боимся, за два дня?» умеет.

01 / Сделайте сравнение сравнимым

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

Три способа это испортить, и все три обычные:

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

02 / Критерии, которые переживут совещание

В потребительском продукте, описанном отдельным кейсом, язык бэкенда выбирали несколькими PoC, а не по предпочтению, по четырём критериям: масштабируемость, сопровождаемость, скорость и то, насколько кодовая база подойдёт для разработки с AI. Go вышел из этого баланса, остальные части стека решались так же.

Три критерия из четырёх обычные, и каждый стоит превратить из прилагательного в вопрос с ответом:

Масштабируемость — что происходит при десятикратной и стократной нагрузке к ожидаемой и сколько это там стоит? Померьте; не рассуждайте по странице вендора.
Сопровождаемость — сколько времени нужно человеку, который этот код не писал, чтобы безопасно внести небольшое изменение? Это число, и PoC — самый дешёвый момент его снять, пока кодовую базу ещё можно прочитать за час.
Скорость — системы и команды. Быстрый рантайм, на котором в команде никто бегло не пишет, медленный.

03 / Критерий, который почти никто не проверяет

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

Это проверяемо, и мерить нужно ревью, а не выдачу. Отдайте ассистенту одну и ту же задачу в каждом кандидате и посмотрите:

сколько из вернувшегося оказалось верным, а сколько — правдоподобным и неверным;
что отсёк компилятор или система типов раньше, чем это пришлось делать человеку: стек, где неверный код не собирается, дешевле стека, где он запускается и падает позже;
покрыла ли стандартная библиотека то, подо что ассистент иначе затянул бы зависимость, — потому что зависимости, выбранные автодополнением, это решение о сопровождении, принятое никем;
решено ли форматирование инструментом, чтобы диффы были про логику, а не про стиль;
сколько времени заняло прочитать результат — то самое число, которое растёт вместе с командой.

Большой публичный корпус помогает. Но это не вся история: чем шире поверхность языка, тем больше в нём мест, где можно уверенно ошибиться, и тем больше ревьюеру приходится держать в голове, чтобы это поймать.

04 / Право ответить «нет»

PoC отвечает и на вопрос «оставляем ли то, что уже есть». На том проекте существовала более ранняя кодовая база, написанная одним разработчиком больше чем за год до того, и для начинаемого объёма она давала мало опоры. Это законный результат, и ему нужны тот же записанный вопрос и тот же срок, что и любому другому. Иначе обсуждение уезжает в сторону предыдущего автора вместо кода.

Когда вопрос закрыт, PoC нужно удалить — или осознанно развить, с планом по тем частям, которые так и не были доделаны. Оставленный «просто для справки», он попадает в копипаст.

05 / Половина, которую PoC не покрывает

Решение по языку на том проекте учитывало разработку с AI. Рабочий процесс вокруг неё с самого начала не стандартизировали, и результат часто не совпадал с общими ожиданиями команды, его приходилось переделывать, и это снижало качество в целом. Это то, что я сделал бы иначе, и это не проблема инструментов.

Оценка технологий отвечает на вопрос какой инструмент. Она не отвечает на вопрос как мы работаем: как выглядит задача до того, как её отдали ассистенту, что теперь проверяет ревью чего не проверяло раньше, что пишется руками и что никто не вливает, не прочитав дважды. Второй вопрос заслуживает такого же осознанного обращения, как первый, и обычно не получает никакого — потому что по нему нечего показать в конце недели.

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