В 2017 году я разговаривал с коллегой о будущем инструментов разработки. Этот разговор быстро перерос в дискуссию, так как я понял, что поддерживаю развитие облачных IDE. Мой специальный аргумент звучал так: «Все остальное находится в облаке… почему бы и вашим инструментам разработки тоже? Например, Google Docs для программирования…» Мой коллега, который был более опытным и талантливым программистом, чем я, высказал более традиционалистскую точку зрения. Он сказал, что облачные IDE никогда не смогут работать: интернет-зависимость, проблемы безопасности, привязка к поставщику и ограниченный контроль над инфраструктурой.

Безумно думать, но 2017 год был шесть лет назад (черт возьми, я старею)! С тех пор многое произошло. Стартапы облачных IDE, такие как Replit, имеют крупную инвестиционную поддержку, все крупнейшие облачные провайдеры имеют свои собственные облачные IDE, а появление мобильных телефонов и других тонких клиентов в развивающихся странах предполагает настоящий и будущий спрос на браузерная разработка. Оборачивая все это вокруг захватывающих инноваций, происходящих в области искусственного интеллекта, я понял, что разговор об облачной IDE для профессионального использования стоит пересмотреть.

Итак, я открыл свой LinkedIn, включил Don’t You от Simple Minds на повторе и отправил сообщение некоторым старым приятелям-программистам. Моя цель состояла в том, чтобы узнать об их текущей карьере, узнать об их инструментах и ​​процессах, а также обсудить будущие инструменты разработки. В частности, я хотел связать их опыт с жизнеспособностью развертывания облачной IDE, такой как Replit, в масштабе их профессиональной деятельности. Эта статья служит кратким изложением моих выводов.

Методология отбора и опроса

Приступая к этому проекту, я знал, что мне нужны интервью, наполненные нюансами и разнообразием мнений. Я знал, что опросы Twitter и Reddit не дадут много нюансов, поэтому решил взять интервью у пяти своих бывших друзей/коллег по 45–60 минут у каждого. Я признаю, что такой небольшой размер выборки не позволит мне обнаружить выпадающие точки зрения и обобщить вывод. Но эй, длинные обсуждения были более увлекательными и привели к более конкретным выводам!

Кроме того, я признаю, что большинство моих друзей/коллег — молодые программисты начального уровня. Зная, что мне нужно разнообразие мнений, я вышел из своего ближайшего окружения, чтобы найти потенциально уникальные точки зрения. Имея это в виду, вот мой список интервьюируемых! Обратите внимание, что я анонимизировал некоторую информацию по усмотрению интервьюируемого:

  • Брайан, старший аналитик по биоинформатике Орегонского университета медицинских наук, недавний выпускник магистратуры по науке о данных.
  • Джон, соучредитель и технический директор стартапа в сфере медицинских технологий.
  • Эрик, главный инженер-программист SaaS-компании из списка Fortune 50 с более чем 15-летним опытом работы.
  • Макс, инженер по облачной инфраструктуре крупного поставщика облачных услуг с несколькими сертификатами облачных служб.
  • Фиона, инженер-программист начального уровня в Google.

С помощью ChatGPT я составил следующие вопросы:

  1. Какие основные инструменты разработки вы используете ежедневно?
  2. Как бы вы оценили общую производительность и простоту использования средств разработки, которыми вы пользуетесь в настоящее время?
  3. Как вы сейчас сотрудничаете с другими членами вашей команды при работе над проектами кодирования? Асинхронно?
  4. Насколько важна для вас и вашей команды возможность легко делиться кодом и сотрудничать с другими?
  5. С распространением GPT и других инструментов искусственного интеллекта, какую роль играет искусственный интеллект в вашем рабочем процессе?
  6. Использовали ли вы когда-нибудь облачную среду разработки, и если да, то что вам в ней понравилось или не понравилось?
  7. Есть ли у вас или вашей команды какие-либо опасения по поводу безопасности или конфиденциальности данных, когда речь идет об облачной разработке?
  8. Есть ли какие-либо особенности или функциональные возможности, которые вы хотели бы видеть в облачной среде разработки?
  9. Каковы, по вашему мнению, основные проблемы, связанные с тем, чтобы заставить команду или организацию внедрить новый инструмент разработки, такой как Replit?
  10. Steelman/Strawman аргументы в пользу облачной разработки

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

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

Интервью №1: Брайан

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

Должность: старший аналитик по биоинформатике Орегонского университета медицинских наук.

Инструменты разработки и совместной работы, используемые в роли: Python, R, VS Code, RStudio, Github, SLURM. Также используется Discord и Deepnote в программе Masters.

Я взял интервью у Брайана, потому что мне нужен был кто-то с опытом работы с данными. Специалисты по данным постоянно заботятся об общих моделях, оперативной памяти и графических процессорах. Он также является последним выпускником колледжа в моем списке (со степенью магистра), что дает очень свежий взгляд на обучение и профессиональные примеры использования. Он также очень крутой чувак с милой дорожной кроватью в задней части своего внедорожника.

Когда я впервые попросил Брайана об интервью, он сразу же начал изучать Replit! Как и многие, он сравнил это с тем «волшебным» моментом, когда он впервые работал над документом Google в режиме реального времени. Брайан взволнованно объяснил, что его занятия в колледже были бы «настолько проще» Replit. Он описал эти спонтанные 10-минутные задачи в лекции, которые на Replit кажутся легкими. Брайан сказал, что его самые ценные школьные проекты — это проекты с большими наборами данных, которые нельзя хранить локально и которые имитируют количество и целостность реальных вариантов использования. Прекрасная возможность для облачных IDE — дать учащимся возможность подключать свой код к серверу, который дает учащимся ОЗУ и графический процессор, необходимые для работы с реальными данными.

Далее я спросил Брайана о реальных наборах данных, которые он использует в Орегонском университете медицинских наук (OHSU). Брайан

работает в отделе генетики, где он участвует в проектах, связанных с выявлением и описанием новых редких генетических мутаций. Он работает с наборами данных размером в терабайты, если не петабайты. Команда Брайана работает с этими данными поверх инфраструктуры, созданной Intel специально для OHSU. Чтобы запустить сценарий Python, Брайан открывает свой терминал, запускает команду SLURM, которая подключается к серверу, и настраивает сценарий bash, который позволяет ему настроить свою работу на основе раздела, оперативной памяти, количества процессоров и т. д. Команда администраторов следит за тем, сколько вычислительных ресурсов использует Брайан, размещая свои задания в очереди в зависимости от старшинства и используемых ресурсов. Для работы в разных командах и программах университетов потребовались бы дни, чтобы настроить мой ноутбук. В инфраструктуре Intel все настройки и выравнивание встроены. Моя команда буквально не существовала бы без него.

Что касается Replit, у Брайана были идеи. Поскольку партнерство с Intel обошлось в 22 миллиона долларов (плюс техническое обслуживание), Брайан заинтригован идеей сделать эту модель общих вычислений проще и доступнее для небольших организаций. Мы обсудили идею удаленного доступа к серверу, встроенного в IDE, а не через терминал. Это позволило бы специалисту по обработке и анализу данных сразу же видеть свои результаты в виде таблицы или визуала в каком-то CLUI, а не каждый раз загружать файл. Кроме того, уникальное введение Циклов в Replit хорошо подходит для модели очередей, принятой многими группами данных. В начале каждого месяца сотрудникам будет даваться x количество циклов, которое они тратят на свои сценарии. Чем больше вычислительных ресурсов, тем больше циклов. Эта модель обеспечит соблюдение бюджета, демократичное совместное использование вычислительных ресурсов, а также четкую видимость для администраторов.

Интервью №2: Джон

Не стоит недооценивать силу победы в «битве стилей». Если вы каким-то образом подключите Ричарда Столлмана к Replit, все его фанаты очень скоро присоединятся к Replit.

Роль: соучредитель и технический директор стартапа в области технологий для здоровья.

Инструменты разработки и совместной работы, используемые в этой роли:VS Code, Gitlab, iTerm, GCP, Terraform, Notion, Slack, Superhuman.

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

Джон является основателем стартапа в сфере медицинских технологий. Продукт имеет собственный хостинг и облачные варианты, и команда Джона в основном использует GCP и Terraform для создания этой инфраструктуры. Команда в основном работает удаленно, при этом большая часть совместной работы осуществляется посредством ежемесячных сессий дорожной карты, ежедневных стендапов и асинхронно через Slack и GitLab PR.

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

Наш разговор быстро превратился в мета-анализ культуры разработки и того, как она влияет на внедрение инструментов. Инженеры причудливы и самоуверенны. Многие до сих пор используют VIM и Emacs. Молодые инженеры обычно смотрят на самых крутых и талантливых членов команды и перенимают то, что они используют. Если бы инженер мог построить его, а не купить, он бы это сделал. Да, Replit должен продолжать создавать качественную IDE, которая может конкурировать с легким дизайном VS Code, качественным сообществом плагинов и стратегиями безопасности. Но Replit также должен конкурировать с тем, что он называет «битвой стилей». Джон впечатлен способностью Replit взращивать студенческое сообщество, которое со временем может стать профессионалом. Но отсутствие штатных, уважаемых профессионалов, использующих Replit, представляет собой как угрозу, так и возможность. Джон в шутку сказал: «Если вы каким-то образом подключите Ричарда Столлмана к Replit, все его фанаты очень скоро присоединятся к Replit». Но шутка оставила серьезный вопрос, на который нужно было ответить; может ли продвижение создателей контента и влиятельных лиц на Replit привести к серьезной финансовой отдаче?

Интервью №3: Эрик

За годы работы я заметил, насколько проще стало размещать приложения для обычного программиста на уровне приложений. Чтобы перейти к следующему этапу развития облака, уровень PaaS должен быть пуленепробиваемым.

Должность: главный инженер-программист в SaaS-компании из списка Fortune 50.

Инструменты разработки и совместной работы, используемые в этой роли:IntelliJ, AWS, Databricks, Docker, Kubernetes, Slack, Quip.

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

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

Что касается совместной работы, я спросил Эрика о типичном процессе, когда молодому удаленному разработчику нужна его помощь. Он объяснил, как молодой разработчик сделает PR, который Эрик развернет и развернет в новой среде. Этот шаг обязателен, потому что когда вы работаете с достаточно сложным программным обеспечением, код представляет собой всего лишь один маленький фрагмент; это компонент приложения с десятками внешних эффектов. Например, если бы код Python молодого разработчика не работал, Эрику нужно было бы рассмотреть, как код влияет на кластеры Airflow, запросы Databricks и асинхронные действия, которые трудно отлаживать. Для эффективного сотрудничества среда под кодом должна быть настроена очень точно в соответствии с потребностями продукта.

Это то, что принесло нам Replit и жизнеспособность чисто облачной разработки. На первый взгляд, Эрик воспринимал CodePen и HackerRank как конкурентов: инструменты, которые поддерживают случайные, общие вопросы программирования и оценки при приеме на работу, но не реальные инструменты, которые его команда могла бы использовать прагматично. Если бы команда Эрика когда-либо действительно рассматривала Replit, уровень PaaS должен был бы быть пуленепробиваемым, что напомнило мне о текущей работе Replit по строительству прочного фундамента.

После всего сказанного Эрик закончил разговор оптимистичными мыслями. После обсуждения недавнего твита Тоби Лютке об API, преодолевающем барьеры внутренней коммуникации, он был заинтригован идеей Replit как платформы для разработки API. Архитектуры REST API очень распространены и не так уж сложны. Эрик рассудил, что если вы можете безопасно разместить REST-приложение с помощью Replit, микросервисы можно будет очень легко использовать, просматривать и комментировать между командами. Как разработчик, вы тратите большую часть своего времени на то, чтобы выразить то, что делает ваш код, посредством комментариев, документации и встреч. Но в конце концов, если вы хотите знать, что делает код, вам нужно прочитать код или взаимодействовать с его API. Эрик сказал, что если бы Replit могла сделать API более живыми, понятными и повторяемыми, это было бы очень ценно.

Интервью №4: Макс

Было бы интересно, если бы Replit мог решить проблему двух внешних сторон, которые могли бы безопасно совместно работать над проектом кода.

Должность: инженер по облачной инфраструктуре крупного поставщика облачных услуг.

Инструменты разработки и совместной работы, используемые в этой роли:VS Code, Git, GCP, Azure, Terraform.

Я взял интервью у Макса, потому что его карьера олицетворяла основную идею этого проекта: что нужно для перехода в облако? Мы с Максом познакомились в колледже, и я увидел в нем одного из первых наставников в моем раннем путешествии по программированию. Он также очень крутой чувак, который может взорвать сцену караоке, распевая Led Zeppelin.

Макс работает инженером по облачной инфраструктуре в одном из трех крупнейших облачных провайдеров. Он работает в организации, предоставляющей профессиональные услуги, в основном помогая крупным компаниям переходить от локальной к облачной инфраструктуре. Роль Макса заключается в том, чтобы консультировать клиента по облачным продуктам, разрабатывать дорожную карту и проверять концепции в среде клиента. Хотя обычно он работает в VS Code и Git, все клиенты разные, поэтому он работает с множеством инструментов разработки.

Когда я впервые попросил Макса об интервью, он провел свое исследование! Он нашел Кейс Replit по GCP, и было здорово увидеть, насколько он грамотен, просто прочитав кейс. Оттуда мы говорили о жизнеспособности Replit при развертывании арендаторов в инфраструктуре компании, что позволило бы предприятию воспользоваться преимуществами совместной работы Replit с административным контролем, ожидаемым от любого ИТ-отдела. Макс предположил, что Replit работает в контейнерах Docker, которые можно извлечь как образ. Если Replit уже использует Terraform, активность извлечения изображений можно легко масштабировать. Далее Макс отметил, что Google, облачный провайдер Replit, выпустил Cloud Workstations, который позиционируется как облачная IDE корпоративного уровня со встроенными мощными облачными конфигурациями.

Помимо инфраструктуры, мы обсудили функции, которые должны быть в облачной IDE действительно корпоративного уровня. Быстрая мысль была о способности Replit работать на нескольких мониторах. У Макса четыре монитора со своей IDE на одном, оболочкой на другом и статическими файлами на другом. Как IDE на основе браузера справляется с установкой нескольких мониторов? Кроме того, Макс описал возможности кода в реальном времени как «крутые и ужасающие». Как облачная IDE справится с потоком «тестирование-подготовка-производство»? Если это с Git, что представляет собой коммит? И как он решает конфликты слияния? Помимо этих мыслей на уровне рабочего процесса, Макс закончил наше время с одной большой идеей. Он говорит, что у каждого технического консультанта есть одна и та же проблема: как легко подключиться к машинам или кодовой базе клиента. Существует множество блокировщиков, связанных с привилегиями и доступом для подготовки консультанта к проекту клиента. «Было бы интересно, если бы Replit мог решить проблему двух внешних сторон [консультанта и клиента], которые могли бы безопасно совместно работать над проектами кода». Решение этой проблемы помогло бы обычной практике парного программирования технического консультанта с клиентом, значительно сократив время адаптации и нормализовав сотрудничество.

Интервью №5: Фиона

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

Должность:внешний инженер в Google.

Инструменты разработки и совместной работы, используемые в этой роли:CIDER-V, Critique, Buganizer.

Я взял интервью у Фионы, потому что хотел поговорить с инженером из Google — компании, которая почти полностью программирует в облаке. Мы с Фионой пережили множество курсов Comp Sci и провели вместе несколько ночей. Она также очень крутая девчонка, которая может назвать любого аниме-персонажа и воспроизвести боевые сцены в стиле Т.

Хорошо… давайте на секунду поговорим о Google! Как одна из самых уважаемых инженерных организаций, Google привлекает поколения талантов для разработки наиболее широко используемого программного обеспечения в домах, школах и на предприятиях. Ключом к этому успеху является способность Google оставаться новаторами и обеспечивать исключительные операции. Чтобы заглянуть в будущее программного обеспечения, можно взглянуть на Google сегодня, и именно этого я надеялся добиться, поговорив с Фионой!

Фиона — начальный фронтенд-инженер потребительского продукта и одна из тысяч инженеров, работающих над CIDER-V: внутренней облачной IDE Google. Хотя он на 100% основан на браузере, она сравнивает его с VS Code: легкий, достаточно линтерный и настраиваемый. Основные преимущества CIDER-V заключаются в том, что он интегрируется со специфическими функциями Google, такими как прямая связь между строками Buganizer и TODO, а также прямое управление параллельными фиксациями. CIDER-V не имеет функции совместной работы в реальном времени. Что касается коммитов, Фиона высоко оценивает Critique, внутренний инструмент проверки кода Google. Как и Github, Critique предоставляет полезную параллельную историю различий кода, но ключевым фактором является то, что он живет в среде IDE. Для меня это делает Critique невероятно мощным плагином для CIDER-V, поскольку он дает Фионе пошаговое руководство по ее коду. Вместо страшных сбоев git в терминалах Critique заранее определяет несоответствия, которые обычно приводят к конфликтам слияния, и продолжает рекомендовать решения (потенциал для ИИ).

Поскольку Фиона была единственным человеком, у которого я брал интервью, который использует облачную IDE, я прямо спросил ее, должны ли другие компании использовать ту же архитектуру. Критика меняет правила игры, — сказала она. Конфликты слияния — это не пот. Я не могу представить себе возвращение к тяжелому рабочему процессу git. Это подтверждает то, что было известно Gitlab и Github; все чаще молодые инженеры стремятся использовать больше инструментов проверки кода на основе графического интерфейса. Кроме того, Фиона рассмотрела плюсы и минусы перехода стека разработки на 100% в облако. Безопасность — это палка о двух концах. Как правило, сотрудникам Google не разрешается иметь код на своем локальном компьютере. Это рассматривается как угроза безопасности. Это понимание было для меня захватывающим, потому что в других моих интервью облачные IDE воспринимались как риск безопасности. Но Google настолько уверен в своей инфраструктуре, что облако считается более безопасным, чем традиционное локальное хранилище. При этом у Google есть армия экспертов по облачной инфраструктуре. Фиона говорит, что если компания не использует безопасное облако, облачные IDE будут представлять риск.

Заключение

Как и ожидалось, все пять моих интервью были невероятно ценными! Их пересекающиеся и различающиеся точки зрения были одинаково проницательными, и я надеюсь, что в будущем у меня будет больше подобных бесед! Вот краткое изложение трех моих самых примечательных выводов:

  1. Первоначальная реакция на облачную IDE была встречена скорее с апатией, чем со скептицизмом. Судя по моему разговору, упомянутому в первом предложении этого блога, я ожидал, что собеседники критически отнесутся к облачным IDE и “ разорвать» его жизнеспособность с конкретными вариантами использования. Я был неправ! Все, даже Эрик, относительно поддерживали миссии Replit (и других). Настроение было скорее апатичным. Только Джон знал о Replit до того, как я упомянул об этом. После того, как разработчики выбрали свои инструменты, они какое-то время не думают об этом; они сосредоточены на своем программном обеспечении. Таким образом, при представлении облачных IDE разработчикам необходимо ответить на ключевой вопрос: «Что могут сделать облачные IDE, чего не может мой текущий стек, чтобы оправдать затраты на переход?»
  2. Никто не оспаривал фактор удобства облачной IDE. Существовал консенсус в отношении того, что функциональность совместной работы облачной IDE объективно удобна, что делает ее наиболее убедительным ценностным предложением «наименьшего общего знаменателя». Многие люди с ностальгией вспоминали свой первый опыт совместной работы с Google Docs и рассматривали эту функцию как долгожданное дополнение к инструментам разработки. При этом Эрик, Макс и Фиона думали, что живое сотрудничество будет иметь свою цену, например риски безопасности и/или конфликты слияния.
  3. Размер компании был более важным показателем внедрения новых инструментов разработки, чем возраст. Когда вы работаете в крупной компании, вы подсознательно ограничиваете себя инструментами и методами своих коллег. Как сказал Джон, вы делаете то, что делает лучший разработчик в вашей команде. Таким образом, в дополнение к ИТ-ограничениям, облачным IDE будет сложнее войти в любой вариант использования на предприятии, поскольку им придется преодолевать социальные препятствия. Компании малого и среднего бизнеса по своей природе более восприимчивы к новым инструментам, поскольку у них нет предвзятого представления о «правильном способе» создания своего программного обеспечения.

Что вы думаете, как читатель? Нашли ли вы что-нибудь особенно удивительное или наводящее на размышления в каком-либо интервью или кратком изложении? Пожалуйста, дайте мне знать! Спасибо за прочтение.