Эта история личное мнение, основанное на наблюдениях, во время работы в разных проектах.
Вход в командную разработку
Во времена моей работы на фрилансе проблем по выбору стека технологий не было, все было просто, я советовался с друзьями, читал различные источники и выбирал нужный стек. Это были популярные вещи, потому что по ним было больше информации, больше готовых проектов, где можно было подсмотреть нужное решение и больше ответов на Stack Overflow, если сталкивался с какой-либо проблемой. Благодаря этому работать было не так уж напряженно.
Но когда я начал работать в команде, выбор стека превратился в загадку. В голове постоянно крутилось: Зачем? Почему? Откуда это взяли? Что за подход? Я не понимал, почему в одной команде одни технологии, в другой другие, хотя все по сути делали одно и тоже.
Так же было очень интересно и не понятно, почему одни люди на проекте с пеной у рта доказывали превосходство выбранного пути, а в другой команде другие делали тоже самое, но по-другому и различные подходы в технологиях, которые я описывал из предыдущей команды попросту высмеивали.
На тот момент я просто плыл по течению и вникал. Мне не когда было заниматься философией, нужно было просто набивать скилы. Поэтому работая на проекте, я полностью проникался идеями технических вдохновителей и принимал их как свои собственные.
Иногда приходило время и приходилось переходить на другие проекты. И опять наступало время великих удивлений, когда вроде бы стандартный, технически одинаковый и устоявшийся современный фронтенд, в новой команде принимал абсолютно извращённый вид под капотом и абсолютно одинаковый на выходе.
Понимание происходящего
Начать наверно нужно с понимания, что истины не существует и каждый волен делать то, что ему захочется, лишь бы это не вредило общему процессу и результату. Учитывая, что на фронте +10 решений для любой проблемы.
Работа начинается с выбора базового стека, какой бы он там ни был, но дальше начинается большой потенциал для различных вариаций. Так же прибавляется уже существующая база написанного кода, ибо многие вещи или если сказать не все, уже написаны и их осталось только адаптировать под свои нужды.
Когда проект вступает в фазу стартапа тут все открыто и прозрачно. Ну понятно, нужно хоть что-то, как-то сделать. А после становления в проект начинают запихиваться дополнительные фичи и подключаться дополнительные модули.
Так же что бы понять происходящее, нужно обратиться к опыту участников проекта. Даже если он выше среднего, то на начальном этапе люди стараются придерживаться каких-то рамок и не особо блистать своим великолепным умом.
На следующей фазе, становится немного по веселее, рамки приличия постепенно стираются и в коде появляются какие-то супер технологичные подходы, паттерны и космические обертки возвращающие монады. И все это называется эффективным архитектурным решением, что по факту является набором диких самописных костылей, которые замыленным взглядом бывалых участников, смотрятся очень даже ничего, и просто вызывают панику и недоумение у новичков пришедших на проект.
А вот основное веселье начинается, когда с проекта уходят первопроходцы, остается один два сторожил и пока остальные, вновь прибывшие привыкают к проекту, не совсем понимая происходящее, у майнтейнеров развязываются руки, включается “Армейский Дед” и начинается процесс внедрения супер технологий, подходов и архитектур.
Здесь становится просто скучно следовать стандартному технологическому флоу. Хочется больше треша, глубоко записанного в код проекта. Все чаще тимлида посещают мысли, что слишком просто писать на JS или легком TS. Нужна строгая типизация, нужен строгий анализатор кода. А то же может прийти новичок на проект и “О Боже!” совершить смертный грех, случайно пробросить в компонент не нужные пропсы, которые в нем быть не должны или вызвать не подходящую функцию. Все чаще он задумывается об ограничениях стандартных модулей, аля React Router. Как же можно пользоваться этим ограничивающим волю не доработанным роутером, который не дает доступ к history не в рамках React. А если спросить: “А где тебе нужен будет доступ к history в твоем spa, не в рамках компонентов React?” Будет ответ что-то вроде, что ты ничего не понимаешь в технологиях, и не можешь думать так же глубоко и на веки вперед.
Отношение руководства
В отношение руководства все проходит гладко. У менеджеров и своих управленческих дел предостаточно, чтобы вникать во всякие технологические изыски. И полагаясь на старшего разработчика, который бьёт себя в грудь, с абсолютной уверенностью и горящими глазами заявляя, что он так уже 100 раз делал, что проект выстрелит в 100 раз быстрее и надёжнее, что наступит мир во всем мире и полная идиллия, дает отмашку на внедрение супер архитектуры. Но их тоже нужно понять, они хотят, как лучше и если будет прирост производительности, почему бы и нет?
Go ahead
Выбор нового стека всегда проходит “на коленке”. Как правило делается беглый обзор, основанный на отзывах и звездочках на gitHub’е. “Wow Rust”, “Wow React-Reason”. Это наш выбор!
Пишется для примера парочка компонентов, которые “супер быстрые”. Ну как же, они же компилятся в прекрасный человек читаемый код и очень производительны. Разработчик бы так не написал красиво, как интерпретатор. А дальше понеслась работа по перепилу всего приложения на новую архитектуру, которая практически всегда заканчивается вилкой приводящей к одному итогу.
1 вариант. После N месяцев разработчики сталкиваются с не разрешимыми проблемами, из-за которых приложение начинает тормозить еще сильнее, чем до переезда.
2 вариант. Процесс написания кода превращается в попытку разобрать современным человеком старинный манускрипт, написанный на мертвом языке, затворными тибетскими монахами и дописать в него нужное предложение.
Итог
В какой-то момент, великий предводитель проекта, ведущий в светлое будущие, модными прорывными технологиями, понимает точку невозврата и проходит со словами: “Мне тут что-то ценник x1,5 предложили, а мне сейчас деньги нужны, ипотека, кредиты и все такое. Ну в общем, не поминайте лихом, я пошел.”
На вопрос удивленного руководства: “А как же супер архитектура?” Он говорит: “Не довелось…”.
И здесь можно сделать ремарку, что человек то он действительно умный и продвинутый и начитанный, что делает его ценным специалистом и любая галера возьмет такого с руками и ногами, даже дороже рынка. Но вот цена этого ума, загубленный проект и команда оставшаяся не в лучшем положении.
И скорее всего такой ошибки он больше не совершит и будет придерживаться стандартного стека при разработке.
А руководство после ухода предводителя зайдет на hh.ru вобьет в поиск “Rust” или “Reason” получает гордый 0. И на радость команды вернется к разработке в свой старый добрый, понятный репозиторий.
Вывод из всей этой истории можно сказать такой, все модные технологии хорошо подходят для расширения кругозора разработчика и для поднятия скилов. Но пока на них не появится больших, сложных, работающих проектов, разработанных мудрыми разработчиками, наверно не стоило бы самостоятельно внедрять всю эту “Моду” в продакшн.
Автор: AndrewKazanin
