Transcription
[Музыка] Отлично. Мы действуем вслепую. Заметок нет, так что потерпите меня. Спасибо. Мне это нравится. Мне нравится такой настрой. Здравствуйте, меня зовут Бритни Эллик. Я старший инженер-программист в GitHub. Я не занимаюсь продажами, маркетингом или чем-то, что обычно хорошо продается. На самом деле, я даже не работаю в команде Copilot. Я работаю в отделе биллинга. Привет моим друзьям из биллинга. И я очень рада использовать Copilot coding agent. И сегодня я расскажу вам, что я узнала за более чем год использования его в GitHub, чтобы он лучше работал для меня и моей команды. Итак, вот что мы сегодня рассмотрим. Во-первых, я расскажу о проблемах, связанных с управлением техническим долгом. Затем мы поговорим о вашем новом ускорителе устранения технического долга — Copilot. И, наконец, я расскажу вам, как построить устойчивую стратегию управления техническим долгом, как использовать его изо дня в день, чтобы избавиться от этого технического долга в вашем бэклоге. Итак, существующие проблемы с управлением техническим долгом. У скольких из вас есть бэклог, который выглядит примерно так? Некоторые задачи, которые затягиваются на некоторое время, возможно, даже больше года. Такое бывает. И есть вещи, которые разработчики со временем добавляли в ваш бэклог, говоря: «Это то, что меня волнует, и то, что нам нужно исправить». Но у вас никогда не хватает времени, чтобы реально заняться ими. Это потому, что в борьбе между разработкой новых функций и техническим долгом новые функции почти всегда побеждают. И, честно говоря, на то есть веские причины. Я знаю, я разработчик, и мне очень нравится работать над этим, но новые функции — это ваше конкурентное преимущество, и именно они отличают ваше приложение от всех остальных. Поэтому имеет смысл, что большая часть времени разработчиков тратится на разработку новых функций. Но это чрезвычайно деморализует инженера, который владеет приложением и глубоко заботится о нем, никогда не иметь времени, чтобы потратить на этот технический долг. Вот как эта проблема развивается со временем. Она имеет тенденцию расти. Начинается с замедления вашей скорости. Инженерам приходится постоянно обходить проблемы, вместо того чтобы реально их решать. Вещи становятся более хрупкими. Люди начинают бояться трогать старый код. И тогда, наконец, вы достигаете этого обрыва, когда кто-то говорит: «Нам нужно переписать это с нуля». И я могу сказать вам, что это почти никогда не является хорошим решением. Ваши лучшие инженеры покинут кодовую базу. вы потеряете все накопленные знания, которые вы приобрели со временем. Это, честно говоря, отстой, как инженер, который делал это раньше. Это отстой. Мы снова и снова строим эти горы технического долга. Как нам их обойти? Что, если бы нам не пришлось выбирать между новыми функциями и техническим долгом? И именно об этом я здесь, чтобы поговорить с вами сегодня. Ваш ускоритель устранения технического долга — Copilot coding agent. Он всегда доступен, никогда не устает, всегда готов взять на себя скучные задачи, которые многие инженеры просто не хотят делать и никогда не могут расставить в приоритете. Ваша команда в настоящее время балансирует и вращает все эти тарелки. Такие вещи, как исправление ошибок, покрытие тестами, обновление текста, который ваш менеджер продукта действительно хочет, чтобы вы обновили. Вы можете передать все это Copilot, чтобы ваша команда могла работать над тем, что действительно важно. Они могут заниматься стратегическим планированием, которое развивает ваше приложение со временем. Теперь я собираюсь провести небольшую демонстрацию. Надеюсь, это хорошо сработает с этим, потому что я вижу только экран там наверху. Итак, я покажу вам, насколько это просто начать. Это запрос, который вы сможете использовать, и у меня есть слайд со ссылкой в конце, к которому вы все сможете получить доступ. Но вот как начать. Создайте задачу и назначьте ее Copilot. Вот и все. Очень просто. Вы можете взять любую задачу из вашего бэклога. Если бы вы назначили ее прямо сейчас, к концу моего выступления у вас было бы что-то для работы. Это очень здорово. Это один из способов, одно из мест, где я рекомендую начать — просто создавать тесты. Увеличьте покрытие тестами, прежде чем приступать к другим задачам. Это позволит вам вносить изменения без риска. Вы можете видеть здесь, что Copilot уже обратил на это внимание. У него уже есть PR в процессе для этого, что очень круто. Теперь, в интересах экономии времени, поскольку обычно это занимает около 8-10 минут, я открою уже завершенный с той же задачей. Немного магии. Вы можете просмотреть всю сессию, увидеть, что было сделано, увидеть все тесты, которые были добавлены к этому компоненту, и взглянуть на сессию и на то, что произошло во время этой сессии. Вы можете вернуться и задать ему больше вопросов, чтобы узнать, есть ли что-то еще, что вы хотите добавить, и просмотреть это, как любой другой pull request, который создал бы один из инженеров вашей команды. Это невероятно круто. Теперь. Хорошо. Но как люди на самом деле делают это изо дня в день? Как это выглядит для инженера-программиста, использующего этот инструмент? Я расскажу вам, как построить устойчивую стратегию управления техническим долгом. И я дам вам всем подарок. Я дам вам подарок, который поможет вам разобраться с вашим бэклогом. Простая маленькая аббревиатура, которую вы можете использовать, чтобы сделать Copilot coding agent более эффективным для вас и вашей команды. Во-первых, мы начнем с написания эффективных задач. Теперь вот задача, вероятно, написанная разработчиком. Обещаю, это не полностью основано на реальной истории, но это тот объем контекста, который вы можете получить от чего-то, что кто-то добавил в ваш бэклог, особенно если это инженер, рассматривающий задачу по техническому долгу. Это, вероятно, подойдет большинству старших инженеров в вашей команде, потому что у них есть весь контекст того, что вы строите, и они могут использовать это для дальнейшей работы. Но есть способы сделать это лучше, если вы собираетесь передать это coding agent. Во-первых, используйте описательный заголовок. Я всегда стараюсь точно определить, где я хочу внести изменения, и разбивать компоненты на несколько папок, когда это возможно, чтобы я точно знал, на что он будет смотреть и где будут вноситься изменения. Особенно когда у меня несколько PR одновременно, очень приятно иметь этот контекст. Далее, добавьте много контекста. Я всегда стараюсь писать задачу так, как я бы написал ее для кого-то, кто никогда раньше не работал с кодовой базой. Представьте, что у вас в команде совершенно новый человек. Что бы вы хотели видеть в этой задаче, чтобы он мог ее взять и начать работать? Далее, включите примеры. Если вы знаете, чего хотите, добавьте это в задачу. Это отличный способ экспериментировать, вводя новый шаблон в вашу кодовую базу, а затем пусть coding agent возьмет его и применит ко всей кодовой базе, что является гораздо более утомительной задачей, чем экспериментирование в первую очередь. Хорошо, следующий шаг — инструкции для репозитория. Это лишь один из многих наборов пользовательских инструкций, которые вы можете использовать, чтобы Copilot лучше работал для вашего приложения. Это страница документации для него. Вы можете указать инструкции для репозитория, чтобы ваше приложение, чтобы Copilot точно знал, как вы предпочитаете разрабатывать в вашем приложении, и он будет использовать этот контекст каждый раз, когда он запускает задачу. Это отлично подходит для таких вещей, как, я пишу на Go. Мне нравится использовать табличные тесты для разработки на Go. Затем я включаю это в свои инструкции, и каждый раз, когда Copilot запускает задачу, он включает эти табличные тесты, чтобы мне не приходилось говорить ему это в каждой задаче. Это очень, очень приятно. Далее, атомарные задачи. Вы можете посмотреть на это и подумать: «Это хорошо для действительно маленьких задач, но у нас есть большие проблемы, которые мы хотим решить». Ну, это то, что мы делаем уже очень давно в разработке программного обеспечения. Вы берете большие задачи и разбиваете их на мелкие части. Те же правила применяются, когда вы передаете это coding agent. Вы не просто скажете: «Создай кнопку редактирования виджета». Он определенно попытается, но у вас будут очень большие PR для рассмотрения, и это не будет для вас приятным временем. Но вы можете разбить это на мелкие части. Добавьте кнопку редактирования, внесите изменения в базу данных, создайте метод API, добавьте метрики для этой функции редактирования. Объединение всего этого помогает облегчить работу рецензентам и помогает быстрее продвигать эти задачи, чем иначе. И, наконец, работайте в паре с coding agent. Я думаю, что очень, очень важно помнить, в чем я хорош, а в чем хороши инструменты LLM. Например, я могу посмотреть на что-то и понять «почему». Я могу посмотреть на проблему и понять, действительно ли это решит проблему. Я очень хорошо справляюсь с неопределенностью. Я могу посмотреть на что-то и интерпретировать, ну, возможно, они на самом деле не имели в виду, что хотели этого так, в то время как coding agent не так хорош. Я могу читать между строк и учитывать бизнес-контекст проблемы, который может быть не заложен в инструкции. И, наконец, я могу посмотреть на что-то и иметь это кросс-системное мышление, чтобы увидеть, как это будет взаимодействовать с остальной частью вашей организации, что немного сложнее для LLM-инструментов, по крайней мере, сейчас. Посмотрим, где мы будем в следующем году. Coding agent хорош в другом. Он может расширять существующие шаблоны. Его неутомимое выполнение. Это одна из моих любимых вещей. Я могу утром назначить ему 10 PR, и он просто сделает это. Это потрясающе. Он очень хорош в повторяющихся задачах. Как я уже сказал, мне очень нравится делать первую часть чего-то, но я не хочу применять это ко всем остальным частям моей кодовой базы. Это не так весело работать. Так что это отличный сценарий использования для coding agent. И, наконец, он очень хорош для изучения возможностей. Если вы смотрите на проблему и думаете, я могу решить ее так, или так, или так, назначьте все три coding agent и посмотрите, что получится. Вы можете увидеть, как это выглядит, прежде чем тратить время на итерацию самостоятельно, и сэкономить себе столько времени. Вот как выглядит мой рабочий процесс разработки в обычный день. Вот как он разбивается на то, что я на самом деле делаю изо дня в день. Итак, у меня есть встречи, надеюсь, не слишком много, а затем я выделяю время, которое я специально посвящаю PR Copilot. Я сортирую задачи, просматриваю PR, объединяю их, а затем выделяю свое собственное время на разработку, потому что это не так, что я не занимаюсь разработкой изо дня в день. Я оставляю это время для больших задач, для пугающих ошибок или для исследований в новых областях, а затем передаю эти задачи Copilot. Я обнаружил, что в среднем, занимаясь обычной гибкой разработкой, я по-прежнему занимаюсь одной задачей разработки для себя, но я обычно могу одновременно вести три-четыре PR от Copilot coding agent, и это примерно тот объем контекста, который я могу обрабатывать. Это совершенно другой способ работы, и вам нужно намеренно решить, что вы собираетесь делать это так. Это отличается, и поначалу это немного неудобно, но в конце концов это того стоит, потому что удивительно, насколько больше этого технического долга вы можете избавиться в том, что уже есть в вашем бэклоге. Позвольте coding agent управлять местностью, пока вы исследуете новые области. Вы можете превратить свои горы технического долга в управляемую местность. Я призываю вас взглянуть на свой бэклог сегодня. Вы можете даже посмотреть его на GitHub mobile. Это здорово. Посмотрите, назначьте что-нибудь Copilot, посмотрите, что он сделает. У вас, вероятно, уже есть что-то в вашем бэклоге, ожидающее решения. Большое спасибо за ваше время. Вот QR-код со ссылкой, если вам нужно много других ресурсов. И, наконец, я просто хочу сказать, пожалуйста, подойдите поздороваться со мной или с кем-нибудь с розовым бейджем. Мы очень дружелюбны. Мы будем рады поговорить с вами. Большое спасибо, что пришли на GitHub Universe. Спасибо. [Музыка]