Повышаем свою стоимость: конфиги

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

Однако, представим картину: сидит такой крутой, весь из себя, фронтендер. Пишет на JavaScript или TypeScript (кстати, тоже отдельная тема для разговора) с React на пару и в ус не дует. Ведь для быстрой разработки он тупо скачивает create-react-app и даже не пытается вникнуть, как это работает. В этом вся проблема - стоит хоть немного сдвинуться в сторону от готовых конфигов, если возникнет необходимость кастомизации поведения приложения - работа такого программиста сразу встает колом. Ему нужно либо искать того, кто сможет настроить все необходимые инструменты, либо начинать разбираться самому. В обоих случаях теряется драгоценное время, которое можно потратить на сам проект, а не на вспомогательные вещи. Шиза.

Конфигурация

Где там моя любимая Википедия? А, вот же она:

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

Конфигурировать можно вообще все, что в голову взбредет. Автоматизация, отложенный запуск, настройка сервера, домена, веб-сервера, СУБД, IDE, ОС, линтеров и так далее. Да что уж говорить - есть целая область в IT, которая занимается именно что написанием различных скриптов (.bat, .sh, .py, да даже на .js можно накатать скриптик при желании) для автоматизации процессов сборки и деплоя - DevOps. И это я только краем зацепил - DevOps специалисты гораздо больше делают, и без них процесс непрерывной интеграции и быстрой доставки новых версий продукта крайне проблематичен.

Но программисты не обязаны быть DevOps'ами, не так ли? Верно, но нужно понимать, что одно дело заниматься глобальными вещами по типу CI/CD нескольких зависящих друг от друга проектов, а другое - настроить самому себе удобную работу с проектом локально. В конце концов, в первую очередь за сборку продукта ответственность несете вы, так как вы непосредственно с ним работаете.

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

Наши неразлучные друзья: Webpack, Gulp, ESLint

Существует поверье, что Webpack и Gulp взаимозаменяемы. Отчасти, но есть отличия. Как минимум потому, что Webpack - сборщик, а Gulp - планировщик задач, что как бы намекает на разное их применение. Собственно, исходя из того, что вам необходимо сделать, вы выбираете нужный инструмент, а не пытаетесь один, который вам нравится, впихнуть везде, где только можно.

ESLint мы втыкиваем в проект ради проверки нашего кода на стилистические или логические косяки.

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

Взять тот же Webpack. Он умеет билдить наш код, используя свои или подключаемые плагины и загрузчики. Помимо этого, у него есть свой development server. Каждая из этих частей настраивается в конфигурационных файлах. И если вы способны быстро это сделать, это покажет ваш уровень гораздо выше среднего. Просто потому, что вы не тратите время других людей на решение вашей локальной проблемы.

Далее, вебпак билдит весь ваш код в один большой файл. И весит он довольно прилично. Из-за загрузки жирного файла сайт не показывает контент секунд 5. Страшно? Мне да. И что вы будете делать тогда? Эту проблему в любом случае решать вам, так как вы лучше знаете, что происходит в проекте и как оптимизировать размер выходного файла. А оптимизацией вы займетесь как раз в конфигурационном файле.

Если Gulp используется только для сборки проекта, там та же песня. Вы выбираете, какие плагины вам нужны, какие параметры им передать, управляете их поведением. Когда вы знаете инструмент и как он настраивается, вы становитесь королем конфигов. Слава королю!

ESLint, зараза такая, мало того, что вечно указывает вам, что вы косяк на косяке плодите, так еще и настроить себя просит, капризное создание. А у него всяких разных правил - уссаться и не жить. И всяких парсеров, и плагинов, и готовых наборов правил, и вообще рыдать иногда охото от него. Зато он избавит вас от еще более адовой херни - ковыряться в проблемном коде, пытаясь найти, где не там знак препинания воткнут или опечатка в имени функции.

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

Вот вам примеры конфигов инструментов или статьи по их написанию - тыц, тыц и тыц. В последней, кстати, присутствуют еще конфиги babel и пример файла package.json. Об этих вещах я также планирую рассказать в отдельных статьях.

Итого

Уметь в конфиги необязательно, но желательно. Загляните на hh.ru и посмотрите вакансии на фронтедеров. Скорее всего, вы или в основных требованиях, или в качестве плюсов увидите умение настроить webpack, gulp, babel или еще какую-нибудь очередную модную хрень. И это не прихоть работодателя - вы сами должны понимать, что такие навыки повышают вашу производительность. Вы просто настраиваете нужные инструменты под проект и начинаете хреначить, ни на что больше не отвлекаясь. В конце концов, эти инструменты появились нам в помощь, нравится это кому-то или нет.