Хабрахабр

Современная веб-разработка: выбери себе приключение

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

Uber for X, или там еще что-нибудь в таком духе. Предположим, что я и мой друг Валерка решили сделать стартап. Надо сделать. Собрались в баре, обсудили эту идею, клёвая тема. Разрабатывали. Три месяца не спали, не ели, не выходили из дома. Запустили и поняли, что это никому не нужно.

Попробуем еще раз. Печаль. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Круто, идем дальше. Прототип взлетел.

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

Язык

На каком языке писать? По порядку. Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.

Можно взять что-нибудь проверенное временем. Попытка номер два. Это неплохой язык, его модно иногда критиковать, у него есть свои минусы, но на нем легко делать бизнес-логику, он достаточно быстрый, неплохо масштабируется, можно нанять людей когда угодно и где угодно. Например, PHP. Поэтому нам нужно либо много железа, либо писать свой компилятор, как сделали Facebook или ВК. Но он не очень производительный.

Можно взять Perl, но тогда будет некого нанимать ещё вчера. Еще варианты? Java — норм. Ещё?
Java. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много.

В принципе, у него всё ок. Ладно, у нас есть еще Python. Либо можно взять что-то современное: Go, Rust, еще что-то. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Пусть в итоге это будет JS, сойдет. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать.

База данных

JS без документной базы — деньги на ветер. База. Они позволяют нам быстро разрабатывать прототипы, не париться насчет схемы, колбасить данные туда-сюда. У документных баз есть свои плюсы. Когда коллекций у нас становится десять, двадцать или сорок вместо трёх, когда мы без отсутствия схем пытаемся склеить из них что-то хорошее и удобоваримое, становится это делать все сложнее. Плюсов много, минус один: каша из данных. Опять долго делаем фичи.

MySQL, PostgreSQL, или Oracle, если денег хватит. Ок, давайте возьмем реляционную базу. Это не обязательно произойдёт с нашим проектом. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. Долго делаем фичи.

Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Ладно. Когда-нибудь (spoiler: никогда).

Архитектура

Ребята на Хабре пишут, что микросервисы – это клёво. Какую взять архитектуру? Олег Бунин говорит: «берите микросервисы».

Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Сервисы уже работают в продакшене, а мы их не тестируем. Поэтому мы долго делаем фичи.

Это самая правильная идея для стартапа. Ок, тогда давайте бахнем монолит. Но если мы решим сильно расширить команду, то надо быть осторожнее. Очень долго можно жить с отличным монолитом и не иметь проблем. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей. Монолит нормально масштабируется, пока разработчиков 20, 30, 50.

Где запускать проект?

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

Может, это не так ресурсоэффективно изначально, но в долгосрочной перспективе, вероятно, обойдётся дешевле, чем хоститься в облаке. Можно арендовать дата-центр. По моему опыту, те, кто это любят и умеют делать, не очень любят общаться со всеми остальными, поэтому они организуются в отдел. Но тут нужны люди, которые это будут поддерживать. Я имею в виду то, что внутри команды админов будет легче обмениваться опытом, но в будущем это может работать не очень хорошо. А отдел – это сепаратизм. Другие специалисты не будут знать, что происходит внутри отдела, который поддерживает наш дата-центр.
В общем, сепаратизм нам не подходит. Будут вопросы с приоритезацией задач от других коллег, с синхронизацией. Логично переходим к вопросу набора команды.

Разработка

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

  • токсичными пижонами, которые ничего не будут делать и создадут плохую атмосферу в коллективе,
  • либо идеалистами, выстраивающими по крупицам безукоризненную архитектуру, ставящими ORM перед базами, которые никогда менять не придется...

Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. В итоге… да-да, долго делаем фичи. Это не очень эффективно. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Начальник может читать весь код. Как это можно решить? Понятно, это не масштабируется и все медленно делают фичи. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли).

Для многих языков он уже есть, и можно его просто соблюдать. Более правильный вариант — определить кодстайл для компании. С таким аргументом уже не поспоришь, но на деле это не сильно лучше предыдущего варианта, все равно мы медленно делаем фичи. Либо если кому-то очень хочется, можно взять готовый и подтюнить немного, и потом смотреть на пуллреквестах и говорить, что здесь фигурная скобочка не там стоит, по кодстайлу должна стоять там. Правильный вариант для всех современных языков — проверять это автоматически.

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

Quality Assurance

Многие так делают, это иногда работает. Можно сказать, что QA-специалисты нам не нужны. Их можно понять. Но не все разработчики любят писать тесты. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги.

Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.

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

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

Общаться с коллегами в кружках по интересам. Как это разрулить? Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити… Где-то это называют гильдиями, где-то — коммьюнити.

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

Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. А ещё — всё это интересно. Интересно делиться знаниями.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть