Очень давно хотел написать что-нибудь полезное, но не знал, чем можно поделится, и тут наткнулся на очередную статью про рассуждения, что же все-таки лучше — vim, emacs или IDE? Сначала я хотел написать сравнение IDE и vim, но слишком мало пользовался IDE и боюсь быть необъективным. Поэтому просто опишу причины, по которым использую vim. Просто чтобы показать, что редакторы занимают свою нишу. Также попробую рассказать о проблемах, с которыми я столкнулся, используя vim, и как я их решал.
Я поклонник *nix-like систем и слышал, что в каждой такой системе по умолчанию всегда есть vi (хотя, бывает, что не всегда). И однажды мне нужно было написать программу на си для известного linux-дистрибутива, вопрос про использованию IDE не стоял — я просто открыл vi и частенько открывая шпаргалку начал писать код. Сразу замечу, что тогда пользовался vim как обычным редактором и не пользовался всей силой командного режима.
То было прекрасное время студенчества, теперь я инженер. Так сложилось, что технологический стек выбирать не приходилось и писать я стал на php. Всем прекрасно известно, что одной из лучших IDE для php является PHPStorm, хотя есть еще много других, в том числе и бесплатных. Однако все мои коллеги как один рекомендовали мне PHPStorm и я не стал пропускать мимо ушей советы более опытных разработчиков. Эта IDE действительно хороша, в ней есть все, что нужно web-разработчику, но была проблема: IDE очень медленно работала.
Скорость работы никуда не годилась. В моем распоряжении был ноутбук с intel core 2 duo (2 ядра по 2.4 Ghz, если я правильно помню) 3 GB RAM и HDD. Денег на новое железо нет, зарплата у junior'а не высокая и кредиты брать не хочется, да и вряд ли дадут.
Проект состоял из ~1,5 GB исходников, БД на Oracle и использовал некоторые специфичные библиотеки. А так же имел очень большие ресурсные файлы (XML), которые приходилось править руками.
PHPStorm ужасно лагал, он долго запускался, долго производил поиск, даже повисал когда я просто редактировал текст, больше XML он просто не мог открыть.
Первое что стоит сказать о vim, что без написания конфига и дополнительных плагинов программировать в нем нормально нельзя. Но если все настроить, то жить можно. И второе, vim — это не IDE и делать из него IDE не стоит. Даже если прикрутить сотню плагинов, то он не будет таким же как PHPStorm или <твоя IDE могла быть здесь>.
Но разработка — это не только редактирование кода, это анализ, рефакторинг, отладка, перемещение по файлам и прочее.
Эту проблему я решил плагином (NERDTree), в нем можно видеть дерево файлов, производить манипуляции над ними и прочее, но так же в vim есть и встроенный файловый менеджер.
Статический анализ кода и отображение его результатов в редактор оказалось тоже простой задачей, так же решаемой плагином, причем для любого известного мне ЯП.
Для поиска по файлам я использую vimgrep или ack, может быть это не так эффективно, как в IDE, но даже в огромном проекте работают довольно шустро. Поиск самих файлов и их открытие на редактирование так же можно делать связкой команд find или grep + vim или прямо в vim через плагин (например, ctrlp).
С отладчиком мне подружить vim так и не удалось. Вернее есть плагин для связи с xdebug, но пользоваться им не очень удобно, однако ценность этого инструмента у меня сводилась к минимуму, callstack и так посмотреть можно, а остальное дело техники. Сейчас я уже не пишу на php и в качестве отладчиков использую консольные инструменты (аналоги gdb) и их хватает.
Инспекция кода вещь не такая нужная как может казаться, у меня есть плагин (tagbar), но я крайне редко его использую.
Нормальное перемещение к определение работает только с си и его производными, для php, ruby, python и т.д. у меня не получилось настроить, но я очень быстро привык использовать ack и vimgrep.
Для автокомплита есть столько плагинов, что все не перепробуешь, но со временем я для себя решил, что это не такая полезная вещь. Тут стоит отметить, что для некоторых это очень важно, т.к. используются очень длинные названия методов, классов (привет, java) но при желании более менее адекватный автокомпит настроить можно.
Включение поддержки нового языка обычно решается подключением соответствующего плагина, к примеру, для golang достаточно подключить один плагин, который умеет все (от подсветки до статического анализа и автоформатирования).
Vim хорошо работает с большими файлами из коробки, но для гигантских файлов тоже есть плагин (LargeFile), при его использовании можно даже гигабайтные файлы открывать и ничего не зависнет.
Автоформатирование кода есть из коробки и оно автоматические подцепляет настройки из плагинов для разных языков.
Я использую git и делаю я это в bash, но для кое-каких операций поставил пару плагинов (vim-fugitive, nerdtree-git-plugin).
Самая важная особенность vim это режимы. Их много, но самый главный — это normal, или командный режим. После какого-то времени, пусть и продолжительного (2-3 месяца) я практически полностью редактирую код в командном режиме. Конечно, перехожу в режим вставки, когда надо что-то написать, но в остальном я использую команды. Это позволяет не отрывать руки от клавиатуры и через какое-то время ты перестаешь думать о том, как тебе редактировать код и полностью можешь сосредоточится на том, какие изменения требуется внести. Пожалуй, самый удачный пример — это рояль, когда ты научишься на нем играть, ты начинаешь думать только о музыке, а не о том, на какие клавиши жать. И я точно могу сказать, что горячие клавиши не дадут такой результат (очень долго пытался — не получилось).
В тех условиях, в которых я работал, со слабым железом и огромным проектом, пользоваться IDE было мукой, но связка стандартных *nix-инструментов и vim позволила решать все задачи, которые вставали передо мной. Сейчас я так же работаю в vim, но уже из-за того, что не хочу переучиваться и менять привычную среду, которая себя хорошо показала. С течением времени я работаю все более и более эффективно, т.к. vim и *nix-системы — это вещи, которые можно изучать очень долго и постоянно находить новые методы решения тех или иных проблем.
И если вам не хочется использовать IDE или нет денег на крутую платную версию, я рекомендую вам попробовать поработать в редакторах, таких как vim и emacs. Если вы поймете их идеологию и она окажется вам близка, то вы не будете испытывать никаких проблем с работой над кодом.
Но надо сказать, что это все актуально для меня как для backend-разработчика, возможно, для разработки GUI-приложений или frontend, редактором ограничится не получится.
Как я встретил Vim
Я поклонник *nix-like систем и слышал, что в каждой такой системе по умолчанию всегда есть vi (хотя, бывает, что не всегда). И однажды мне нужно было написать программу на си для известного linux-дистрибутива, вопрос про использованию IDE не стоял — я просто открыл vi и частенько открывая шпаргалку начал писать код. Сразу замечу, что тогда пользовался vim как обычным редактором и не пользовался всей силой командного режима.
Время мелких программ прошло, теперь все по серьёзному
То было прекрасное время студенчества, теперь я инженер. Так сложилось, что технологический стек выбирать не приходилось и писать я стал на php. Всем прекрасно известно, что одной из лучших IDE для php является PHPStorm, хотя есть еще много других, в том числе и бесплатных. Однако все мои коллеги как один рекомендовали мне PHPStorm и я не стал пропускать мимо ушей советы более опытных разработчиков. Эта IDE действительно хороша, в ней есть все, что нужно web-разработчику, но была проблема: IDE очень медленно работала.
Скорость работы никуда не годилась. В моем распоряжении был ноутбук с intel core 2 duo (2 ядра по 2.4 Ghz, если я правильно помню) 3 GB RAM и HDD. Денег на новое железо нет, зарплата у junior'а не высокая и кредиты брать не хочется, да и вряд ли дадут.
Проект состоял из ~1,5 GB исходников, БД на Oracle и использовал некоторые специфичные библиотеки. А так же имел очень большие ресурсные файлы (XML), которые приходилось править руками.
PHPStorm ужасно лагал, он долго запускался, долго производил поиск, даже повисал когда я просто редактировал текст, больше XML он просто не мог открыть.
И снова Vim
Первое что стоит сказать о vim, что без написания конфига и дополнительных плагинов программировать в нем нормально нельзя. Но если все настроить, то жить можно. И второе, vim — это не IDE и делать из него IDE не стоит. Даже если прикрутить сотню плагинов, то он не будет таким же как PHPStorm или <твоя IDE могла быть здесь>.
Редактор для редактирования, но...
Но разработка — это не только редактирование кода, это анализ, рефакторинг, отладка, перемещение по файлам и прочее.
Итак, проблемы
Мне хотелось видеть файлы проекта в виде древовидной структуры
Эту проблему я решил плагином (NERDTree), в нем можно видеть дерево файлов, производить манипуляции над ними и прочее, но так же в vim есть и встроенный файловый менеджер.
Понимать, что я допустил синтаксическую ошибку в ходе редактирования
Статический анализ кода и отображение его результатов в редактор оказалось тоже простой задачей, так же решаемой плагином, причем для любого известного мне ЯП.
Иметь быстрый поиск файлов и иметь быстрый поиск по файлам
Для поиска по файлам я использую vimgrep или ack, может быть это не так эффективно, как в IDE, но даже в огромном проекте работают довольно шустро. Поиск самих файлов и их открытие на редактирование так же можно делать связкой команд find или grep + vim или прямо в vim через плагин (например, ctrlp).
Запускать отладчик из редактора
С отладчиком мне подружить vim так и не удалось. Вернее есть плагин для связи с xdebug, но пользоваться им не очень удобно, однако ценность этого инструмента у меня сводилась к минимуму, callstack и так посмотреть можно, а остальное дело техники. Сейчас я уже не пишу на php и в качестве отладчиков использую консольные инструменты (аналоги gdb) и их хватает.
Иметь инструмент инспекции кода
Инспекция кода вещь не такая нужная как может казаться, у меня есть плагин (tagbar), но я крайне редко его использую.
Перемещаться к определению метода или класса
Нормальное перемещение к определение работает только с си и его производными, для php, ruby, python и т.д. у меня не получилось настроить, но я очень быстро привык использовать ack и vimgrep.
Иметь автокомплит привязанный к проекту
Для автокомплита есть столько плагинов, что все не перепробуешь, но со временем я для себя решил, что это не такая полезная вещь. Тут стоит отметить, что для некоторых это очень важно, т.к. используются очень длинные названия методов, классов (привет, java) но при желании более менее адекватный автокомпит настроить можно.
Поддержка нескольких языков
Включение поддержки нового языка обычно решается подключением соответствующего плагина, к примеру, для golang достаточно подключить один плагин, который умеет все (от подсветки до статического анализа и автоформатирования).
Работа с очень большими файлами
Vim хорошо работает с большими файлами из коробки, но для гигантских файлов тоже есть плагин (LargeFile), при его использовании можно даже гигабайтные файлы открывать и ничего не зависнет.
Автоформатирование кода
Автоформатирование кода есть из коробки и оно автоматические подцепляет настройки из плагинов для разных языков.
Интеграция систем контроля версий
Я использую git и делаю я это в bash, но для кое-каких операций поставил пару плагинов (vim-fugitive, nerdtree-git-plugin).
Редактирование как оно есть
Самая важная особенность vim это режимы. Их много, но самый главный — это normal, или командный режим. После какого-то времени, пусть и продолжительного (2-3 месяца) я практически полностью редактирую код в командном режиме. Конечно, перехожу в режим вставки, когда надо что-то написать, но в остальном я использую команды. Это позволяет не отрывать руки от клавиатуры и через какое-то время ты перестаешь думать о том, как тебе редактировать код и полностью можешь сосредоточится на том, какие изменения требуется внести. Пожалуй, самый удачный пример — это рояль, когда ты научишься на нем играть, ты начинаешь думать только о музыке, а не о том, на какие клавиши жать. И я точно могу сказать, что горячие клавиши не дадут такой результат (очень долго пытался — не получилось).
Подводя итог
В тех условиях, в которых я работал, со слабым железом и огромным проектом, пользоваться IDE было мукой, но связка стандартных *nix-инструментов и vim позволила решать все задачи, которые вставали передо мной. Сейчас я так же работаю в vim, но уже из-за того, что не хочу переучиваться и менять привычную среду, которая себя хорошо показала. С течением времени я работаю все более и более эффективно, т.к. vim и *nix-системы — это вещи, которые можно изучать очень долго и постоянно находить новые методы решения тех или иных проблем.
И если вам не хочется использовать IDE или нет денег на крутую платную версию, я рекомендую вам попробовать поработать в редакторах, таких как vim и emacs. Если вы поймете их идеологию и она окажется вам близка, то вы не будете испытывать никаких проблем с работой над кодом.
Но надо сказать, что это все актуально для меня как для backend-разработчика, возможно, для разработки GUI-приложений или frontend, редактором ограничится не получится.
