Check Levi9 best QA positions to Backbase team!
×Закрыть

Чому я користуюсь 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 мишкою, стрілка вправо, cmd-V)? З іншого боку, ним користується багато людей, навряд чи вони робили б це, якби це було незручним. Тож тут, певно, є якийсь секрет.

Я загуглив, як користуватись 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-утиліт використовують Vim-шорткати для навігації, пошуку тощо. Є розширення для браузерів Vimium, яке дає змогу користуватись навігацією сторінки, пошуком у документі, відкритими вкладками, вікнами тощо через підходи з Vim. Тобто раз помучився, а потім відкриваєш все нові місця, де ці навички можна застосовувати. Це дуже круто.


Ось така історія. Пишіть у коменти свої питання або розкажіть, чому це все неправильно :)

👍НравитсяПонравилось1
В избранноеВ избранном7
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


Лучшие комментарии пропустить

Цитата «Я уже два года пользуюсь Vim, в основном потому, что не знаю, как выйти из него»

Статья классная, но всё равно не понятно как выйти из Vim

124 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
і я раптом усвідомив, що Windows мені насправді не потрібна.

Очікував, що зараз автор розповість, який Linux йому більше до вподоби, а тут — macOS :(

Сергій, впізнаю персонажів з твого першого знайомства з Vim.

Я використовую VSCode і Vim десь 50/50. Кілька років тому переповз у Linux , в якості основної системи, а потім на MacOS (насправді, це змінило тільки те, який термінал використовується). В нас дуже схожий досвід та шлях його набуття, напевно тому я згоден з усіма твоїми аргументами та висновками.

Цікавий досвід. Дякую за статтю. Майже одразу захотілося спробувати. Але є певні побоювання. Що, наприклад робити, якщо є звичка користуватися «важкою артилерією» Resharper. Наприглад: змінити ім’я класа, який вже використовується в декільках десятках файлів. Перенести певний клас/файл в інший директорій та зберегти при цьому відоповідність структури неймспейсів структурі директоріїв? Що, якщо користуєшся, іншими VS Extensions, наприклад AsyncFixer? Чи зручно користуватися паралельно Vim та VS?

Я для С++ користуюся зв’язкою Vim + RTags, який використовує CLang, і, відповідно, знає все про код.

Є функція rtags#RenameSymbolUnderCursor.

Щойно перевірив на одному з базових класів. Працює. В один бік.

git submodule foreach git reset —hard

Треба на свіжу голову дивитися, а не в ліжку.

Тема vim’a не раскрыта
~70% статьи автор вспоминает былые времена и описывает опыт который не очень-то релевантный заголовку статьи, а потом вдруг внезапно немного рассказывает про vim

Якщо його опанувати, можна бути більш продуктивним, ніж з IDE.

тільки у випадку якщо ти кодер, і то — може бути, інколи, якщо, ..., ..., it depends
програміст більш часу витрачає на думки, а не їх кодування.

або не програміст, якому байдуже, не дає нічого корисного що дають IDE

а обвішаний плагінами vim чи emacs — то вважай що IDE. то навіщо відмовлятись від IDE, щоб її зробити в результаті?
корисно коли для мови немає пристойної IDE
чув що хаскелісти у emacs сидять. бо більш нема в чому :)

чув що хаскелісти у emacs сидять. бо більш нема в чому :)

был плагин к идее, насколько я помню вполне рабочий
уж точно проще емакса))

корисно коли для мови немає пристойної IDE

ну вот у меня такая ситуация, пишу на редком языке, пристойной IDE нету, тем не менее, потребности в виме не ощущаю аж никак. Sublime Text с плагинами (в большинстве коллеги юзают VSCode, но мне саблайм больше нравится) плюс консолька. Ну еще SourceTree чисто для просмотра логов.

ZeroBrane не заходить?

(Я в вімі пописую, але зеробрейн нічого так)

ZeroBrane не заходить?

А, так я сейчас не на луа пишу. У нас движок на Ниме.

опа, первый «живой» чел которому хоть как-то можно доверять говорит что используют nim
или не вы писали, а просто используете движок?

Это же «идеальный язык программирования»:
dou.ua/lenta/articles/nim

про идеальный я много где читал
сколько их было уже, идеальных
а выживают почему-то кривые и косые :)

а тут, живые люди используют.
неужели выжил, и не повторил судьбы D например...

GC робить його непридатним для багатьох задач, наскільки я розумію

опа, первый «живой» чел которому хоть как-то можно доверять говорит что используют nim
или не вы писали, а просто используете движок?

За основу взяты оупенсорсные движок и гуи платформа от автора статьи, на которую Сергей сослался ниже

Это же «идеальный язык программирования»:
dou.ua/lenta/articles/nim

https://github.com/yglukhov/rod

https://github.com/yglukhov/nimx

(с автором этого кода и статьи раньше вместе над одним проектом работали, один из евангелистов nim ’а). Затем это все основательно допилено под наши нужды и сейчас имеем живой кроссплатформенный проект с универсальным кодом для всех платформ (андроид, иос, веб плюс мак и винда для разработки).

Я міг би, звісно, розказати про плагіни, які використовую, проте це потягне на окрему статтю (і таких статей можна нагуглити багато). До того ж я не вважаю свій набір плагінів чимось досконалим: я періодично щось змінюю і маю надію, що цей матеріал проживе довше, ніж мій поточний конфіг Vim.

давай шарь свой .vimrc :) или лучше репозиторий dotfiles
P.S. Если шо, мой .vimrc, плагины и dotfiles

Ни разу в жизни не видела разработчика младше 1990 года рождения, который юзает вим.

Ни разу в жизни не видела разработчика младше 1990 года рождения, который юзает вим.

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

В мене працює такий. Правда Emacs, але яка різниця?

Значит, ты ещё не всё в жизни повидала. Многие молодые программисты таки юзают vim.

юзать то можно. главный вопрос — а зачем?

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

Многие молодые программисты

Многие? это сколько в %%? ну так, с потолка, по ощущению.
40%? 30%? 0,000000001%?
и, а на чем пишут эти многие?

юзать то можно. главный вопрос — а зачем?

Затем, что некоторые помешанные на безопасности компании не разрешают юзать ничего больше. И для работы дают очень ограниченные права, которые не позволяют установить что-либо.

и, а на чем пишут эти многие?

Как правило, на Сях и плюсах. Могут на баш-скриптах.

Как-то я работал в подобной конторе. Ну как работал — просидел полтора месяца на испыталке, плюнул и прервал по своей инициативе. Мотивация — зарплата чуть выше, чем по рынку, уходил оттуда я с даунгрейдом.

Затем, что некоторые помешанные на безопасности компании не разрешают юзать ничего больше

понятно, то есть был не сводобный выбор. бывает, согласен.

Как правило, на Сях и плюсах.

знаю, виртуально, одного крутого плюсовика.
да, он на vim давно, не раз рассказывал почему
по цветным скринам отрывков кода, и тому как он пишет, рефакторит, у него там такой обвес, что может и Visual Studio отдыхает

но вот «Многие молодые программисты» тогда требует уточнения,
на С/С++

Согласен с идеями статьи, что консоль и vim увеличивают продуктивность, но как же стыдно читать аргументации вида

Формально для редагування тексту Vim потребує меншу кількість натискань на клавіші, отже, треба менше часу

Вот мое чтобы я посоветовал, тем кто хотел бы улучшить продуктивность за счет внедрения Vim:

  1. Не надо из-за этого отказываться от IDE. Просто ставим Emulate Vim или плагин в IDE которую вы привыкли использовать.
  2. Вы знаете, что косынка была добавлена в Windows, для обучения работы с мышкой? Попробуйте Vim через игровое обучение. vim-adventures На github ест советы по прохождению уровней и docker image, чтобы не покупать доступ.

1. Як у Vim з дебагерами?
2. Чи можна у Vim дізнатися автора по annotate, як в продуктах JetBrains, коли поруч з номером рядка відображається дата коміту та ім’я автора?

2. Чи можна у Vim дізнатися автора по annotate, як в продуктах JetBrains, коли поруч з номером рядка відображається дата коміту та ім’я автора?

git blame?

Це не спортивно, мене цікавить те ж саме, але не виходячи з vim.
P.S. Загуглив, так — все можна. Але це настільки незручно, що ну його нафіг. Дрочь заради дрочі.

Це не спортивно, мене цікавить те ж саме, але не виходячи з vim.

www.google.com/search?q=git blame vim

Є як готові плагіни, так і просто кастомні скріпти в 1 строку.

В інших опенсурсних проектах це теж можливо, я не про emax авжеш.

Колись давно прикручував DDD, і воно таки було прикольне.

Я відкрив для себе Git і зрозумів, що найзручніший спосіб його використання — саме через консоль.

Особенно rebase).

Коли у своїй кар’єрі я дійшов до написання Front-end, то усвідомив, що став буквально рабом інструменту. Звісно, я почав писати у Visual Studio, і там ReSharper навіть якось намагався допомогти, але його можливості були настільки обмежені, що написання JS-коду було справжньою мукою.

Вот он — корень всех проблем))).

Использую VS (без ReSharper — 16я версия уже содержит всё, что мне нужно)/VS Code + TortoiseGit (one love) + bash/PowerShell.

Можна не вибирати між VIM і VisualStudio. Рекомендую vsvim. Користуюся майже кожний день.

Для мене, VIM — це ідеологія сліпого і швидкого набору тексту, а не заміна IDE. Тобто його основна цінність не конкретна реалізація, а підхід до шорткатів і режими-редагування (modes: INSERT,NORMAL,VISUAL etc.) які роблять набір і модифікацію тексту по ефективності близькими до оптимальних.
А те що vim йде під всі платформи і похожі шорткати працюють в less, git, github робить життя легшим.

Також ціль проекту NeoVim — це бібліотека яку можна використовувати і в IDE в тому числі. Тобто це просто дуже ефективний движок для редагування тексту.

Для мене, VIM — це ідеологія сліпого і швидкого набору тексту,

А потом вы становитесь мидлом и «набор текста» занимает процентов 10 от вашей работы.

А потів Ви стаєте СТО і виправляєте баги у Vim на продакшині, поки CEO відволікає клієнта.

А потів Ви стаєте СТО і виправляєте баги у Vim на продакшині, поки CEO відволікає клієнта.

Такое тоже бывает, если в инженерном плане человек не может расти, то можно пойти и в жулики, то есть в стартаперы.

Та я й на галеру пішов, бо жулік...

Відповідь вражає як хамовитостю так і нічим необгрунтованою статистикою.
Судячи по відстутністі софт скілів, мідл це ви )

нічим необгрунтованою статистикою

Вы не согласны, что на обдумывание решений уходит сильно больше времени, чем на непосредственный кодинг руками?

Я думаю, коли йду пити чай-каву )
Якшо серйозно, то є різні області для думання:
1. Архітектура, продумування високорівневої структури кода — це окрема задача. IDE тут, як правило, ні до чого.
2. Похоже і з юзер сторями. Береш сторю, розписуєш сценарії в JIRA чи іншому місці (до речі швидкий набір помагає текст топтати і тут :) ). Це потрібно шоб було зрозуміло як тестувати і що іменно буде підтримуватися в продукті. В ідеалі це робиться через співпрацю BA,QA і Dev. Тобто тут також IDE ні до чого
3. Маючи сценарії, в більшості випадків TDD рулить. Тобто це цикл: Test-Fail->Fix.
І в більшості випадків це просто топтання кода. Час від часу попадаються ситуації коли потрібно розвязати якусь головломку або перерватися на 1,2. Але це точно не 90% часу як описують деакі.
4. Коли TDD не рулить. Це випадки коли є забагато невідомих в задачі. Тому роблять «спайк» і це, як правило, прототип який «щось» вміє. Він зроблений за обмежену кількість потраченого на нього часу і тут справді бувають різні ситуації включно з тільки 10% часу на кодінг. Як часто у бувають спайки ? Це залежить від проекта, його стадії і досвіду девелопера. Статистику тут будувати буде дуже важко.

1-2-3-4 це звичайно дуже спрощений опис розробки, але якшо ви справді тратите 10% часу на кодінг, то це, як правило, значить шо ви або Архітектор або у вас хаос в процесі вашої роботи або взагалі хаос в голові. В останніх двох випадках рекомендую переглянути ваші денні активності і розібратися що не так.

Похоже і з юзер сторями. Береш сторю, розписуєш сценарії

Оно-то да, но только если юз-кейс — простой саппорт/добавление несложных фич. Для плюс-минус сложных фич

продумування високорівневої структури кода

Маст хэв.

Плюс ещё есть пункт 5 и классическое «2 дня дебажил — исправил одну строчку»). Хотя в целом да — может, я немного предвзят, т.к. стараюсь не сидеть на саппорте по возможности и, в принципе, практически не сижу.

простой саппорт/добавление несложных фич

З цього і починаються проблеми. Питання скільки таких невеликих змін зроблених аби-как проект витримає до того як його вирішать переписати.

Питання скільки таких невеликих змін зроблених аби-как

тести не падають — значит все добре!
думати ж не треба, треба код писати та таскі закривати!
бо не треба ж думати під час написання коду

це я ще мовчу про те що
програміст читає та перечитує набагато більше коду ніж пише сам.
і що він витрачає на це читання теж більш часу, у середньмоу, аніж на написання
не думаючи мабуть теж.

тобто
коли пишеш код — не думаєш
а думаєш — коли не пишеш

за рахунок такої економії недумаючи кодери видають на порядкі більш коду, сліпим набором, без хаосу у голові, аніж ті що думають коли пишуть код.

в дійсності що бачив чомусь це явище не спостерігається. але шо я там бачив...

В дійсності, на жаль, більшість людей не структурує свою роботу по різних причинах. З цим згоден, але це не проблема інструментів, а людського фактору.

а людського фактору.

так. якби прибрати з програмування людей
з керування — теж прибрати
а ще прибрати людей як замовників, то світ стане краще навіть чим у будь якої утопії

люди ж все псують, всю красотэнь детермінізму

youtu.be/U-ijUylm64k

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

я теж не думаю
не бачив ще ні разу щоб формалізація хаосу, практики працювали самі по собі
без людей

але що я там бачив.
пишуть на доу що «многие молодые программисты программируют в VIM и пишут код на Go быстрее в 6-8 раз чем на php»

ви ось бачили, як воно працює без людей. довело свою ефективність.
різний досвід, різних світів.

не порозуміємося, так.

Сергій, я десь згадав програмування без людей?
Це ваша ідея фікс.
І я не поділяю ідею автора пересідання на VIM.
Для мене це просто ефективний інструмент для деяких задач і ідея про покращення IDE

Я використовую і Vim, і VS Code, і Eclipse (з JetBrains не складалося — може, Бог милував, бо то кацапи).

В VS Code і Eclipse — розкладка клавіатури від Vim. Щоб кожного разу не згадувати, яка комбінація клавіш для інкрементального пошуку і всього іншого.

В JetBrains насправді в них багато українців працює. Подурачитися про vim у якості IDE як на мене одна з улюблених тролінг тем співробітників (була років 10-12 тому). Ніби був колись один співробітник який у вімі писав код, і від того пішов тролінг холівар.

чув що vi та vim розробляли для терміналів, де кількість кнопок на клавіатурі була обмежена, але ж ті часи давно минули і не розумію я чому повинен відмовлятися від використання спеціально передбачених кнопок типу Home/End/PgUp/PgDwn?

Олег, освойте сліпий набір. Питання відпаде саме собою

я його освоїв у достатньому обсязі, але швидкість набору для мене не є «вузьким місцем» у роботі

І при сліпому наборі вам зручно користуватися PgUp/PgDwn/Home/End?
Стаття і обговорення не про вузькі місця, наскільки я розумію, а іменно про ефективність кодінга. Якшо вважаєте що можете покращити свій професійний рівень в інших напрямках, то потрібно шукати в інших місцях

В наші часи, щоб користуватися кнопками home/end/pageup/pagedown доводиться купувати окрему клавіатуру. Не розумію, як люди взагалі живуть без них. Але я навіть якось звик в VIM користуватися літерами замість «стрілок», нормально, справа звички.

hjkl не працюють в insertmode.

тому потрібно вчитися правильно ними користуватися ))

Як саме? Перемикатись в command mode — не пропонувати.

Як казав один старий та досвічений інженер — «always exit edit mode», що саме по собі досить цікаво навіть з філософської точки зору

можливо vim зручний для тих, хто знає весь проект і де що знаходиться або пише його від початку, але дуже часто потрібно розбиратися з чужим кодом, де сотні і тисячі файлів і на початку взагалі не зрозуміло де і що знаходиться, а документації тупо немає

Я так розумію, питання в навігації по коду. Є багато плагінів на цю тему.
Особисто користуюся neovim + github.com/neoclide/coc.nvim для typescript і rust.
В neovim в наступній версії має з’явитися власна підтримка LSP

знову ж таки, навіщо ставити 100500 кастомних плагінів якщо включив Visual Stidio чи Idea і одразу працюєш.

я так розумію, і visual studio і Idea такі речі також реалізують через плагіни і LSP

Навігація робиться через плагіни.

Для С++ є RTags, який використовує CLang — тобто є вся інформація від компілятора.

Тут може бути два питання: «Як?» і «Навіщо?».

Собственно ответа на вопрос «Зачем?» я так и не увидел.
Или вопрос был не «зачем это может пригодится читателю», а «как конкретный человек пришел к определенному состоянию/решению». Если да, то вопрос «зачем об этом писать?»

System Architect в

Вот тут уже интереснее:
Собственно кодинг для этой должности уже вторичен. Довольно часто, есть много активностей по:
— коммуникации с не техническими людьми. Заморочиться тут конечно можно, но большинство эффективных тулов тут с ГУИ.
— подготовка всяких диаграмм. Тоже не сильная сторона вима.
— подготовка всяких презентаций, документаций для разного рода людей. Далеко не все из них захотят работать с консольными утилитами (и те же АДР могут переехать в конфлюенс)
— ревью и анализ кода, фактически поиск имплементаций, наследников, датафлоу от/до места в коде. Тут так же идея (у вас оно, наверно, называется решарпер) справляется лучше. Не исключено конечно что для дотНет все по другому, но для джавы разница гигантская.

Мне нравится что vim может открывать очень большие файлы без проблем. Интересно как автор дебажит код без IDE. Алертами?

Код дебажиться аналізом логів.

Бо розподілені системи і ріелтайм.

Якщо мається на увазі інтерактиіний дебаг, то gdb/ddd. Неінтерактивний дебаг — через логи та інстументи аналізу (perf, valgrind, etc.)

Пользуйтесь Emacs, а не этим богомерзким «редактором»)

На постійній основі використовую тільки vim(якщо точніше — neovim) вже більше півроку(раніше сидів на Webstorm). Найважче певно перейти — треба витратити декілька тижнів на вивчення і тренування основних комбінацій команд, також ще тиждень може піти на встановлення необхідних плагінів і додавання власних комбінацій. З плюшок — менше від’їдає ресурсів, швидко стартує, трішки швидше і веселіше кодиться :)

Приклади фіч, які вдалось завести:

  • Підсвітка коду(JS, TypeScript), лінтер
  • Автодоповнення
  • Файловий провідник
  • Сесії
  • Гітові штуки
  • Пошук по назві файла/по слову

так в штормі це все є. в чому основна причина переходу? дорого? тормозить?

Якось скучновато на штормі. У vim режимі зручно код писать, наприклад наводишся на будь який тег у будь-яке місце — жмякаєш cit — vim автоматично видаляє зміст всередині тегу і переводить тебе у режим вводу. Також легко можна робити кастомні макроси, аби не повторювати якісь дії по 50 разів. Пробував vim плагін для шторму — починають плутатись вімовські кнопки і штормівські, не зайшло. В плані UI своєї системи(Arch Linux в моєму випадку) я перейшов на i3, який теж підтримує vimівські комбінації клавіш, ще й файловий менеджер змінив на ranger(теж вімівські команди пітримує). Як тільки спробуєш і звикаєш — воно стає настільки зручно, що уже зовсім не хочеться вертатись до клави з мишкою). Ну і часу на редагування коду загалом менше йде, не витрачаєш час аби дотягнутись до мишки, а робиш то все в декілька натискань на клаву, при чому коли звикнеш — не задумуєшся навіть які кнопки натискати.

В плані швидкості — старт справді швидший, моєму vimу треба біля секунди аби завантажити мою стару сесію з 10 файлами, і для пошука по проекту індексація йому не потрібна, як шторму, і опори менше їсть.

Ну і 13$ лишніми ніколи не бувають :)

То все і в VSCode працює плагінами. 500мб файли не відкриє, але для щоденної роботи цілком зручно.

Завжди юзаю емуляцію vim у різних редакторах, але пересісти на самостійний vim для мене занадто хардкорно. Зараз сиджу на VS Code, там багато сучасних інструментів і все гарно працює, в тому числі емуляція VSCodeVim

Нет, это что-то вроде «некропост».

Коли я через ssh на терміналі налаштовую конфіг файли на linux сервері — vim то не погана штука, хоча ще є nano і редактор у midnight commander, якщо вони на сервері встановлені або є рутові права і можно встановити. Але писати C# код на Vim o_O. Це без студії і решейпера, вибачайте але як на мене це такий собі мазохізм.

Для C++ є RTags на базі CLang, який чудовий майже у всьому. Хоча не у всьому.

Без решарпера обходитися дуже просто. Roslynator — набагато швидше працює та й не потрібен цей зоопарк функціонала. Від самої студії як і будь-якого IDE, в першу чергу вимагається:
— ефективний набір коду (будь-яким методом)
— навігація по коду
— дебагер
— рефакторинг
Із цього списку VIM не дає тільки дебагер і рефакторинг пока відносно слабуватий.
Але із ростом підтримки LSP і з переходом Microsoft на LSP (їхній же стандарт) можливості будуть вирівнюватися.
Зато VIM виграє по першому пункту без варіантів. Навіть EMACs не тягне ))

github.com/puremourning/vimspector таки дебаггинг есть, геморно но можно запустить.

у midnight commander

слезы ностальгии побежали по щекам))

я переважно .NET-розробник і використовую Vim для роботи з .NET-кодом.

risovach.ru/...​em/322_77300682_orig_.jpg :)
статью почитаю вечером.

И для всех петросянов, которые спрашивают:

Статья классная, но всё равно не понятно как выйти из Vim

Ну запустите вы этот вим хоть раз!

~                type  :help iccf<Enter>       for information                  
~                                                                               
~                type  :q<Enter>               to exit                          
~                type  :help<Enter>  or  <F1>  for on-line help                 
~                type  :help version8<Enter>   for version info  

Зачем его запускать, если сложно выйти и для того чтобы редактировать нужно нажать «i»?)))

Зачем его запускать, если сложно выйти

Естественный отбор: человек не способный прочитать что написано на экране должен вечно смотреть в экран (вреда будет меньше приносить)

Часто на сервере больше ничего нет, и поставить ничего не можешь потому что нет прав. Поэтому приходится vim-ом конфиги править и хорошо ещё если это vim а не vi. При должной сноровке им вполне можно даже пользоваться, в отличие от vi. Ну а в основном это любимая тема на потролить от производителей IDE и инструментов, естественно писать таким образом код это извращение и по производительности с нормальным инструментарием в никакое сравнение не идёт.

взагалі-то для переходу в режим редагування є не одна, а багато команд. Найпоширеніші — i, a, o.

Якось рідко їх використовую, мабуть, не мої, нема для чого.
А ось r забув, да, це часто треба.

попробуйте ci" например чтобы заменить сразу весь текст между двумя ближайшими кавычками и сразу перейти в режим редактирования

А хто запускає вім без параметрів?

Коллега, я вот читал комменты именно потому что нужно этот мем запостить, но кто-то мог успеть раньше.

Emacs ничуть не менее сложен в освоении, там тоже отдельными командами можно вызвать появление всяких паранормальных окон внутри уже существующих окон, написать слово «Hello» на языке клингонских регекспов и всё такое прочее колдунство.

Там даже LaTeX можно фигачить, не приходя в сознание — opensource.com/...​loads/helloworld_file.png

Не одним вимом живо человечество же.

++ О, не я первый.

Знаєм, пробували:
wordpress.morningside.edu/...​les/2012/05/its-cover.png

Але за Lisp можна і потерпіти

Тооооочняк, именно такое ощущение!

Чому не neovim?

Цікава стаття, але головне питання залишилося без відповіді:
— Навіщо вона існує?

Можливо для того, щоб хтось знав, що є такі збоченці, як ТС і я.

Напомнило год эдак 2004, статьи от альва, форум на lafox, linuxforum.ru, очень стрёмный linux.org.ru и не менее стрёмный linux.org.ua. Следующей должна появиться статья о emacs.

Кстати, кто помнит/приложил руку/пасся в те годы на lafox.net?

Следующей должна появиться статья о emacs.

В 2009-м одна была уже :)
dou.ua/...​ticles/emacs-impressions

У меня до сих пор жива футболка с надписью «Unix» от lafox.net :)

lafox.net

Був там модератором деякий час.

Docker чудово працює з середени WSL2. Якщо налаштувати роботу systemd в wsl2 — то можно взагалі ставити звичайний docker усередені WSL замість комбайну Docker for Windows.

В MacOS для docker потрібно статично виділити певну кількість пам’яті (якої в маках або небагато або воно коштує неадекватних грошей) а в WSL2 пам’ять повертається Windows хосту коли вона звільняється.

І можно мати краще з двох світів — Vim (або neovim) екстеншн для vscode. ... Що також не відміняє використання vim з WSL, якщо потрібно.

в мене не вийшло під’єднати IDE з host системи до xdebug всередині докер імейджу під WSL2. на Лінуксі все вийшло без проблем, тож принаймні проблема не в конфігу власне xdebug, а щось з нюансами роутінгу «зсередині — назовні». Навіть тікет є але закрили через відсутність активності

З vscode — ніяких проблем, GUI на стороні вінди, але з remote extension дозволяє пряцювати так, ніби воно усередені Linux. З іншими IDE та тулзами може бути проблематично. Але я наприклад пускаю IDEA в WSL, з VcXsrv на стороні вінди — так простіше. Єдина реч що трохи дратує — новий IP в WSL після кожного перезапуску.

PhpStorm на Windows 10 + WSL 2 + xDebug всередині контейнера — все працює, але з налаштуваннями довелося повозитися.

крутота! не думали накидати статейку на dev.to?

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

Цитата «Я уже два года пользуюсь Vim, в основном потому, что не знаю, как выйти из него»

В 2020 шутить про выход из вима)

Не выходи из vim, не совершай ошибку

Статья классная, но всё равно не понятно как выйти из Vim

и удивляться «а что это за фигня у меня в файле появилась???»

Для таких есть ZQ

Подписаться на комментарии