Сарайчик или музей: как выбирать между быстрым MVP и идеальной архитектурой

[stikhonchuk]

Хорошо подмечено про сарайчики и музеи!

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

Строя музей, мне кажется, можно попасть в ловушку, что идеальная вещь сама себя пиарит, и не утруждать себя продвижением. Но для пользователя с первого взгляда музей не отличим от сарайчика.

[OlegZH]

Вопрос не в том, что важнее: хороший код или быстрый выход на рынок.

На это можно посмотреть с совершенно с другой стороны. Если кто-то хочет выйти на рынок, то у него должны быть изначально свои рабочие инструменты. У электрика (прежде чем пойти к клиенту) есть свой инструмент, у сантехника — свой. А у программиста? Можно себе представить, что у программиста тоже должен быть какой-то набор инструментов. Если есть какая-то предметная область, то надо предварительно иметь какие-то библиотеки и фреймворки.

Нужно выбирать уровень технических инвестиций, соответствующий зрелости продукта, неопределённости и цене ошибки.

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

В этом смысле, мне очень понравилось такое высказывание:

Производительность позволяет выполнить работу. Эффективность позволяет выполнить работу правильно. (Зиг Зиглер)

[Цитируется по книге "Операционные системы" (Дейтел и др., 2006).]

[Berrimor]

Согласен с идеей про собственный набор инструментов. Зрелая команда не должна каждый раз с нуля придумывать CI/CD, логирование, авторизацию и базовую наблюдаемость. Это накопленный инженерный капитал, который действительно делает каждый следующий запуск дешевле.

Но я бы разделял готовые инструменты и готовый ответ. Предыдущий опыт помогает быстрее начать, но новая предметная область почти всегда ломает часть исходных предположений. Если ещё до проверки гипотезы начать строить универсальный фреймворк под будущий продукт, можно незаметно получить тот самый музей.

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

[merkel]

Как говорила моя первая жена, хорошо у меня получается со второго раза... щютка.

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