Как и обещал, сегодня будет день о выборе технологий и инструментов. Давайте начнем с того, когда вообще приходится делать этот выбор и какие могут быть последствия ошибки? (спойлер: скорее всего необратимых последствий не будет).
Начнем с самого ответственного варианта. Пора стартовать новое приложение и так вышло, что у вас есть право голоса. Если вы единственный, кто принимает решение и это у вас в первый раз, то я вам немного сочувствую, но не переживайте, все будет хорошо!
Итак, чем же руководствоваться при выборе фреймворка? Хорошо бы учесть влияние последствий на: пользователей, коллег и бизнес. Часто разработчики думаю про пользователей и коллег (хотя тут чаще про себя любимого),а про бизнес забывают. И это не удивительно, пусть менеджеры думают
С пользователями все понятно: нам нужны технологии, которые помогут реализовать отзывчивый интерфейс и выбить хотя бы 90/100 в Лайтхаусе. Тут нам иногда придется подумать об SSR, и хорошо бы об a11ly. Хотим выходить за пределы одного языка? Сразу учитываем i18n и l10n.
Тут можно продолжать накидывать варианты фич, которые так или иначе влияют на архитектуру приложения: темизация, PWA, выбор поддерживаемых платформ, работа на нестабильном канале, подключение платежных систем, различных способов авторизации, кажется я уже пошел в сторону бекенда
О чем еще стоит подумать? На сколько этот будет долго жить? Если это разовый спецпроект под какое-нибудь событие, то можно даже не подключать линтеры, писать на чистом js (если вам вдруг так удобно), смело пробовать новые подходы и технологии (ну, если сроки позволяют).
Если это потенциальный долгострой, то тут у нас 2 варианта: сделать MVP по схеме выше и после проверки гипотезы все переписать с нуля, или же подойти к вопросу основательно: выбрать типизируемый язык, настроить очень строгие линтеры, работать в CI/CD пайплайне с первого коммита.
Почему так? Ответ довольно очевидный, но стоит его явно дать: в противном случае мы будем плодить техдолг и те самые куски кода, что через полгода с отвращением назовем "легаси" и будем всячески избегать.
С пользователями разобрались, что же важно для команды? Обычно это субъективные предпочтения касаемо языков и фреймворков. Правила для линтера и определенные подходы (с DI или без, например) тоже можно отнести в субъективную историю. Тут самое важное - понять хотелки команды.
Ну и добавить немного диктатуры, потому что демократия хороша для понимании всей картины, но чертовски сложна для принятия решения, можно пару месяцев правила для линтера выбирать. Берете наиболее близкий вам конфиг, модифицируете под 80% ожиданий команды и разбираетесь на ходу.
С пользователями разобрались, команду порадовали, а как теперь учесть интересы бизнеса? Бизнес любит когда быстро, бесплатно и масштабируемо. Как можно влиять на быстро и бесплатно плюс минус понятно, а что такое масштабируемость?
@jsunderhood Пример из опыта: решили писать проект на mithril.js потому что маленький бандл это хорошо. Спустя год выяснилось что бизнес хочет темную тему, a11y, больше компонентов, а наша маленькость бандла им вообще никак не нужна. Мораль: внимательнее изучать бизнес-требования
Уже подоспел хороший комментарий twitter.com/justboriss/sta…
Ребята от бизнеса никогда не смогут вас сразу рассказать о том, что им надо. Почему мы сразу на сказали про темную тему? Так это же само собой разумеется, вон даже macOS из коробки такое умеет!
Но выяснение скрытых желаний бизнеса это вообще отдельная история и задача для опытного тимлида, а в лучшем случае и проджекта, что будет ему помогать. Но есть довольно понятные факторы, которые можно сразу учесть.
Планируется ли наращивать команду? Как активно планируется это делать? Выбор велосипедов или нишевых технологий может заметно влиять на найм, вам придется искать специалистов, которые готовы разбираться в продукте самостоятельно, ведь на SOC нет готовых решений проблем.
Многие кандидаты даже не будут читать вашу вакансию, если там нет заветных слов React, Angular, Vue, Svelte, а рекрутер из агентства не сможет смаппить вашу вакансию на резюме кандидата.
Но может сложиться так, что продукт нишевый, взрывного роста команды не планируется и тогда можно позволить написать свой фреймворк под условный картографический или медтех стартап. Ну или ваш работодатель просто крупный игрок и может себе позволить все что угодно.
Момент о котором не все велосипедостроители задумываются, но про который спрашивают себя опытные кандидаты. А через 1-2-3-5-10 лет я буду нужен на рынке после работы в этой компании? Хорошо если речь только о фреймворке, а если в компании свой диалект JS?
2.У продукта видится потолок по части наращивания функционала? Если потенциал продукта хороший, то вскоре вам понадобится решать проблему тесноты репозитория для 100 разработчиков. А какие веселые деплои бывают, когда все команды пытаются затолкать фичи в прод до конца квартала!
Некоторые продукты подразумевают систему вайтлейблов. Это когда один и тот же ресурс прикидывается отдельными сайтами. Ни разу с таким не работал и не могу предположить как быстро становится известно о подобной концепции, но может в реплаях кто расскажет.
А может бизнес сразу готов выкладывать результаты в опенсорс? Это дает преимущество для всех: разработчикам красивый гитхаб профиль и уважение, а бизнесу экономия на CI.
Самое неочевидное, пожалуй. А вдруг прямо сейчас бизнесу выгоднее купить готовый конструктор и за неделю его допилить? Да, это звучит отвратительно для разработчика, но зато может закрыть сиюминутную потребность и быстро запустить MVP.
Что еще я не упомянул?
Поехали дальше. Случай второй: вам надо выбрать библиотеку для решения абсолютно рутинной задачи: форматирование даты, генерация uid, рисования графика, таблицы, визивиг... Что делать, на что смотреть? Может писать самому?
Для начала надой пойти и спросить коллег, вдруг эта задача решена, а вы не в курсе? Совет выглядит слишком очевидно? Но почему-то этим шагом часто пренебрегают, а потом в проекте появляется 5 разных реализаций одной функции. Решения еще нет? Идем дальше.
Тут нам предстоит искать баланс между весом библиотеки, ее функциональностью и перспективностью (активность авторов на гитхабе, количество пользователей). Ну и еще на плече будет сидеть маленький дьявол и говорить "используй moment, всегда же так делал раньше!"
Функционал библиотеки можно оценить по документации, перспективность по гитхабу и частоте релизов, остался размер. Почему вообще размер библиотеки так важен для нас? ну подумаешь 10Кб или 100Кб. Но только вот на 20-й библиотеке это уже будет 200Кб или 2Мб. А 20 это не предел.
Как замерять размер? Могу порекомендовать вот этот ресурс bundlephobia.com и смотреть на MINIFIED размер, потому что нам библиотеку надо не только скачать, но еще распарсить и выполнить. Если вы поняли, что библиотека тяжеловата, то можете посмотреть на аналоги.
Ничего не подходит? Не бойтесь сделать форк, но перед этим внимательно изучите исходники. Ну или хотя бы попробуйте завести тикет о недостающем функционале, вдруг повезет? Ну и не бойтесь пробовать и перебирать варианты, когда пишите прототип.
И случай 3, когда вам надо выбирать технологии и это может повлиять лично на вас. Вот вышли вы на рынок труда, разослали резюме, прошли по несколько интервью и на руках у вас офферы. И дальше мы пытаемся балансировать между: зп, технологиями, продуктом, командой и локацией
Вот загорелись вы тем, что хотите писать например на Elm? И тут есть несколько вариантов после того, как вы соглашаетесь.
Через полгода интерес пропадает, перегорание, разочарование. Ну ок, можно вернуться в предыдущий стек. (Ну или вообще уйти из программирования)
Интерес сохранился, но текущий проект в компании завершился, а на остальных сплошное легаси. Тут либо депрессия, либо уход из компании.
Через 3 года с вами не продляют контракт, хотя все шло хорошо, а вы релоцировались ради этой работы, например во Флоренцию.
К чему я это все, на самом деле? Если вы хотите выбрать что-то не из мейнстрима, то будьте готовы к потенциальным сложностям, это нормально. Причем не мейнстрим с большой вероятностью может случиться с вами в FAANG, они привыкли сидеть на своих технологиях.
И через пару-тройку лет вы можете ощутить себя джуном на рынке: вокруг незнакомые названия, компании нанимают людей, что пишут код под конкретный фреймворк и пользуются гитом, а вы года 3 как не ребейзили.
В этом нет ничего плохого, просто попробуйте это учитывать при выборе следующего работодателя, взвешивая все за и против. А если бы я жить не мог без написания велосипедов, то я бы побоялся увольнятся в никуда, хотя ладно, я и так боюсь увольняться в никуда.