Современные инженерные работы редко хранятся в одном файле. Реальные системы развиваются в течение многих лет принятия последовательных многоуровневых решений – некоторых хороших, некоторых случайных. Один запрос на функцию («добавление тегов в заметки», «рефакторинг уровня проверки», «поддержка нового потребителя с помощью нашего API») часто затрагивает контроллеры, модели предметной области, репозитории, миграции, тестирование, документацию и стратегию развертывания.
Агентские возможности CoPilot не заменяют ваше суждение в таких ситуациях – они усиливают его. При правильном использовании Copilot становится партнером в проектировании системы, рефакторинге, модернизации и координации нескольких файлов.
В этом руководстве основное внимание уделяется многоэтапным рабочим процессам с учетом архитектуры, которые ежедневно используются штатными инженерами, но оно написано так, чтобы быть доступным для начинающих инженеров, которые хотят понять Как Старшие инженеры думают о том, как Copilot может ускорить их разработку.
Он основан на четырех упражнениях на GitHub (ссылки приведены ниже) и создает полный реальный сценарий: расширение небольшого модульного сервиса заметок с помощью подсистемы тегов, реинжиниринг уровня проверки, разработка безопасной миграции и модернизация тестов.
прежде чем начать
Вы получите максимальную пользу от этого руководства, если у вас есть:
- GitHub Copilot с включенным режимом агента
- Некоторое знакомство с архитектурой сервисного уровня (Node, Python, Go — язык не имеет значения)
- Скопируйте шаблон упражнения по навыкам GitHub на свой адрес или в организацию (используйте зеленую кнопку «Копировать упражнение»).
- Готовность позволить второму пилоту предлагать решения, а также решение наблюдать и оспаривать их.
Если вы только начинаете свою карьеру, не волнуйтесь. Каждый раздел объясняет Почему Эти шаблоны имеют значение, а также то, как безопасно их практиковать.
Использование Copilot для проектирования и декомпозиции системы (не только построения лесов)
Старшие инженеры редко начинают с написания кода. Они начинают с определения границ: логики предметной области, доступа к данным, интерфейсов и того, как модули должны взаимодействовать.
Режим второго пилота может помочь выявить структурные проблемы и предложить архитектуру.
быстрый:
Analyze this service and propose a modular decomposition with domain, infrastructure, and interface layers.
Identify anti-patterns, coupling issues, and potential failure points.Обычно вы получаете обратно:
- Предлагаемые ограничения модуля
- Проблемы межуровневой связи
- Асинхронные/транзакционные потери
- дублирование или консолидация обязанностей
- Последствия тестируемости и наблюдаемости
Это превращает Copilot из инструмента самозавершения в рецензента проекта.
Вы можете пойти дальше, попросив его сравнить архитектуры:
Compare hexagonal architecture vs. layered architecture for this codebase.
Recommend one based on the constraints here. Include tradeoffs.Хотите попробовать сами? Используйте эти предложения в качестве отправной точки.
Создание модульного сервиса с использованием агентских рабочих процессов
После определения ограничений второй пилот может координировать изменения в модуле.
готовый: :
Implement the domain, controller, and repository layers as distinct modules.
Use dependency inversion to reduce coupling.
Document assumptions and contracts for each module.Второй пилот обычно генерирует:
- интерфейс модели предметной области
- сводка акций
- логика контроллера, вызывающая доменные службы
- Краткое описание Markdown с описанием каждого модуля
Для начинающих инженеров это дает возможность познакомиться с реальными инженерными моделями. Для старших инженеров это обеспечивает рычаги воздействия и снижает стандартные накладные расходы.
Работа с функциями с учетом архитектуры (пример: подсистема тегов)
Добавление подсистемы тегов — обманчиво простой запрос, имеющий значимые архитектурные последствия.
Даже эта единственная особенность заставляет принимать решения по всей системе:
- моделирование данных: Встроенные теги, нормализованные таблицы и отношения «многие ко многим»
- Поведение поиска: Как теги влияют на индексацию, фильтрацию и релевантность
- Контракт API: Являются ли теги первоклассными ресурсами или деталями реализации?
- Ограничения проверки: Где применяются ограничения и инварианты
- Миграция и внедрение: Стратегия аддитивных и критических изменений и отката
Прежде чем прикасаться к коду, попросите второго пилота составить карту воздействия.
готовый: :
Propose the architectural changes required to add a tagging subsystem.
Identify migration needs, cross-cutting concerns, caching or indexing implications, and potential regressions.Второй пилот может распознать:
- Отношения тег-примечание (один-ко-многим или многие-ко-многим)
- миграционная стратегия
- Влияние на логику поиска
- необходимые тестовые обновления
- Изменение логики проверки
- Влияние на внешних потребителей API
Это подход на уровне персонала, который Copilot может помочь младшим разработчикам внедрить.
Затем реализуйте это:
Implement the tagging domain model, schema changes, repository updates, and controller logic.
Update tests and documentation. Show each change as a diff.Пример вывода (упрощенный)
Пример миграции:
ALTER TABLE notes ADD COLUMN tags TEXT DEFAULT '[]';Пример модели домена:
export interface Tag {
id: string;
label: string;
}
export interface Note {
id: string;
title: string;
body: string;
tags: Tag[];
}Обновление контроллера (частичное):
await noteService.addTag(noteId, { label: req.body.label });В этом и заключается преимущество режима агента: координация нескольких файлов с единым намерением.
Миграция схемы и стратегии безопасного развертывания
На старших уровнях самое сложное — это не написание SQL. Он разрабатывает трансформацию, которая:
- обратная совместимость
- обратимый
- безопасен под нагрузкой
- прозрачный для зависимых систем
Спросите второго пилота о причине:
быстрый:
Generate an additive, backward-compatible schema migration to support the tagging subsystem.
Describe the rollback plan, compatibility window, and expected impact to existing clients.Это заставляет второго пилота учитывать:
- Пн-разрушающее аддитивное поле
- Необязательные поля и обязательные поля
- Есть ли необходимость в стратегии двойного чтения или двойной записи?
- Безопасные процедуры отката
- Последствия управления версиями API
Если вы только начинаете свою карьеру, это дает урок о том, как организовать безопасную миграцию. А если у вас больше опыта, это дает вам повторяемый рабочий процесс для многоэтапной разработки схемы.
Расширенный рефакторинг с агентным рабочим процессом
Давайте проведем настоящий кросс-модульный рефакторинг: удалим проверку с контроллеров на службу домена.
быстрый:
Create a step-by-step refactor plan to extract validation logic into a domain service.
Identify affected modules and required test updates.Второй пилот может вывести что-то вроде этого:
- Представьте домен
validationService - Перенесите логику проверки с контроллера на сервис.
- Обновите контроллеры для использования новой службы.
- Обновить логику репозитория, где происходят утечки предположений проверки.
- Обновление теста домена
- Обновить интеграционный тест
выполнять поэтапно
быстрый:
Execute steps 1–3 only. Stop before controller rewrites.
Provide detailed diffs and call out risky areas.Это рефакторинг с малым радиусом взрыва, встроенный непосредственно в IDE.
Модернизация стратегии тестирования
Вместо того, чтобы просить CoPilot «написать тесты», попросите его оценить весь пакет.
быстрый:
Analyze the current test suite and identify systemic gaps.
Recommend a modernization plan including contract, integration, and domain-layer tests.Затем примените тестирование контракта:
describe("NotesRepository contract", () => {
test("create + fetch returns a fully hydrated note object", async () => {
const note = await notesRepo.create({ title: "Test", body: "…" });
const fetched = await notesRepo.get(note.id);
expect(fetched).toMatchObject({ title: "Test" });
expect(fetched.id).toBeDefined();
});
});Это превращает тестирование в архитектурную задачу.
Полный комплексный рабочий процесс
Объединив все это, вот реальная последовательность действий, которую вы можете запустить с помощью Copilot:
- Попросите Copilot проанализировать существующую архитектуру: Выявить угрозы, возможности для модульности
- Определите границы модуля: Домен, репозиторий, уровни контроллера
- Добавить подсистему тегов: От оценки архитектуры до реализации, тестирования и обновления документации
- Создайте обратно совместимую миграцию: Аддитивная схема для планирования отката
- Выполните целевой рефакторинг: извлечение слоя проверки
- Модернизируйте тесты: Контракт + Интеграция + Тестирование домена
Этот рабочий процесс архитектурно реалистичен и является моделью того, как Copilot становится помощником на системном уровне.
что такое режим агента Нет Для
Важно уточнить, что режим агента не идеален для:
- Изменение инвариантов домена без проверки человеком
- Изменение ограничений владения несколькими сервисами
- Замена логики, движимой институциональными знаниями
- Массовая перезапись сотен файлов.
- Отладка глубоких проблем во время выполнения
потребности второго пилота Помощь Принятие своего решения, а не замена его.
куда идти дальше
Именно здесь на помощь приходят GitHub Skills — не как «стартовый материал», а как набор управляемых, автономных лабораторных занятий, которые закрепляют вышеуказанные шаблоны.
Выгода будет даже для старших инженеров: эти упражнения построены таким образом, что вы сможете достоверно воссоздать сложные рабочие процессы и протестировать поведение второго пилота в контролируемой среде.
написал
