Возвращение I обратно в IDE: на пути к Github Explorer

Ссылка на оригинал - https://blog.janestreet.com/putting-the-i-back-in-ide-towards-a-github-explorer/, автор публикации - James Somers

Представьте себе систему для редактирования и просмотра кода, где:

  • Каждая ветка каждого репозитория получает свой собственный каталог с песочницей. Ваша история ревизий в каждой ветке, включая незафиксированные данные, сохраняется, как и артефакты сборки. Когда вы переключаете контексты, каждый проект такой же, как вы его оставили.

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

  • Проверка кода происходит полностью в редакторе. Вы получили серию различий: одно нажатие клавиши для подтверждения, одно нажатие клавиши для начала редактирования. Погрузитесь, внесите свои изменения, оставьте комментарии автору, нажмите и двигайтесь дальше.

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

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

Проблема в том, что он довольно сильно связан с нашей несколько необычной цепочкой инструментов: мы используем Mercurial для контроля версий; вместо того, чтобы отправлять запросы на загрузку в Github, мы отправляем «функции» в Iron, систему проверки кода, которую мы написали в OCaml; и чтобы связать все это вместе, мы используем пользовательский интерфейс под названием «Feature Explorer», который мы создали на основе Emacs.

Таким образом, цель этого поста - просто показать, как выглядит результат - показать, какой тип рабочего процесса возможен, - в надежде, что он вдохновит аналогичные инструменты в других экосистемах. Правда в том, что после написания кода на работе таким образом какое-то время вы начинаете желать, чтобы у вас было нечто подобное дома. Но нет ничего подобного для Git и Github и таких редакторов, как Vim, Textmate или VS Code.

Как могут выглядеть Git и Github с действительно глубокой интеграцией редактора

Когда вы идете по офису здесь, вы увидите одно окно, открытое на экране каждого разработчика:

Feature Explorer todo

Это ваша задача в Feature Explorer. В самом верху находятся функции, которые вы назначили для проверки, а ниже - функции, которыми вы владеете.

(Обратите внимание, что мы называем все «функцией», но на самом деле они бывают двух разновидностей: функции, которые готовы к рассмотрению, являются эквивалентом запросов извлечения, а функции, которые вы просто взламываете в частном порядке, эквивалентны ветвям.)

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

Когда вы углубляетесь в функцию, вы видите страницу, похожую на ту, что вы видите на Github для запроса на извлечение:

Github вид функции

Feature Explorer вид функции

(Как бы вытащил запрос Github, если бы это была функция Feature Explorer.)

Конечно, разница в том, что здесь эта «страница» - просто буфер в вашем редакторе. Это означает, что вы можете нажать Enter и вместо того, чтобы получить список инертных различий в вашем веб-браузере, вы получите разностные файлы, которые могут одним нажатием клавиши перенести вас на те самые строки, которые были изменены - загруженные прямо в вашем редакторе.

Детализация в Feature Explorer

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

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

  1. Вы использовали инструмент обзора кода Github-esque, чтобы получить общее представление о том, что делает функция (запрос на извлечение), включая файлы, которые она изменяет.
  2. Вы использовали инструмент контроля версий Git-esque, чтобы проверить (git checkout) конкретное хранилище и ветвь для этого запроса на извлечение.
  3. Вы использовали файловую систему для переключения в соответствующий каталог, в котором находится репозиторий и ветка live (cd ...), чтобы вы могли компилировать, запускать тесты, управлять историей ревизий и т. п. В песочнице.
  4. Вы использовали редактор, чтобы загрузить файл, который вам нужен, в буфер, где вы можете вносить изменения, использовать завершение кода и так далее.

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

Это делает почти тривиальным переключение контекстов. Допустим, я хочу вызвать запрос на извлечение сотрудника в совершенно другом репо. Я разделил свое окно Emacs, перешел к глобальной задаче, наведя курсор на ее объект, Enter, Enter, и теперь у меня есть diff или сам базовый файл, загруженный в мой буфер. Я могу вносить изменения в файл и отправлять их, я могу запускать сборку против изменений моего коллеги и т. Д., И все это никак не влияет на мою функцию; все, к чему я прикасаюсь, помещено в песочницу для мира ее запроса на получение. Когда я закончу, я закрою окно и вернусь к тому, что я делал. Мне буквально никогда не приходилось покидать мой редактор.

Вы можете подумать, эй, у Atom появилась новая интеграция с Github! Разве это не то же самое?

Интеграция Atom с Github, как и улучшение, не намного больше, чем окно браузера, которое находится внутри вашего редактора. Переход к запросу извлечения внутри окна Github не меняет «где вы находитесь» на диске; вы не можете просто перейти от репо к репо и прямо в редакторе вытащить файл в том состоянии, в котором он находится в этом запросе на извлечение.

Как только вы это сделаете, вы захотите, чтобы эта функциональность существовала везде, где люди пишут код.

Жизненный цикл запроса на выборку в Feature Explorer

Давайте вернемся к основной задачи и создадим новую функцию. Это похоже на создание новой ветки в git и одновременный запрос на загрузку в Github. Просто нажмите !cи дайте имя функции, указав, к какому репо она относится.

Создание функции

Когда вы нажимаете Enter, уже Iron создал «рабочее пространство» для новой функции. Под капотом рабочие пространства управляются с помощью расширения Mercurial под названием ShareExtension; эквивалент git будет иметь несколько клонов одного репо на одном диске.

На Jane Street работает так, что у каждого пользователя есть каталог ~/workspaces на своем диске. В ~/workspaces/REPO/+clone+/ есть полный клон репо; затем вы выполняете свою работу в ~/workspaces/REPO/BRANCH1/+share+ и ~/workspaces/REPO/BRANCH2/+share+/ и так далее.

Эти каталоги +share+ имеют очень маленькие каталоги /.hg по сравнению с основными + clone + one, потому что версии в каталогах +share+ в основном состоят из указателей на каталоги +clone+.

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

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

Новая функция

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

  • Это может быть в настоящее время на рассмотрении. В этом случае вы увидите, сколько осталось рецензентов.
  • Это может быть готово к выпуску. Весь ваш код был проверен и одобрен: если у вас есть необходимые разрешения, просто нажмите !rl«Release» (т. Е. Объедините pull с master).
  • Это может быть совершенно новый, ожидая, пока вы добавите код или включите обзор. Функция, в которой проверка не была включена, похожа на ветку, над которой вы работаете в частном порядке, а не на пул-запрос. Это не видно другим людям. Зайди туда и начни взламывать.

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

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

Когда вы сделаете это, вы заметите, что ваш корневой каталог изменился на ~/workspaces/REPO/BRANCH2/+share+/, потому что вы находитесь в песочнице.

Рабочая среда

Чтобы «отправить запрос на извлечение», вам нужно только «включить проверку», т. е. !e нажать на главной странице функции - внезапно, функция станет общедоступной и появится в задачах других людей. Что хорошо в этом рабочем процессе, так это то, что так же просто отключить проверку, скажем, если чьи-то комментарии в обзоре кода привели к серьезному переосмыслению подхода к этой функции. Вы можете замолчать, взломать взломать взломать и снова включить, как только вы будете готовы снова показать свой код миру.

Обзор кода

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

Но мы хотим, чтобы вы как можно быстрее входили и выходили из обзора кода. Вот как это работает. В Feature Explorer выполнение обзора - это переход к глобальной задаче, нажатие Enter на одной из назначенных вам функций и нажатие r. Это вызовет такой экран:

Сводка обзора кода

Каждая из этих строк представляет собой патч для вашего обзора. Нажмите Enter еще раз, чтобы прочитать его:

Патч обзора кода

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

Если вам нравится то, что вы видите в данном патче, просто нажмите, !rчтобы одобрить его. Если вы этого не понимаете или хотите оставить комментарий, вы можете открыть файл, нажав e. Файл откроется в вашем редакторе в специальной песочнице. Feature Explorer даже поместит ваш курсор точно на линию, затронутую патчем.

На Джейн-стрит рецензенты оставляют заметки как буквальные комментарии в коде. Их отличает специальное обозначение «CR» в начале комментария. Вы можете назначать CR, разрешать их и т. Д., Просто редактируя текст комментария, используя специальный (но простой) синтаксис.

CR шаг 1

CR шаг 2

(Пересмотр кода происходит в самом коде с использованием специальных комментариев «CR». Ожидающие CR отображаются в задании назначенного пользователя.)

Эта система может показаться примитивной по сравнению с пользовательским интерфейсом комментирования в браузере Github, но это означает, что вы можете выполнять обзор кода полностью в своем редакторе. А так как Feature Explorer настолько тесно интегрирован с системой анализа кода, тривиально привлечь других людей к участию: если вы назначаете кому-либо CR, функция, частью которой он является, сразу же появляется в их задачах.

Иди и процветай

В Mercurial, Iron или Emacs нет ничего особенного, что делает эту систему возможной. Любой расширяемый редактор - например, Vim, Atom, VS Code, Textmate - может поддерживать основной пользовательский интерфейс. Глубокая интеграция для git уже существует в большинстве этих редакторов, и Github API должен быть достаточно мощным, чтобы поддерживать систему обзора кода, подобную Iron.

Части с наибольшим эффектом в некоторых отношениях являются наиболее простыми, например, часть, которая позволяет переходить от запроса на загрузку Github к файлу в определенной ветви на локальном диске. Если у вас уже есть клон репо, ветвление дешево; создание изолированных каталогов - это дешево; и при достаточно хорошем интернет-соединении перечисление запросов на получение и файлов, на которые они влияют, обходится дешево. (Одна из вещей, которые мы обнаружили в нашей системе, это то, что она действительно не щелкала, пока у нас не было сервера обзора кода менее 100 мс.) Остальное - в основном клей редактора.

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