Я работал в команде, которая делала десктопное приложение для VPN. Не самая простая штука в мире, много нюансов, много обратной совместимости. У нас были четыре разраба, три тестера, продукт оунер, проджект менеджер, сторонняя команда дизайнеров. Все по-серьезному. Помимо десктопного клиента делалась ещё и либа, которая содержала в себе всю бизнес-логику, и использовалась на других платформах. И эта либа в свою очередь использовала сишный бинарь, который и поднимал VPN туннель.
Если бы меня кто-то спросил, за сколько можно сделать такое приложение в одиночку — я бы сказал: «два месяца на разработку, один на тестирование». Но нас было много, поэтому мы работали больше двух лет.
Каждый человек, причастный к проекту, увеличивал общее непонимание этого проекта. Есть куча практик, чтобы бороться с этим — мы пишем документацию, формализуем требования, заводим специальных людей, у которых задача — понимать что за проект, и всем это объяснять. И в краткосрочной перспективе это даже работает — но впоследствии каждая страница документации на большом проекте начинает противоречить другим, и становится ещё одним источником проблем — ещё одной штукой, чье развитие мы должны суппортить, не понимая, как, и зачем.
Чем больше пользователей становится у приложения, тем больше само приложение, чем оно больше, тем больше команда, и тем меньше вы понимаете, что и зачем делаете. Если у меня есть механизм из одной шестеренки, у которой надежность 50%, значит его надежность — 50%. Если в нем две шестеренки, надежность будет 25%, а если шестеренок десять — надежность будет близка к нулю.
На одном из викли к нам пришёл какой-то важный хозяин тестировщиков, и попросил сделать ему тестовое приложение. Десктопную штуку, которая позволяла бы применять и комбинировать все возможности нашей либы. Без задания на дизайн, без четких требований.
Я сделал приложение за неполный месяц — и оно было гораздо фичастей основного проекта. При этом я не забывал хорошенько отдыхать в рабочие часы.
Работать вот так — легко. Я не потратил три месяца на создание странного «дизайнерского» аналога гамбургер-меню. Ни одного нелепого кастомного контрола. Все из популярной материал либы. Я сразу точно знал, что за проект должен получится в итоге, и не тратил время на создание кода, который будет переписан через неделю. Я не тратил время на написание кучи юнит тестов, которые ничего не проверяют. И не оверинженерил, потому что сразу понимал — требуется сделать достаточно простую штуку.
Я не зеленый джун, у меня есть привычка сразу писать плюс-минус неплохой и читабельный код. Контекст предметной области был у меня в голове, я получил десяток замечаний на ревью, быстро пофиксил, и проект был готов.
После этого я, конечно, не пришел к убеждениею, что так должны делаться абсолютно все проекты. В бизнес-приложениях, которыми пользуется много людей, так не работает. Мне объясняли — так выходит, Фил, потому что на старте бизнес и сам не знает, что должно получиться. Индустрия давно отказалась от проектов, которые можно просто взять и сделать. Взять и сделать — это чушь. Надо делать проект вечно, на каждом шаге собирать фидбек, каждый день улучшать. Проект должен как живой организм эволюционировать до тех пор, пока у нас есть деньги.
И когда я первый раз услышал идею вечной разработки, я поверил. Звучит действительно разумно — бизнес требования растут и меняются, мы будем итеративно улучшаться, а кодовая база станет детальной спецификацией всех процессов, которые описывает. Современное ПО слишком сложное, чтобы спроектировать и разработать что-то законченное.
Я люблю поработать в одиночку и быстро что-то собрать. Но я не разуверился и в идее вечной разработки. Она правильная — для проектов, масштаба Windows или Chromium. При разработке калькулятора, эта идея — чушь собачья. А если посмотреть на рынок вакансий, походить по собесам, то можно увидеть, что большая часть индустрии в РФ делает скорее калькуляторы, чем Windows.
Калькуляторы, но с Scrum/Agile, CI, CD, целым выводком продактов, гигантской кодовой базой, и сложным, кастомным дизайном. У меня есть теория, что так получается, потому что все хотят поиграть во взрослую разработку.
Я могу зафигачить целое приложение за месяц. Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок. Но когда я начинаю делать пет-проект, мне сразу хочется все обсерьезить. Мы с пацанами создаем жиру, рубим все на спринты, заводим тикеты, настраиваем CI. Потому что со всеми этими церемониальными вещами пет-проект становится чем-то очень настоящим.
Это иллюзия, в которую мы играем, потому что на самом деле мы и не хотим делать пет-проект. Мы хотим играть в стартапщиков. И мне кажется, что маленький и средний IT бизнес в РФ — из той же серии. Причем эта гадская система сама себя поддерживает. Вот изобрел ты интернет-магазин. Сделали концепт, бизнес пошёл, ты выпросил у инвесторов миллион долларов, и нанял большую команду. Они за пару лет напечатали тебе 300 тысяч строк кода, и система неплохо работает. Ты смотришь на эти тысячи строк, и думаешь — ну раз мы их написали, и вроде бы отсюда ничего и не выкинуть, значит такая система и должна иметь такую большую кодовую базу.
Ошибка выжившего. Интернет-магазин можно вообще просто взять готовый — скорее всего, мужик, уникальность твоего бизнеса не заключалась в каких-то специфичных программных фичах. Или заключалась, но таких фич было две штуки — и ради вот этого мы написали с нуля систему, одновременно с тысячей других компаний, которые за это время написали тысячу точно таких же систем с нуля в мире, где такие системы давным давно были построены.
У каждого проекта есть точка невозврата — момент, когда ответ на вопрос «а не полную ли хрень мы делаем» уже не имеет значения, потому что даже если и полную — делать с нуля уже не получится. Потому что пользователи привыкли именно вот к такому куску говна, который мы для них сделали, со всеми его багами и неочевидными поведениями — в этом и есть его уникальность, которую быстро и легко воспроизвести не получится.
Бизнес хочет поиграть в крутую разработку, а разрабы и не против. Что вам нужно? Усложнить до невероятности немыслимо простые вещи? Ох, братан, мы ещё как хороши в этом. Усложнение — наше второе имя. Святой Усложнитель — наш великий идол, и сейчас ты у нас получишь столько сложности, что тебе придется потратить полмульта зеленых только на сервер, на который мы сложим документацию этой сложности.
Мы создадим DevOps отдел, несколько отделов тестирования, мы возьмем самый энтерпрайзный из всех стеков. Наша кодовая база будет детально задокументирована, мы строго соблюдем все принципы, которые изобрели для гигантских приложений. Тесты — мы напишем невообразимое количество тестов на любой вкус и цвет, и сделаем все для того, чтобы прогон этих тестов шел как можно дольше. Пусть билд крутиться 6 часов — у меня как раз много важных дел дома, но ты должен понимать — мое время стоит дорого. А платить ты вздумал не за продукт, а за игру в разработку. И я с тобой поиграю.
Уже потом, через четыре года, тот-кто-за-все-платит придет и скажет: «Проект умер по независящим от команды разработки причинам, ребят, всем спасибо. Можем ли мы как-то использовать написанный код для других продуктов, или выложить отдельные модули в опенсорс, ведь вы говорили, что у нас все компоненты переиспользуемые?»
Нет, братан. Ты оплатил четыре года написания самого бесполезного говна во вселенной. Этот код нигде больше не используешь, и без продукта, который он описывает, ни одна строка тут не имеет никакой ценности. У нас 400к строк мусора, который писался топовыми инженерами с грамотным соблюдением всех стадий хорошо продуманного процесса, потому что ты — идиот.
А мы хорошенько поучились тут, и пойдем в большие компании, где эта сложность действительно нужна. Большое спасибо за опыт и деньги. В следующий раз, когда захочешь что-то поделать, попробуй принять уже наконец простой факт: ты изобрел ларек — вот и строй ларек. Он ведь очень прост, и он зарабатывает деньги — именно то, что ты хочешь. А в индустриальную разработку пусть играют индустриальные гиганты — у них это отбивается.
На правах рекламы
Эпичные серверы — это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Представляем множество тарифных планов, где каждый найдёт нужное ему предложение.
Автор: Philipp Ranzhin