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