Разработчики понимают, что эффективность программного обеспечения имеет значение, но многим не хватает четкого способа обнаруживать потери, измерять улучшения и обосновывать необходимость их устранения.
Это главный вывод нового опроса 1 039 пользователей GitHub, проведенного GitHub совместно с Йельской программой коммуникации по изменению климата. Восемь из десяти респондентов заявили, что заинтересованы в инструментах, которые помогают писать более энергоэффективный код. Почти столько же выразили желание получить лучшие практические рекомендации по снижению экологического следа ПО, а около 75% хотели бы иметь способы измерения влияния своего программного обеспечения или процесса разработки.
Существует возможность превратить этот интерес в обычную инженерную работу: выявлять ненужные вычисления, предлагать изменения, тестировать их и позволять мейнтейнерам решать, что отправлять в релиз.
Разработчики заботятся об изменении климата и экологическом влиянии ИИ
В ходе опроса, проведенного среди ежемесячно активных пользователей GitHub в США, задавались вопросы об изменении климата, искусственном интеллекте, эффективности ПО и обязанностях организаций во всем технологическом секторе.
Обеспокоенность была очевидна:
- 79% заявили, что обеспокоены глобальным потеплением.
- 71% выразили обеспокоенность экологическим влиянием систем ИИ, включая потребление ими энергии и воды, а также выбросы углекислого газа.
- 75% отметили, что для них важно, чтобы их работодатель активно работал над снижением своего экологического следа.
Эти выводы описывают мнения участников опроса. Они не измеряют экологический след ИИ или какой-либо отдельной программной системы. Выборка была сформирована из пользователей GitHub, подписанных на получение маркетинговых рассылок, поэтому результаты не следует рассматривать как репрезентативные для каждого разработчика или пользователя GitHub.
Тем не менее они показывают, что многие разработчики думают об экологических последствиях систем, которые они создают и используют.
Пользователи GitHub отличаются от взрослого населения США в целом
При ответе на вопросы, которые также звучали в национальном репрезентативном исследовании Йельского университета «Изменение климата в сознании американцев» (Climate Change in the American Mind), пользователи GitHub выражали большую озабоченность изменением климата, чем взрослые жители США в целом.
Пользователи GitHub чаще заявляли, что глобальное потепление происходит (86% против 68% среди взрослых американцев), что оно лично для них имеет хотя бы некоторую важность (82% против 65%) и что оно нанесет им лично как минимум умеренный вред (68% против 45%). Они также чаще ожидали по меньшей мере умеренного вреда для будущих поколений (82% против 68%) и заявляли, что беспокоятся о глобальном потеплении (79% против 66%).
Одно примечание относительно интерпретации: данные в этом отчете основаны на нерепрезентативной выборке пользователей GitHub, подписанных на маркетинговые рассылки, поэтому результаты описывают респондентов опроса, а не разработчиков в целом, а отличия от данных по взрослому населению США отражают различия как в составе аудитории, так и в дизайне самого опроса.
Проблема не в интересе. Проблема в практическом пути к действию
Лишь 10% респондентов заявили, что их методы разработки и написания кода оказывают большое влияние на снижение их личного экологического следа. Еще 28% отметили умеренное влияние, в то время как 63% считают этот эффект незначительным.
В то же время:
- 80% проявили интерес к инструментам для написания более энергоэффективного кода.
- 78% хотели бы изучить лучшие практики по снижению экологического следа ПО.
- 74% заинтересованы в измерении экологического влияния своего ПО или процесса разработки.
- 70% выразили интерес к участию в открытых проектах, посвященных устойчивому развитию.
Разработчики просят о том же, к чему привыкли в других инженерных областях: о полезных инструментах, надежных измерениях и изменениях, которые можно подвергнуть ревью.
Открытые вопросы в анкетах продемонстрировали конкретные запросы. Респонденты просили помочь оценить след репозиториев и CI/CD-пайплайнов, обнаружить лишние запуски GitHub Actions, повысить эффективность кода и сравнить использование ИИ с другими источниками вычислительной нагрузки. Некоторые также предостерегли от заявлений об экологичности без предъявления доказательств.
Этот последний момент имеет принципиальное значение. Более быстрый код может снижать потребление ресурсов, но само по себе сокращение времени выполнения не доказывает снижения энергопотребления или выбросов. Оборудование, рабочая нагрузка, геолокация, время суток и источник электроэнергии — все это влияет на результат. Разработчикам нужны измерения, соответствующие их заявлениям.
Начните с потерь, которые вы можете увидеть и измерить
Эффективность программного обеспечения уже является частью качественной инженерии. Она позволяет снизить затраты на инфраструктуру, повысить производительность, уменьшить задержки и высвободить емкость ресурсов. Когда оптимизация сокращает объем вычислений, необходимых для достижения того же успешного результата, она также может снизить энергопотребление.
Практическая отправная точка — поиск измеримых потерь в четырех областях:
- Код: повторяющиеся вычисления, неэффективные алгоритмы, избыточные аллокации или ресурсоемкие задачи, которые можно кэшировать.
- Данные: избыточная выборка (over-фечинг), немодерируемые запросы, отсутствие кэширования или вызовы базы данных, которые следует объединять в пакеты (батчинг).
- Сеть и ввод-вывод (I/O): дублирующиеся запросы, поллинг, который можно заменить событийно-ориентированной архитектурой (event-driven), слишком большие полезные нагрузки (payloads) или отсутствие сжатия.
- Фронтенд: ненужный рендеринг, преждевременная загрузка ресурсов вне зоны видимости экрана или медиафайлы, для которых можно использовать более компактные форматы.
Выбор правильной метрики зависит от характера изменений. Время выполнения, использование процессора, выделение памяти и объем переданных по сети данных могут служить полезными прокси-показателями вычислительной нагрузки. У каждого из них есть ограничения, поэтому всегда указывайте, что именно вы измерили, а что осталось за рамками.
Например, пул-реквест, заменяющий поиск O(n²) на поиск по хэш-карте, должен содержать измерения до и после для репрезентативной рабочей нагрузки, команды, необходимые для воспроизведения теста, а также описание возможных компромиссов в памяти или поддерживаемости кода. Это более весомый инженерный аргумент, чем просто называть изменения «более экологичными» без подтверждающих данных.
Используйте агента для поиска возможностей, а не для принятия финальных решений
Поиск неэффективных мест в крупном репозитории может занимать много времени. Рабочие процессы на базе агентов GitHub (GitHub Agentic Workflows) могут помочь автоматизировать этот поиск, сохраняя полный контроль за мейнтейнерами.
Воркфлоу с открытым исходным кодом Daily Efficiency Improver анализирует репозиторий на предмет возможностей оптимизации кода, данных, сети, ввода-вывода и производительности фронтенда. Он расставляет приоритеты для изменений, которые поддаются измерению, запускает тесты репозитория и может создавать черновики пул-реквестов с доказательствами и описанием компромиссов для проверки мейнтейнерами. Он не производит слияние (merge) изменений самостоятельно.
Вы можете добавить этот рабочий процесс в репозиторий с помощью GitHub CLI:
Прежде чем включать запланированный воркфлоу, проверьте его права доступа, конфигурацию, используемую модель, предполагаемую частоту запуска и вероятные затраты на вычисления. Начните с подходящего тестового репозитория или запустите его вручную. Относитесь к каждой рекомендации как к гипотезе до тех пор, пока бенчмарки и тесты не подтвердят ее.
Самые убедительные пул-реквесты должны отвечать на пять вопросов:
- Какие потери обнаружил воркфлоу?
- Какая метрика отражает ожидаемое улучшение?
- Каким был базовый показатель (базовые данные)?
- Сохранили ли изменения функциональность и качество?
- Какие компромиссы следует учесть мейнтейнерам?
ИИ может помочь разработчикам искать, тестировать и документировать потенциальные улучшения. Люди по-прежнему принимают решения о том, являются ли доказательства надежными и стоит ли внедрять изменения в кодовую базу.
Сделайте эффективность частью инженерного цикла
Эффективную работу проще поддерживать, когда она органично вписывается в инструменты и решения, которые разработчики уже используют. Рабочий процесс на уровне репозитория может выявить проблему. Черновик запроса на слияние (pull request) может продемонстрировать предлагаемое исправление. Бенчмарки и тесты могут подтвердить его работоспособность. После этого мейнтейнеры могут принять, доработать или отклонить изменения.
Этот цикл обеспечивает разработчиков практической поддержкой, о которой просили респонденты опроса: инструментами, метриками и понятным путем от проблемы к коду.
Ознакомьтесь с полным отчетом «Software Developers on Climate Change, AI, and Sustainable Software» от GitHub и Йельской программы по коммуникациям в области изменения климата (Yale Program on Climate Change Communication). Затем запустите Daily Efficiency Improver для подходящего репозитория и изучите полученные результаты.
Автор
Узнайте больше от GitHub
Документация
Все, что нужно для освоения GitHub, в одном месте.
Перейти к документации
GitHub
Создавайте будущее на GitHub — платформе, где каждый может создать что угодно и откуда угодно.
Начать разработку
Истории клиентов
Познакомьтесь с компаниями и инженерными командами, которые создают продукты с помощью GitHub.
Узнать больше
GitHub Universe 2026
Присоединяйтесь к нам 28-29 октября в Сан-Франциско или онлайн на GitHub Universe — нашей главной конференции для разработчиков, объединяющей людей, агентов и мировой кодовый базис.
Зарегистрироваться