IDE против Vim для разработки

Kate · 2 Ноя 2021

Начало

Итак есть проект к работе над которым нужно подключиться. Есть репозиторий в котором ведется работа над проектом и дамп базы данных. Какие действия требуются для начала работы? В шторме создается проект сразу из репозитория и автоматически загружается в рабочий каталог. Остается только добавить локальную базу данных, импортировать дамп, подтянуть зависимости и настроить подключение к локальному Xdebug. Все это делается встроенными в IDE средствами. Единственная сложность с которой придется столкнуться - нам придется удерживать повышенный контроль над ходом мыслей во время перекладывания руки с клавиатуры на мышь/тачпад, ведь по заверениям пользователей vim мысль резко обрывается, стоит только оторвать руки от клавиатуры.

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

Первая задача

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

Если в процессе работы мы встретим в legacy-код, то для начала его надо хоть как-то бы привести в читаемый вид. В IDE придется исполнить аккорд на клавиатуре Alt+Shit+L, однако в этом вопросе vim отличается только аккордом. Точнее у него их несколько.

В IDE, благодаря умному анализу кода, ничего особенного не предпринимая, мы сразу увидим какие переменные не используются, какие циклы окажутся вечными, какие условия никогда не изменятся, а значит мы увидим большинство проблемных мест, просто открыв файл. Vim же предлагает нам внимательно вникать в каждую строчку и и выискивать все самостоятельно, проявляя весь свой талант разработчика. Сколько уйдет на это времени и насколько сильно утомится разработчик от такой работы сказать сложно. Видимо именно из-за этого перенос рук с клавиатуры на мышь сбивает vim-овцев c мысли.

Что мы имеем? Мы еще не написали ни одной строчки кода, а разработчик, использующий vim уже потратил ощутимое количество своего ресурса.

Следующим шагом логично посмотреть в дебагере как ведет себя приложение, какие данные откуда и куда ходят, какие значения пишутся в переменные и как они используются. Расставляем брекпоинты (в шторме это тоже можно делать с клавиатуры) и нажимаем Shift+F9. Перед нами откроется полная картина происходящего. IDE выведет все значения переменных не только в окне дебагера, но и наложит их на редактор кода. Можно будет отследить все подключаемые файлы и цепочки вызовов. Сможет ли сделать это vim? Пускай знатоки подскажут в комментариях.

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

А если что-то пошло не так? Сможет ли пользователь vim откатиться по локальной истории и вернуть все взад? Или предлагаете коммитить построчно?

А что если мы разрабатываем интерфейс API и нам нужно покидать на него запросы и посмотреть какие приходят ответы? Без проблем - в IDE есть встроенный HTTP-клиент и мы можем баловаться с запросами так, как захотим, а что предлагает нам vim-комьюнити? Использовать штатный консольный клиент операционной системы? Но для этого мы вновь вынуждены покинуть рабочее окружение. И пока ведется разработка, мы так и будем скакать из одного окружения в другое.

Что дальше?

А дальше будут другие задачи. И знаете что? Их тоже можно подключить в свою IDE. PhpStorm из коробки умеет подключаться к таким сервисам, как Jira, Trello, YouTrack, Redmine, Bugzilla, Git, Asana и другим. Вы даже можете отслеживать время затраченное на решение задач. Здесь vim уверенно проигрывает, потому что не рассчитан на командную работу.

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

Почему vim?

Vim производительный и может легко открыть файл в несколько гигов.

Да, это правда. А еще правда то, что разработчику не нужно открываться многогиговые файлы. Единственное для чего может пригодиться эта возможность - просмотр логов. Но зачем, когда всю необходимую информацию можно получить в отладчике?

Владея десяти-пальцевым методом вы получаете прибавку в скорости.

Да, но причем здесь vim? Или тот факт что управляется он только с клавиатуры как-то ускорит вам процесс рефакторинга? Современная разработка это по большей части чтение и анализ кода. Владея слепым методом методом вы просто будете писать быстрее и в vim, и в IDE. А учитывая то, что непосредственно на набор текста уходит меньше всего времени разработчика суммарно вы ничего не выигрываете. А для тех у кого руки приклеены к клавиатуре есть бесчисленное множество шорт-комбинаций и в IDE. Если хотите, можете даже vim-плагин поставить в IDE и радоваться. Для чего нужно отказываться от остальных возможностей IDE, мне не понятно.

Весь функционал vim направлен на то, чтобы пользоваться им без использования мыши. Отсюда многообразие команд. А из многообразия следует их изощренность, которая таковая лишь на первый взгляд.

Отнюдь. Nano тоже работает без мыши. Я, помню, даже DOS-среда разработки Turbo Pascal позволяла комфортно работать без мыши. Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало.

Со своим конфигом от vim можно прийти куда угодно и сразу же получить свою сборку.

Для этих же целей служат файлы .idea

Если чего-то нет в vim, то всегда можно написать самому.

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

Вместо заключения

В заключение расскажу одну притчу, которую придумал сам. Жили-были два мужика. Иван, да Матвей. И каждый год они вспахивали поля плугом, а осенью собирали с полей урожай. И чтобы урожай был хорошим - каждый из них как мог усовершенствовал свой плуг. Добавляли в него новые фичи, улучшали эргономику. Иван даже стул к нему приделал на колесиках, чтобы пахать сидя можно было. Но в какой-то момент их пути разошлись. Матвей купил себе трактор и стал собирать урожая кратно больше чем Иван. А Иван обозлился на Матвея и каждый раз проходя мимо трактора Матвея плевал в него, недовольно бормоча про то, что лучше плуга ничего нет и все эти тракторы жутко неудобны и громоздки, да и заправлять их все время надо и запчасти покупать. И как не пытался Матвей убедить Ивана купить себе трактор, но ничего у него не вышло.