Чому я користуюсь Vim і раджу спробувати іншим. Розповідь розробника
Почну з головного: я обожнюю Vim. Це, звісно, не така вже й суперновина, якби не кілька уточнень: я переважно .NET-розробник і використовую Vim для роботи з .NET-кодом. Тут може бути два питання: «Як?» і «Навіщо?». І ця стаття відповість більше на останнє і трохи на перше (звісно, якщо аудиторію зацікавить, то можна буде розкрити краще й перше).
Отже, що ми маємо. Дядько, що займається програмуванням за гроші вже близько 20 років, 19 із яких сидів на Windows, робив доповіді та майстер-класи з ReSharper, зараз активно топить за Vim. З якого дива? Щоб відповісти на це, розкажу свою історію: з чого все починалось і куди згодом прийшло. Олди тут? Будете виправляти, якщо щось наплутаю :)
Ілюстрація Аліни Самолюк
Що таке Vim
Це текстовий редактор, що працює у консолі. Його головна стратегія залучення нових користувачів полягає в тому, що після того, як людина потрапляє у Vim (як правило, випадково), вона довго не може з нього вийти. Редактор має доволі архаїчний вигляд, і фраза «я програмую у Vim» нерідко викликає сміх і здивування у розробників. Але «не всьо так адназначна».
Трішки історії
Програмуванням я почав цікавитись на початку дев’яностих, коли воно ще не було модним. Та й навіть комп’ютерів у вільному доступі не було. Першим моїм компом був «Правец 8Д» (вже дорослим я дізнався, що це був болгарський клон Apple II), ігри та програми на нього завантажувались через магнітофонні касети, і він під’єднувався до телевізора. Звісно, він працював у текстовому режимі. Потім з’явилась можливість попрацювати з MS-DOS — там був Turbo Pascal, Norton Commander, де я вперше побачив псевдографіку. Це коли в текстовому режимі зі спеціальних символів малювались вікна з тінню, крапочки та меню. На якомусь етапі в моє життя зайшов маніпулятор типу миша.
Також я читав різні журнали про новинки комп’ютерної науки та техніки й одного разу натрапив на статтю про графічні оболонки. Замість текстового режиму такі оболонки використовували графічний режим, у якому малювали символи та імітували текстовий (навіть курсор блимав). Для мене це було чимось фантастичним, бо я не міг уявити, якою потужною повинна бути система, що може дозволити собі імітувати текстовий режим у графічному. Коли за кілька років я вперше сів за Windows (ще вдалось застати 3.11), я був у захваті. Ну а потім з’явилась «95», і поступово я звик і до неї.
Перше знайомство
У ті часи я програмував на Delphi (той самий Turbo Pascal, але під Windows), потім перейшов на .NET та Visual Studio. Якраз на початку мого шляху у .NET я працював в одній кімнаті з командою, яка робила дивні, як на мене, речі. Вони писали .NET-код у FAR (це файловий менеджер, який копіював зовнішній вигляд текстового Norton Commander) і використовували CVS у консолі. І саме від них я вперше почув про Vim (чи просто Vi — вже не пам’ятаю).
Як це було: один мій «співкамерник» порадив іншому спробувати цей редактор, і той спочатку посміявся типу «та ну його, маячня якась», а потім прийшов у понеділок і сказав, що посидів у вихідні над цим і зрозумів Vim, він прикольний. А я от не зрозумів. Я тоді якраз дізнався про новий продукт від компанії JetBrains — ReSharper. Пізніше мені показали SVN з чудовим TortoiseSVN, де все інтегрувалося одразу у провідник. OMG, що ще було треба?
Саме так я знехтував першим сигналом і на багато років поринув у світ решарпера та GUI-інструментів. Я вирішив, що треба підвищувати ефективність роботи. Опанував ReSharper майже досконало, активно користувався комбінаціями клавіш і тішився зі свого продуктивного «alt-enter driven development» підходу. «Працювати менше, робити більше» стало моїм гаслом. Я зрозумів, що мишка не допомагає у цьому, а лише заважає. Адже треба відірвати руку від клавіатури, намацати мишку, повозити нею, десь клацнути і потім повертати руку назад. Саме в той час я купив собі ноутбук, щоб користуватись тачпадом, і це було справді круто.
Одночасно з тим, як я підвищував свою швидкість як програміста, почав помічати проблеми інструментів. ReSharper відчутно пригальмовував і не встигав за моєю думкою. Це було неприємно, тому що без нього я вже не міг працювати. Я добряче на нього підсів і почав замислюватись, чи це справді так добре. Коли у своїй кар’єрі я дійшов до написання Front-end, то усвідомив, що став буквально рабом інструменту. Звісно, я почав писати у Visual Studio, і там ReSharper навіть якось намагався допомогти, але його можливості були настільки обмежені, що написання JS-коду було справжньою мукою. Водночас офіційний туторіал з Angular передбачав використання консольних команд, і працювати з ними було одне задоволення. «Хм, а консоль має право на життя», — подумав я тоді.
До того я вже замислювався над тим, що GUI-інструменти не дають тієї гнучкості, якої хочеться. Наприклад, в них досить обмежені можливості щодо автоматизації. Тоді як консольну команду можна зберегти у файл і викликати скільки завгодно. Я відкрив для себе Git і зрозумів, що найзручніший спосіб його використання — саме через консоль.
Звісно, cmd не можна було назвати зручною. В ті часи активно просувався PowerShell, і я вирішив його опанувати: використовувати для операцій з файлами замість провідника, редагувати реєстр, керувати Windows. Я відкрив для себе ConEmu, Posh-Git і багато іншого. Навіть з Azure намагався працювати через консоль.
Наприкінці нульових матеріалів про bash було набагато більше, ніж про PowerShell. Якщо шукати вирішення проблем з консольними командами, частіше натрапляв на bash-відповіді, які потрібно було адаптувати під PowerShell. З появою Docker та WSL з’явилось відчуття, що краще переходити на bash. Це було не просто, адже філософія PowerShell дуже відрізняється від bash. Якийсь час я жив у двох світах одночасно. Половину задач робив через PowerShell, а половину — у WSL через bash. Це складно і неприкольно.
А як щодо розробки
Що більше я користувався не .NET-технологіями, то більше я усвідомлював, що IDE не обов’язкові. У вас є можливість запустити консольну команду, яка перекомпілює код, щойно в ньому з’являться зміни (ng serve для Angular). Звісно, був варіант переходу на IDE від JetBrains: у них однакові інтерфейси й можна не змінювати звички. Проте є дві проблеми. Перша — це той самий vendor lock. Якщо ви захочете спробувати мову, для якої немає IDE, будете страждати. А друга проблема — це недосконалість GUI-інструментів. Вони завжди будуть підтримувати лише обмежену підмножину доступних програм. Щоб якийсь новий чи оновлений інструмент став доступний, треба дочекатись, аби його підтримку хтось додав.
І ще одна біда — IDE змушує вивчити свій унікальний спосіб взаємодії з програмою. Наприклад, для роботи із залежностями npm там буде свій UI. І якщо ви зіткнетеся з проблемами, то можна буде швидко нагуглити рішення для консолі, а на пошук того, як це розв’язати у WebStorm, знадобиться більше часу. Тому я для себе відкрив чудову комбінацію: VS Code + консоль. В першій я писав код, а в другій робив все інше: білд, залежності, тести тощо.
У той час я сидів на Docker і Kubernetes. Я вже змирився, що основний двіж йде у Linux, що навіть .NET Core треба запускати на ньому. У Windows була вбудована Linux (WSL), я нею активно користувався і... страждав. Постійно вилазили якісь проблеми, а їхні рішення, що гуглились для Linux/MacOS, нерідко потребували допрацювання напилком. Там треба якісь дозволи дати, тут поміняти CRLF на LF, ще щось доробити. Не все працювало із WSL: та сама VS Code запускалась на Windows. І там треба було теж підтримувати набір інструментів. Завжди потрібно було пам’ятати, звідки що запускати (Docker — з Windows, Curl — з WSL тощо). Дві HOME папки, різні менеджери пакетів (Chocolatey для Windows, apt-get для WSL), різний набір команд (PowerShell vs bash).
Це все потрохи накопичувалось, і я раптом усвідомив, що Windows мені насправді не потрібна. Від OS мені треба лише консоль та VS Code (ну і браузер, щоб гуглити рішення на Stack Overflow), майже вся моя робота відбувається у WSL, то, може, спробувати перейти з Windows на щось більш природне для такого сетапу?
І так торік я перейшов на MacBook. І це було одне з найкрутіших рішень у моєму професійному житті. Всі проблеми зникли, натомість лишилась одна — відсутність фізичної клавіші esc, хоча я швидко до цього звик. А оскільки проблеми зникли, то я подумав, а чи не прибрати останній GUI-інструмент, а саме VS Code? Адже я використовував його лише як текстовий редактор і разом з терміналом. А що як працювати лише в терміналі?
Саме тут вдруге з’являється Vim. Коли я вирішив знову його розглянути, я тільки вмів з нього виходити. Це, звісно, неабияке досягнення (можете подивитись кількість лайків на питання і відповідь на Stack Overflow), проте я все ж не розумів, як Vim може бути зручним. Так, там є команди, вони задаються комбінаціями клавіш, але як їх всіх запам’ятати? Хіба може нормальна людина, а тим паче після Windows і мишки, запам’ятати, що комбінація bveP копіює слово (тобто double click мишкою, стрілка вправо,
Я загуглив, як користуватись Vim, і натрапив на пост про Vim language. Виявляється, команди не треба запам’ятовувати, натомість варто зрозуміти мову взаємодії з Vim. Якщо коротко, то є дієслова (додати, замінити, видалити), модифікатори (всередині, навколо) і об’єкти (слова, рядки, параграфи). І ваш діалог з редактором більше схожий на розмову: наприклад, «заміни три слова якимось текстом буде c3w, тобто change 3 words». Логічно і зрозуміло. Головна фішка полягає в тому, що для редагування тексту ви використовуєте ті самі рухи пальцями, що і для його написання. І в тому, і в іншому випадку ви друкуєте — або команди, або текст.
Наступним моїм відкриттям був Vimtutor. Ця штука навчає роботи з Vim у самому Vim. Ти пишеш у консолі Vimtutor, відкривається Vim з описом різних можливостей та завданнями, якими можна швиденько засвоїти матеріал на практиці. Кілька разів пройшов Vimtutor — і можеш нормально користуватись редактором!
Далі я почав читати різні блоги й дивитись ролики на ютубі. Знайшов багато матеріалу на будь-який смак. Безліч юзер-груп публікують свої відоси, де люди діляться досвідом і розповідають про різні підходи та плагіни. Усі питання швидко гугляться.
Для Vim є багато різних плагінів, які додають нові можливості, проте не завжди вони такі й нові. У стандартній конфігурації Vim напрочуд функціональний. І перед тим, як ознайомитись з плагінами, адепти рекомендують попрацювати без них, аби зрозуміти, що він насправді може. Ось непоганий туторіал для людей, які люблять засвоювати нові поняття методично. Також можна погуглити відео Vim without plugins. Я міг би, звісно, розказати про плагіни, які використовую, проте це потягне на окрему статтю (і таких статей можна нагуглити багато). До того ж я не вважаю свій набір плагінів чимось досконалим: я періодично щось змінюю і маю надію, що цей матеріал проживе довше, ніж мій поточний конфіг Vim.
За доволі короткий час я почав комфортно почуватися у цьому редакторі й використовувати його для майже всіх своїх справ. Навіть для роботи з .NET-кодом він чудово підходить. Якщо його опанувати, можна бути більш продуктивним, ніж з IDE. Там є можливість налаштування auto completion, quick actions та інших речей, притаманних лише IDE. Це, звісно, холіварна тема, кожний кодить, як хоче, я кажу за себе. Формально для редагування тексту Vim потребує меншу кількість натискань на клавіші, отже, треба менше часу. Також йому треба менше ресурсів, щоб відрендерити код. Він не просто швидкий — він блискавичний (звісно, якщо не зловживати плагінами). Що швидше ти друкуєш, то швидше працюєш з редактором.
Виявилось, що команди Vim використовуються і в інших місцях. Наприклад, у zsh консолі є vi mode — коли можна редагувати набрані команди нею. Чимало Linux-утиліт використовують
Ось така історія. Пишіть у коменти свої питання або розкажіть, чому це все неправильно :)
Щоби не пропустити нові статті Сергія Калінця — підписуйтеся на нього у телеграм-боті Стрічки DOU.
