Автор Дэйв Николетт

В части 1 этой серии я изложил причины попытки создания минимальной среды разработки и поставил цель для этого проекта. Я также обобщил свой опыт создания такой среды с использованием множества небольших дистрибутивов Linux. В этом сегменте я делюсь результатами построения среды на Debian Linux с редактором NeoVim в качестве основного инструмента разработки.

Существует так много подробной информации о том, как именно устанавливать различные инструменты, какие плагины Vim работают, а какие нет, и где есть «подводные камни», что я решил, что это слишком много для публикации в блоге. Ниже приводится краткое изложение конечных результатов без излишнего описания, за исключением случаев, когда требуется объяснение.

Ограничения

Я ограничился экземпляром 512 МБ, чтобы быть уверенным, что есть достаточный запас для запуска необходимого программного обеспечения в более нормальной, но все же небольшой системе, такой как Raspberry Pi 3B + с 1 ГБ оперативной памяти. Я также хотел загрузить в него как можно больше языков и плагинов Vim, чтобы доказать, что для всех этих инструментов было достаточно места как в памяти, так и в постоянном хранилище. Это не потому, что я ожидаю, что кто-то будет работать с 30 или 40 различными языками на регулярной основе, а скорее для того, чтобы доказать, что любой профессиональный разработчик должен иметь возможность настроить подходящую среду в рамках этих ограничений памяти и хранилища.

Уроки выучены

  • Возможно собрать удобную и продуктивную среду разработки в небольшом экземпляре ОС (всего 512 МБ ОЗУ) и с использованием минимума различных инструментов (редактор NeoVim с плагинами, а также несколько инструментов командной строки). Из 35 протестированных языков программирования, сценариев и разметки 34 работали, по крайней мере, до некоторой степени, а оставшийся не мог быть построен с учетом установленных мною жестких ограничений памяти. Этот результат указывает на то, что было бы вполне реально настроить легкую среду разработки, которая поддерживала бы несколько языков, которые реально может использовать реальный человек. Я никогда не слышал о том, чтобы у него была рабочая установка для разработки на 35 языках.
  • Конфигурация без мыши удобна и основана на Debian Linux, оконном менеджере OpenBox для X и NeoVim. Когда я говорю «удобно», я имею в виду, что это кажется естественным, в отличие от использования среды IDE, в которую задним числом были добавлены некоторые сочетания клавиш.
  • Для большинства языков вы жертвуете некоторыми удобствами IDE, но все равно можете выполнять работу; может подойти, если вам нужно работать с несколькими языками и в целом вам нужна простая среда. Также может быть нормально, если вы все равно предпочитаете работать с командной строкой, и вы обнаружите, что вся «помощь», предоставляемая IDE, менее полезна, чем предполагалось.
  • Для некоторых языков рабочий процесс разработчика в минимальной среде на самом деле лучше, чем в полнофункциональной IDE; особенно Scala, Ruby и COBOL; Опыт разработчика .NET сравним с использованием VSCode; на мой взгляд, лучше, чем использовать VisualStudio. Работа с Markdown или с языками разметки и надмножествами, такими как Haml, сравнима с использованием Sublime Text 3 или Atom.
  • По большей части доступные плагины Vim плохо документированы и не поддерживаются. Некоторые из них очень хороши, но в целом вы не можете рассчитывать на их работу или даже установку, а когда что-то пойдет не так, вы должны рассчитывать на устранение неполадок самостоятельно. По крайней мере, половина плагинов, которые я пытался использовать, не работали. Во многих случаях вы можете получить разумную подсветку синтаксиса и отступы, а в некоторых случаях разумное завершение. Кроме того, будьте благодарны за все, что работает.

Хороший рабочий процесс

Пробуя Scala, я обнаружил, что с sbt возможен очень хороший рабочий процесс разработчика. Я подозреваю, что многие люди, которые работают со Scala каждый день, уже делают это. Когда я установил sbt, я понял, что мне не приходило в голову настраивать такой рабочий процесс при использовании IDE, если инструменты не были встроены в IDE. В этом смысле я стал ленивым. Этот более простой набор инструментов сделал все неизбежно видимым.

С помощью консоли sbt, наблюдающей за каталогом проекта Scala в одном окне, и редактора, открытого в другом окне, вы можете плавно перемещаться между изменениями кода и результатами изменений. Видео ниже показывает это на минимальной виртуальной машине. NeoVim открыт в верхнем окне, а консоль sbt запущена в нижнем окне. Команда ~ run в консоли sbt заставляет sbt запускать сборку каждый раз, когда обнаруживает изменение исходных файлов Scala в проекте. Для меня это проще сделать с помощью простого текстового редактора и окна командной строки, чем при работе в среде IDE.

Для эксперимента я не нашел времени, чтобы определить полномасштабную настройку проекта с тестами и т. Д., Но было бы легко экстраполировать этот рабочий процесс на цикл рефакторинга красный-зеленый. Возможно, вы видели и работали с аналогичными установками, используя автотест для Ruby или Infinitest для Java, или даже сценарий командной строки, выполняющийся в цикле по таймеру. Легкая среда может довольно легко поддерживать такого рода вещи.

Почти, но не совсем все единороги и радуги: консоль sbt не всегда отключается чисто. Иногда он оставляет в памяти "сиротский" процесс Java. В этой небольшой среде при следующей попытке загрузить программу вы обнаружите, что у вас уже недостаточно памяти. Возможно, вам придется убить Java-процесс sbt, прежде чем вы сможете делать то, что хотите делать дальше. Достаточно легко написать сценарий, но это еще одна вещь, которую нужно написать, чтобы сбалансировать среду.

Разработка Arduino

Для этого эксперимента я не пробовал разрабатывать Arduino. Однако, судя по довольно недавней (2017 г.) статье Криса Риттерсдорфа Программирование Arduino в Vim, это кажется выполнимым.

Я уже упоминал, что плагины Vim не всегда надежны и не обязательно должны поддерживаться в течение длительного времени. Крис обнаружил то же самое, когда намеревался настроить Vim для разработки на Arduino. В его статье содержится предостережение от определенных плагинов Vim, которые вы можете найти при поиске в Интернете.

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

Особые случаи - Vim не рекомендуется

Поклонники Vim любят говорить, что их любимый плагин «превращает Vim в полноценную среду IDE», и некоторые из них идут на многое, чтобы дублировать или имитировать функциональность специализированных инструментов разработки с помощью конфигурации и плагинов Vim. Нет ни одного случая, когда это утверждение верно, и в первую очередь это не цель создания минималистской среды.

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

Вся идея заключается в простоте. Как только вы выйдете за пределы точки убывающей отдачи от плагинов, вы подорвите цель простоты.

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

R - рекомендую RStudio
Серьезный пользователь R, вероятно, является Quant, а не разработчиком многоязычных приложений, и его не заинтересует такая многоязычная установка. Лучший плагин Vim для R - это Rvim-R, который не работает так, как рекламируется, и даже если бы он работал, он не обеспечил бы возможности разработчика, даже отдаленно сопоставимые с RStudio.

Java / Groovy - рекомендую IntelliJ IDEA или Spring Tool Suite
При установке соответствующих плагинов Vim опыт разработчика неплох, но все же не так гладко, как с полной IDE. Эта среда подойдет для случайного использования или для человека, хорошо знакомого с Java, которому не нужно много рук в среде IDE. (Примечание: другие языки на основе JVM подходят, например Clojure, Kotlin и Scala.)

Lisp / Scheme / Racket - рекомендуйте Emacs / Slime для Lisp / Scheme и DrRacket для Racket
Редактирование этих языков с этим стеком инструментов является проблемой. Ответы командной строки работают хорошо, но опыт разработчиков с Vim очень плох. Плагины, предназначенные для «помощи» круглыми скобками, только усугубляют ситуацию. Если вы хотите, чтобы в этой среде был доступен язык, похожий на Lisp, я рекомендую Scheme без добавления подключаемых модулей Vim; он казался лучшим из трех. Я использовал мит-схему.

Разработка под Android - рекомендуйте Android Studio
Поклонники Vim говорят, что вы можете разрабатывать для платформы Android с помощью подключаемого модуля Eclim. Один из способов работы Eclim - это связь с автономным экземпляром Eclipse для использования функций Eclipse. Eclipse с надстройкой ADT раньше был стандартным способом разработки приложений для Android. Помимо введения накладных расходов из-за одновременного запуска двух инструментов разработки, использование Eclim с Vim создает зависимость от инструментов, которые прекращаются. Он также создает довольно сложную стопку, состоящую из компонентов, которые не предназначены для наложения друг на друга таким образом. В конце концов, если вы вообще сможете заставить эту настройку работать, опыт разработчика будет хуже, чем Eclipse с ADT, а Eclipse с ADT хуже, чем Android Studio. Зачем туда ехать?

Разработка для iOS - рекомендуйте XCode для OS X
Люди пробовали и не смогли найти множество способов настроить Vim для разработки под iOS. Тем, кто категорически настроен на использование Vim, следует подумать о том, чтобы пойти другим путем: использовать плагин Xvim для XCode вместо того, чтобы пытаться добавить все, что им нужно из XCode в Vim.

А как насчет устаревшего кода?

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

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

Сводка по окружающей среде

Минимальная среда разработки работала хорошо настроенной следующим образом.

Общие замечания

  • При общем объеме памяти 512 МБ во время этого эксперимента не было времени, когда система чувствовала себя вялой и не было ошибок, связанных с памятью, кроме как при установке Idris и первоначально при запуске Scala sbt.
  • Виртуальный жесткий диск, полностью загруженный инструментами и библиотеками, занимал 15 ГБ пространства. Это включает в себя операционную систему. Все было в одном разделе.
  • Я не устанавливал менеджеры версий, такие как rvm, rbenv и nvm. Обоснованием было использование альтернативной системы Debian для управления несколькими версиями программного обеспечения. Я хотел избежать загрузки избыточных инструментов для управления версиями, придерживаясь минималистского подхода.

Виртуальная машина

  • Гость VMware
  • 64-битный
  • 512 МБ памяти
  • Виртуальный диск 20 ГБ

Операционная система

  • Debian 9
  • пакеты разработчика в соответствии с требованиями различных языков

Оконный менеджер

Упорство

  • Sqlite3 - реляционная БД
  • PostgreSQL - реляционная БД
  • MongoDB - база данных документов
  • BerkeleyDB - индексированные файлы

HTTP-серверы

  • Nginx
  • Lighttpd
  • различные встроенные в языковые дистрибутивы (Npm, Python, Java и т. д.)

Инструменты для тестирования

редактор

  • NeoVim с:
  • патоген - менеджер пакетов
  • vim-plug - менеджер пакетов
  • deoplete - многоязычное завершение
  • neomake - интегрированный инструмент make
  • rainbow_parentheses - сопоставление скобок
  • NerdTree - встроенный файловый браузер
  • Цветовая схема Spacegray
  • и многочисленные языковые плагины

Языки программирования / сценариев / разметки и плагины NeoVim [0] Ошибка [1] Работает в среде, но без помощи Vim [2] Плагин Vim работает частично (или я не мог понять)

[3] Плагин Vim кажется работает

[4] Плагин Vim работает хорошо

[5] Рабочий процесс разработчика хороший (на мой взгляд)

  • [2] Awk
  • [2] Баш
  • [3] C/C++
  • [5] Clojure
  • [5] КОБОЛ
  • [2] CoffeeScript - встроенная программа make работала, режим разделенного окна не работал.
  • [5] C#
  • [3] Эликсир
  • [3] Эрланг
  • [5] F#
  • [4] Go
  • [3] Отличный
  • [3] Хамл
  • [4] Haskell - используется плагин ghc, а не Vim.
  • [3] HTML
  • [0] Idris - недостаточно памяти при установке
  • [2] J - плохая документация; ты должен возиться с этим
  • [3] Java
  • [3] JavaScript / узел
  • [3] JSON
  • [3] Котлин
  • [3] LaTeX
  • [1] Lisp - проблемы с плагинами Vim
  • [3] Lua
  • [2] Markdown - проблемы с редактированием плагина; плагин предварительного просмотра ОК
  • [3] Матлаб
  • [1] OCaml - проблемы с плагинами Vim
  • [3] Perl
  • [3] Python3
  • [1] R - проблемы с плагинами Vim
  • [1] Racket - проблемы с плагинами Vim
  • [5] Рубин
  • [3] Sass
  • [5] Скала
  • [1] Схема - проблемы с плагинами Vim
  • [3] SCSS
  • [2] TypeScript - несколько высоко оцененных плагинов; очень мало доставлено
  • [3] XML
  • [3] VimScript
  • [5] VisualBasic
  • [3] XML

Заключение

Из этого упражнения я пришел к выводу, что можно создать легкую среду, полностью подходящую для профессиональной разработки программного обеспечения, которая легко поместится в небольшой виртуальной машине, контейнере Docker или Raspberry Pi. Есть некоторые виды разработки, для которых эта среда не подходит, но для общей разработки приложений на большинстве языков это подойдет.

Мне любопытно создать машину для разработки на основе дешевого оборудования и нескольких из этих инструментов разработки и посмотреть, как это пойдет. В конце концов, мне не нужны 35 языков; Я просто хотел набить эту штуку как можно полнее, чтобы доказать или опровергнуть гипотезу о том, что это сработает. Следующий эксперимент может состоять в том, чтобы собрать систему и какое-то время использовать ее для реальной работы, а затем сообщить о плюсах и минусах. Это будет более узкая и глубокая проба идеи с выбранным набором инструментов разработки, полностью настроенным для использования в реальном мире.

Об авторе:

Дэйв Николетт был ИТ-специалистом с 1977 года. Он занимал различные технические и управленческие должности. Он работал главным образом консультантом с 1984 года, оставаясь одной ногой в техническом лагере, а другой в лагере менеджеров… Подробнее.

Первоначально опубликовано на www.leadingagile.com 29 августа 2018 г.