Vim як не IDE

Дуже давно хотів написати що-небудь корисне, але не знав, чим можна поділитися, і тут натрапив на чергову статтю про міркування, що ж все-таки краще - vim, emacs або IDE? Спочатку я хотів написати порівняння IDE і vim, але занадто мало користувався IDE і боюся бути необ'єктивним. Тому просто опишу причини, через які використовую vim. Просто щоб показати, що редактори займають свою нішу. Також спробую розповісти про проблеми, з якими я зіткнувся, використовуючи vim, і як я їх вирішував.

Як я зустрів Vim

Я шанувальник * nix-like систем і чув, що в кожній такій системі за замовчуванням завжди є vi (хоча, буває, що не завжди). І одного разу мені потрібно було написати програму на сі для відомого linux-дистрибутива, питання про використання IDE не стояло - я просто відкрив vi і частенько відкриваючи шпаргалку почав писати код. Відразу зауважу, що тоді користувався vim як звичайним редактором і не користувався всією силою командного режиму.

Час дрібних програм минув, тепер все по серйозному

То був чудовий час студентства, тепер я інженер. Так склалося, що технологічний стек вибирати не доводилося і писати я став на php. Всім прекрасно відомо, що однією з кращих IDE для PHPStorm, хоча є ще багато інших, в тому числі і безкоштовних. Однак всі мої колеги як один рекомендували мені PHPStorm і я не став пропускати повз вуха поради більш досвідчених розробників. Ця IDE дійсно хороша, в ній є все, що потрібно web-розробнику, але була проблема: IDE дуже повільно працювала.

Швидкість роботи нікуди не годилася. У моєму розпорядженні був ноутбук з intel core 2 duo (2 ядра по 2.4 Ghz, якщо я правильно пам'ятаю) 3 GB RAM і HDD. Грошей на нове залізо немає, зарплата у junior'a не висока і кредити брати не хочеться, та й навряд чи дадуть.

Проект складався з ауд 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 добре працює з великими файлами з коробки, але для гігантських файлів теж є плагін (Lar^ File), при його використанні можна навіть гігабайтні файли відкривати і нічого не зависне.

Автоматичне форматування коду

Автоформатування коду є з коробки і воно автоматичні підчіпляє налаштування з плагінів для різних мов.

Інтеграція системи контролю версій

Я використовую git і роблю я це в bash, але для якихось операцій поставив пару плагінів (vim-fugitive, nerdtree-git-plugin).

Редагування як воно є

Найважливіша особливість vim - це режими. Їх багато, але найголовніший - це normal, або командний режим. Після якогось часу, нехай і тривалого (2-3 місяці) я практично повністю редагую код в командному режимі. Звичайно, переходжу в режим вставки, коли треба щось написати, але в іншому я використовую команди. Це дозволяє не відривати руки від клавіатури і через якийсь час ти перестаєш думати про те, як тобі редагувати код і повністю можеш зосередиться на тому, які зміни потрібно внести. Мабуть, найвдаліший приклад - це рояль, коли ти навчишся на ньому грати, ти починаєш думати тільки про музику, а не про те, на які клавіші жати. І я точно можу сказати, що гарячі клавіші не дадуть такий результат (дуже довго намагався - не вийшло).

Підбиваючи підсумок

У тих умовах, в яких я працював, зі слабким залізом і величезним проектом, користуватися IDE було борошном, але зв'язка стандартних * nix-інструментів і vim дозволила вирішувати всі завдання, які вставали переді мною. Зараз я так само працюю в vim, але вже через те, що не хочу перевчатися і змінювати звичне середовище, яке себе добре показало. З плином часу я працюю все більш і більш ефективно, тому що vim і * nix-системи - це речі, які можна вивчати дуже довго і постійно знаходити нові методи вирішення тих чи інших проблем.

І якщо вам не хочеться використовувати IDE або немає грошей на круту платну версію, я рекомендую вам спробувати попрацювати в редакторах, таких як vim і emacs. Якщо ви зрозумієте їх ідеологію і вона виявиться вам близька, то ви не будете відчувати ніяких проблем з роботою над кодом.

Але треба сказати, що це все актуально для мене як для backend-розробника, можливо, для розробки GUI-додатків або frontend, редактором обмежиться не вийде.