Итак, вы начинаете бизнес в Интернете и выбираете стек технологий. Вот что я могу сказать по этому поводу после того, как в течение 13 лет управлял программным стартапом с нулевым финансированием.
Предупреждение: впереди крайне самоуверенные и откровенные заявления.
Выбор стека
Существует множество (веских) причин, по которым вам следует выбирать один стек (фреймворк, язык программирования) вместо другого. Например, «проверьте экосистему» или «подумайте о будущих наймах».
Также есть много дерьмовых и бессмысленных советов, таких как «ставьте пользователей выше технологий» или «всегда используйте открытый исходный код».
Но самым важным критерием номер один является способность быстро двигаться. Период.
Когда-то был термин «RAD: быстрая разработка приложений», который в наши дни используется редко (и не имеет никакого отношения к нашей теме), но именно этим вы будете, надеюсь, и будете заниматься в следующем десятилетии.
БЫСТРАЯ разработка.
Молниеносные изменения. Быстрый поворот. Редизайн всей панели инструментов за один день. Выявление критической ошибки, не глядя на свой код, потому что вся кодовая база умещается в вашей голове. И исправление ошибки с помощью мобильного телефона во время поездки в метро (добро пожаловать в жизнь основателя-одиночки).
Вот почему единственный рабочий совет здесь - использовать то, что вы уже знаете. Желательно что-нибудь монолитное. То, что было давно. С минимумом абстракций и минимум шумихи. Но самое главное то, что вы знаете лучше всего.
Почему одержимость «скоростью»?
Чтобы свести к минимуму время, затрачиваемое на «технические» задачи.
У вас будет много «некодируемых» вещей. Изучение рынка, проверка вашей идеи, интервьюирование потенциальных клиентов, получение первых платящих пользователей, затем масштабирование метода привлечения клиентов, затем поворот, затем снова поворот, а затем снова - пока вы не доберетесь до продукта, подходящего для рынка ...
Джоэл Тест - начальная версия
Вряд ли осталось кто-нибудь, кто не слышал о Джоэле Тесте в наши дни.
Вот исходный список Джоэла (на все это нужно ответить «да»):
- Используете ли вы систему контроля версий?
- Сможете ли вы сделать сборку за один шаг?
- Вы делаете ежедневные сборки?
- У вас есть база данных об ошибках?
- Исправляете ли вы ошибки перед написанием нового кода?
- У вас есть актуальное расписание?
- У вас есть спецификация?
- Есть ли у программистов спокойные условия работы?
- Используете ли вы лучшие инструменты, которые можно купить за деньги?
- Есть ли у вас тестировщики?
- Пишут ли новые кандидаты код во время собеседования?
- Вы проводите юзабилити-тестирование в коридоре?
Вот отредактированный список, учитывая, что вы (1) занимаетесь начальной загрузкой, (2) вы команда из 1–3 человек и (3) сейчас офигительный 2019 год.
- Используете ли вы s̶o̶u̶r̶c̶e̶ ̶c̶o̶n̶t̶r̶o̶l̶ GitHub, GitLab или Bitbucket?
- Можете ли вы m̶a̶k̶e̶ ̶a̶ ̶b̶u̶i̶l̶d̶ запустить модульные тесты, создать сборку и развернуть все за один шаг?
- Вы m̶a̶k̶e̶ ̶d̶a̶i̶l̶y̶ ̶b̶u̶i̶l̶d̶s̶ используете CD / CI? Ничего страшного, если нет, не зацикливайтесь на этом.
- D̶o̶ ̶y̶o̶u̶ ̶h̶a̶v̶e̶ ̶a̶ ̶b̶u̶g̶ ̶d̶a̶t̶a̶b̶a̶s̶e̶? Вероятно, да, см. №1
- Исправляете ли вы ошибки перед написанием нового кода?
- Есть ли у вас план действий n̶ ̶u̶p̶-̶t̶o̶-̶d̶a̶t̶e̶ ̶s̶c̶h̶e̶d̶u̶l̶e̶?
- D̶o̶ ̶y̶o̶u̶ ̶h̶a̶v̶e̶ ̶a̶ ̶s̶p̶e̶c̶? (вы, очевидно, не делаете)
- У программистов спокойные условия работы? (Также известное как «работа удаленно»)
- Используете ли вы лучшие инструменты m̶o̶n̶e̶y̶ ̶c̶a̶n̶ ̶b̶u̶y̶?
- D̶o̶ ̶y̶o̶u̶ ̶h̶a̶v̶e̶ ̶t̶e̶s̶t̶e̶r̶s̶? Есть ли у вас модульные тесты и UI-тесты с использованием Selenium, Phantom JS или аналогичной технологии?
- Пишут ли новые кандидаты код во время собеседования?
- Вы проводите юзабилити-тестирование в коридоре? AKA проводит аудит UX или просто показывает приложение супруге
Без микросервисов
(сказал, что это будет самоуверенный)
Разбить приложение на более мелкие части выглядит очень заманчиво. Эй, это сработало для Google, Amazon и Facebook, должно работать и для вас! Но это не так.
Причина, по которой Google и Amazon делают это, заключается в том, что, когда вы достигаете определенного масштаба, просто нет другого пути, чтобы все это было скоординировано. Это была необходимость, а не выбор.
Делайте прямо противоположное: старайтесь не разбивать приложение на более мелкие объекты как можно дольше. Если только вы не хотите, чтобы ваш код превратился в «не подлежащий модульному тестированию», «не развертываемый», «неконтролируемый» кошмар.
Нет JS-фреймворков
(если это не то, что вы уже знаете лучше всего)
JS-фреймворки - это новые «серверные страницы Java». JS-фреймворки - это новые «веб-формы ASP.NET». JS-frameworks - это новый «сервер BizTalk», новый «JavaBeans».
Вы, наверное, слишком молоды, чтобы все равно вспомнить, что это такое. Мне 42 года, поверьте мне. Я видел это раньше. Взгляните на этот код:
<div>
<ex:Hello>
This is message body
</ex:Hello>
<c:if test="${myVar > 2000}">
<p>The variable is: <c:out value="${myVar}"/><p>
</c:if>
</div>
Эй, можно даже сказать, что код читабельный! Это даже похоже на какой-то модный современный фреймворк, не так ли?
Но это не так. Это JSP. Выпущено еще в гребаном 1999 году.
Или это:
<div> <asp:DataGrid ID="Grid" runat="server" ForeColor="#333333"> <Columns> <asp:BoundColumn HeaderText="EmpId" DataField="EmpId"> </asp:BoundColumn> <asp:BoundColumn HeaderText="F_Name" DataField="F_Name"> </asp:BoundColumn> <asp:BoundColumn HeaderText="L_Name" DataField="L_Name"> </asp:BoundColumn> </Columns> <FooterStyle BackColor="#990000" Font-Bold="True" ForeColor="White" /> </asp:DataGrid> </div>
Это «Веб-формы ASP.NET», ребята. Опять же, из 2001 года
Все эти фреймворки были начаты с добрыми намерениями, но в итоге превратились в дерьмовые абстракции со своими собственными «тегами», своими собственными «атрибутами», скрытой логикой и уровнями «API», через которые вам пришлось пробиваться.
То, что когда-то было тривиальным в HTML, внезапно превратилось в беспорядочный обходной путь. Если - не дай бог - вам нужно отрендерить что-то, что не является частью фреймворка - вы застряли на хаках и спагетти-коде.
Вот почему с появлением «обычных» легких фреймворков - таких как «ASP.NET MVC», «Ruby on Rails» и «Laravel» - все бросили чудовищных чудовищ и больше не оглядывались назад.
Мир JS сейчас просто переживает тот же цикл. И нам - старым пердунам - все это очень знакомо.
Так что да, никаких модных JS-фреймворков. Вы можете добавить невидимый JS-слой без трения, который прекрасно сочетается с вашим существующим кодом (например, Stimulus или даже Vue). Но обработанный на стороне сервера HTML (с примесью JavaScript) всегда будет - как придумал @DHH - возвратом к тому моменту, когда один-единственный программист мог добиться хищных успехов, не застревая в слоях косвенного обращения. В этом посте.
Если этого достаточно для GitHub и Basecamp, значит, и для вас.
(UPD: для ясности, под «фреймворками JS» я подразумеваю такие библиотеки, как Angular, Ember, React и другие чудовища, а не легковесные и не jQuery. И позвольте мне повторить: если вы эксперт в JS-framework - дерзайте. Только не «пробуйте, потому что все делают»)
«2.0» - всегда плохая идея
А теперь вернемся к Джоэлю. Переписывать приложение с нуля - всегда плохая идея. Это одна из вещей, которые вам никогда не следует делать. Перезапись волшебным образом не решит ни одной из ваших проблем. Но он представит новых и отпугнет ваших существующих пользователей.
Если, конечно, вы не финансируемый стартап, и вам нужно оправдывать новых сотрудников перед инвесторами (в этом случае JS-фреймворки - отличная идея).
Мониторинг и устранение ошибок
Напишите тесты после исправления ошибок. Если что-то действительно серьезная и сложная ошибка, вы больше никогда не захотите ее видеть. Напишите тест, чтобы предотвратить это.
Расставьте приоритеты и сначала исправьте те, которые могут повредить конверсии. Напишите тест пользовательского интерфейса для подписки на пробную версию приложения SaaS.
Отслеживайте использование функции. Я люблю убивать фичи. Если функция используется менее 0,5% ваших пользователей, мы скрываем ее в пользовательском интерфейсе, чтобы не загромождать приложение - мы просто не показываем флажок, если он выключен.
Отслеживайте исключения и простои. Обработка исключений на стороне сервера и отправка уведомления по электронной почте, как правило, проста. Обработка ошибок на стороне клиента может быть более сложной, я бы порекомендовал использовать такой инструмент, как Sentry (есть бесплатный план входа).
Избегайте ажиотажа
Как правило, не гонитесь за ажиотажем. Не используйте Go, потому что это новая крутая штука. Не используйте кластер NoSQL потому что он масштабируется в сети, реляционная база данных может работать нормально. Быть крутым ребенком - заманчиво (а использование крутых технологий может быть очень важным компонентом сохранения мотивации), но есть и другие способы поддерживать себя в восторге (можно назвать один из них).
Как стартап, ваш главный приоритет - быстро выйти на рынок. Помните об этом, когда принимаете решение и ставите реалистичные цели и вехи. Быстрое выполнение задач - это то, что вам нужно. Не в масштабе Facebook.
Первоначально опубликовано на www.jitbit.com.
