Зеленое кодирование. Qt: Что раздувает ваш код?

Зеленое кодирование. Qt: Что раздувает ваш код?

Это гостевой пост для Computer Weekly Developer Network, полностью написанный Морисом Калиновски, директором по продуктам Qt — компания известна своими кроссплатформенными приложениями и инфраструктурой пользовательского интерфейса для разработчиков, использующих C++ или QML.

Калиновский полностью пишет следующее:

Когда речь идет о выбросах углекислого газа, мы думаем о таких вещах, как ископаемое топливо, сельское хозяйство или вырубка лесов. Но думаем ли мы достаточно о том, как неэффективность нашего кода в программном обеспечении способствует выбросам углекислого газа?

Более того, понимают ли предприятия фундаментальные процессы разработки программного обеспечения, которые вообще приводят к такой неэффективности? Создание эффективного программного обеспечения и продуктов должно быть главным приоритетом, но нам может потребоваться установить обновление, чтобы «исправить» недоразумения, которые иногда возникают.

Где неэффективность?

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

Прежде всего, вам нужно спросить себя: кому код неэффективен? Если вы разрабатываете код «общего назначения», нуждаются ли входные данные в семантической проверке? Охватывает ли код все потенциальные сценарии, включая те, которые могут никогда не произойти? И т. д. и т. п. Хотя идея разделения и модульизации частей вашего программного продукта может показаться привлекательной, опасность заключается в том, что вы потеряете контекст.

Источники избытка

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

Морис Калиновски, директор по продукту Qt.

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

Рефакторинг кода полезен с точки зрения эффективности, но только до определенного момента. Обычно целью рефакторинга является улучшение определенного аспекта вашего кода, например способа его взаимодействия с другими частями вашей архитектуры. Тем не менее, не всегда на 100 процентов очевидно, как используется определенный код – особенно для фреймворков, в которых можно быстро понять, что код используется совсем не так, как предполагалось изначально. Другими словами, можно упустить из виду целостную картину.

Устойчивые языки программного обеспечения

Как показывает практика, идеального языка программирования не существует – не существует единого языка, который бы управлял ими всеми. Сказав это, потратьте достаточно времени на языки программирования, и вы быстро поймете, что «самые простые в изучении» языки могут фактически противоречить вашим целям создания эффективного и устойчивого кода.

Python является хорошим примером этого. Платой за его доступность является производительность, что, в свою очередь, приводит к потерям энергии. По совпадению, это также одна из многих причин, почему многие библиотеки Python, используемые для современных тенденций, таких как машинное обучение, используют библиотеки из других языков, таких как C++.

Согласуйте методы

Мы могли бы поговорить и о других вещах, которые способствуют неэффективности кода. Обеспечение качества также оказывает влияние. Увеличение количества проводимого тестирования программного обеспечения – особенно рост CI/CD, приводящий к тому, что целые наборы тестов тестируются по всем аспектам архитектуры программного обеспечения при каждом минутном изменении – также приводит к некоторому неправильному использованию энергии. Учитывая этот факт, как определить, какие тесты необходимо выполнить для конкретного изменения кода?

Как вы можете оптимизировать свою инфраструктуру тестирования по таким критериям, как энергопотребление, эффективность и производительность, сохраняя при этом тестовое покрытие?

Это вещи, о которых стоит подумать.

Целостный эффективный

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

Некоторые рынки уже определились с подходами, позволяющими смягчить это явление. В Германии, например, есть «Сертификат «Blauer Engel» (Голубой Ангел) – где у вас, как у поставщика, есть возможность сертифицировать свое программное обеспечение.

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

Поделиться в соцсетях