Про выбор инструментов для фронтенд-разработки

| Comments

Так получилось, что за последние пару месяцев мне несколько раз приходилось принимать решение о том, какие фронтенд-инструменты будут использоваться на старте новых проектов. При том, что опыта у меня не так много, было очень интересно послушать мнение людей, более искушённых в этих вопросах. Расстановка сил на тех проектах, где я работаю обычно такая: один фронтенд-разработчик (собственно это я) и три-четыре бэкэндера. Соответственно участие команды в вопросах выбора фрэймворков сводилось обычно к минимуму и просьбе сделать так, чтобы им приходилось как можно реже писать (о Боже!) javascript.

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

Первая мысль касается того, как люди относятся к готовым решениям: библиотекам и фреймворкам. Вечная тема для холиваров: написать своё или взять уже тысячу раз кем-то написанное? Фронтенд-разработчики (и те, кому приходилось когда-либо писать клиент-часть веб-приложения), с которыми я говорила поделились на три категории в зависимости от опыта работы в данной сфере.

Первая – джуниоры (или те, кто обычно занимаются совсем другими тасками). В этом случае разработчик пытается написать код, чтоб он хоть как-то работал, изобретает свои “велосипеды”, они не всегда красивы, и, честно сказать, не всегда работают, но иногда просто не хватает знаний, чтобы понять, как в конкретном случае нужно было написать “правильно”, да и не всегда человек умеет выбрать и быстро “прикрутить” подходящее для своей задачи готовое решение.

Вторая – те, кто имею сколько-то опыта, но ещё не доросли до сеньора в этой сфере. Они начинают оглядываться по сторонам, с удивлением понимают, что больше половины кода, который они так долго и мучительно писали, уже написан, причём гораздо более красиво (у меня на первом году работы, была ситуация, когда я поняла, что реализовала пару стандартных jQuery функций, не знав об их существовании). При этом разработчик, написав несколько своих “велосипедов”, уже начинает понимать, как какие-то вещи устроены изнутри, как их более эффективно использовать. Сразу возникает непреодолимое желание попробовать все самые модные инструменты, в них ведь так много плюшечек, да и все на каждом углу про них говорят.

Ну и третья категория фронтов, с которыми я разговаривала – это сеньоры. Они помучились на первой стадии, скорее всего проходили через вторую и наконец, они пришли к выводу, что проще написать что-то своё по разным причинам. Но теперь имея за плечами определённое количество лет опыта, покопавшись в чужих “велосипедах”, насобирав всё самое лучшее, разработчику проще при минимуме усилий написать именно то, что требуется для конкретной задачи, использовав поминимуму ненужного кода, который очень часто, скрывается в том самом модном фреймворке или библиотеке.

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

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

Если в команде преимущественно люди, которые предпочитают иметь как можно меньше дел с javascript и клиент-частью приложения, а фронтендом занимается один-два человека, не нужно тащить в проекты фреймворки и незнакомые библиотеки. Соответственно главная роль при таком раскладе отдаётся сервер-части. Для клиент-части же весь инструментарий должен свестись ко всем знакомому минимуму (чаще всего это jQuery и набор стандартных плагинов к нему), даже если вам кажется, что какой-то новый и современный инструмент ну просто очень вам необходим для решения вашей задачи. В противном случае вы рискуете попасть в ситуацию, когда куча кода уже написана, а никто кроме вас в нём разобраться не может, да и не хочет. Закончиться это может очень печально.

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

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

Да, возможно, для какого-то сферического проекта в вакууме можно определить идеально подходящий набор инструментов, исходя из целей и задач, и здесь вам бы здорово помогли советы тех фронтенд-разработчиков, которые их уже решали, но от реальности не убежишь: у вас всегда будет команда, с определёнными скилами и возможностями и чаще всего есть заказчик, у которого может быть свой, сугубо индивидуальный (иногда весьма странный) взгляд на вещи. И выбор того, что использовать в разработке всегда будет определяться именно этим.

Comments