Возвращение аспектно-ориентированного программирования

Привет, Хаброжители!

Только подумайте, сколько всего программисту необходимо учитывать при написании кода:

1) Корректность: обеспечение того, чтобы программа работала правильно, удовлетворяла всем требованиям, соблюдала все важные инварианты, реализовывала бизнес-логику должным образом и т. д.

2) Эффективность: программа должна потреблять минимум времени, памяти ^[1] и ресурсов. Это включает в себя отказ от удержания памяти дольше, чем это необходимо, а также, по возможности, отказ от освобождения использованной памяти в фрагментированном состоянии. Некоторые программы имеют «ограничения реального времени», при которых определенные цели эффективности, такие как возвращение ответа пользователю в течение 0,2 секунды, считаются частью их корректности

3) Возможность отладки: когда в программе возникают проблемы, должна быть возможность относительно легко выяснить, в чём они заключаются и как их устранить.

4) Сопровождаемость. Программа должна быть хорошо документирована и легко читаема. Она должна быть написана в едином внутренне согласованном стиле, который также должен соответствовать стилю внешней кодовой базы, частью которой она является.

5) Тестируемость. Программа должна быть написана таким образом, чтобы модульные и интеграционные тесты были полезными и при этом не слишком сложными для создания.

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

7) Безопасность.  Программа должна позволять пользователю выполнять только разрешённые действия; как правило, это действия, которые пользователь мог бы выполнять и без программы, а также, возможно, небольшой набор явно определённых действий, право на выполнение которых предоставляется пользователю в виде доступа к запуску программы.

8) Расширяемость: в программу должно быть относительно легко внести небольшое количество незначительных изменений.

9) Конфиденциальность. Программа не должна раскрывать данные об одном пользователе каким-либо другим лицам – в том числе, возможно, владельцам самой программы – за исключением случаев, когда это явно требуется.

10) Управление зависимостями. Большинство программ используют код, написанный другими людьми и организациями, часто в виде библиотек. Программист должен убедиться, что использование этих библиотек является законным, то есть не нарушает никаких условий лицензии, по которой распространяется внешний код, и что все библиотеки в совокупности являются перекрестно совместимыми. То есть если библиотека A использует библиотеку C версии 1, а библиотека B – библиотеку C версии 2, то либо система программирования должна поддерживать такую комбинацию, что в большинстве случаев не так, либо эту ситуацию необходимо урегулировать. Программист также должен убедиться, что ни одна из используемых библиотек не нарушает какие-либо другие соображения из данного списка.

11) Развертывание.  Многие программы запускаются не на том компьютере, на котором их написал программист.  Обычно это требует от программиста определённых действий: либо программа должна распознавать среду, в которой она запущена, и адаптироваться к ней, либо её необходимо поместить в контейнер, чтобы обеспечить запуск в стандартной среде, которую можно воспроизвести в любом месте, либо же нужно написать отдельную программу для преобразования исходной программы под новую среду.

12) Мониторинг/наблюдаемость.  Не для каждой программы это имеет значение, но для длительно работающих программ будет полезно, чтобы информация, описанная в логировании, была доступна в режиме реального времени через отдельный интерфейс.

13) Устойчивость.  Не для каждой программы это имеет значение, но длительно работающие программы часто приходится останавливать и перезапускать, и почти во всех системах программирования перезапуск требует от программиста дополнительных усилий.

14) Проверка входных данных.  Не все программы принимают входные данные, но большинство из них это делает, и в таких случаях им, как правило, необходимо выполнять проверки, чтобы убедиться, что входные данные соответствуют ожидаемому или требуемому формату и/или могут быть преобразованы в этот формат.

15) Обработка ошибок: когда возникают проблемы, программа должна плавно переходить в режим ограниченной работоспособности, логируя ошибку ^[2], оповещая соответствующих пользователей и возвращая программу в приемлемое состояние.

16) Интернационализация и локализация.  Не каждая программа должна учитывать возможность работы в нескольких странах или взаимодействия с пользователями на нескольких языках, но многие из них это делают.

17) Доступность.  Опять же, не каждая программа должна уделять этому внимание ^[3], но многим всё же необходимо обеспечить удобство использования для людей с различными физическими или когнитивными особенностями, причём сделать это изящно.

Я мог бы продолжить этот список, но, думаю, уже ясно, что подобных аспектов очень много. И это даже не включает задачи, которые программисту приходится выполнять вне процесса написания кода (например, оценивать сроки выполнения работы или взаимодействовать с коллегами). Аспектно-ориентированное программирование ^[4] (АОП) – идея, предложенная Грегором Кичалесом ^[5] и другими исследователями из Xerox PARC в середине 1990-х годов. Она заключается в том, что программирование могло бы стать проще, если бы разработчик мог сосредотачиваться на каждом из этих аспектов по отдельности, а не пытался учитывать их все одновременно практически в каждой строке кода.

Мне всегда нравилась эта идея, но я также всегда ненавидел конкретный механизм, который АОП выбрал для её реализации – нечто, называемое «моделью точек соединения» ^[6], которая, по сути, сводится к сопоставлению шаблонов во время выполнения на стеке вызовов программы и запуску некоторого кода каждый раз, когда шаблон совпадает.  Например, каждый раз, когда в стеке вызовов в качестве последнего элемента, добавленного в стек, находится процедура открытия файла, программа может логировать имя файла, который собирается открыть. Как отмечается на странице Википедии, посвящённой АОП, это очень похоже на оператор «COME FROM» ^[7], который был предложен в шутку, и который так же сложен в отладке и сопровождении.

Но благодаря новым возможностям LLM в области программирования я считаю, что АОП заслуживает другого взгляда. В своей новой форме программисту нужно лишь создавать отдельные документы для каждой области. Разумеется, эти документы будут очень разного объема, причем документ, посвящённый корректности, как правило, будет самым объёмным.  Многие из этих документов можно повторно использовать и совместно применять в разных проектах; например, руководство по стилю организации можно использовать для решения задачи поддерживаемости. А «плетельщик» (используя терминологию АОП) – это просто LLM, который генерирует программу на основе этих документов.

Почему этот вариант лучше, чем старая модель точек соединения АОП?  Дело в том, что та модель была неустойчивой: чтобы вести логи после каждого открытия файла, требовалось сопоставлять функции открытия файлов с конкретной строкой-именем или набором имен.  И если бы коллега добавил новую функцию открытия файла (или, что ещё хуже, переименовал существующую), это не было бы зафиксировано в логе.  Здесь, когда соединение осуществляет LLM, мы полагаемся на его фоновые знания о том, что представляет собой открытие файла, для выполнения сопоставления.

Еще одним преимуществом LLM является то, что результат их соединения является статическим (то есть не вычисляется во время выполнения программы) и удобочитаемым. Существуют некоторые реализации АОП, которые выполняют «соединение на этапе компиляции», например ajc от AspectJ, но они выдают такие данные, как не совсем удобочитаемый необработанный байт-код Java.

К тому же это несколько несправедливое сравнение, учитывая, что LLM будут использоваться для генерации кода независимо от того, поддерживают они АОП или нет. Я просто хочу сказать, что концепция «забот» АОП даёт нам полезный способ структурировать предложения, которые мы подаём в LLM. (Или в несколько LLM; можно также подавать описание каждой «заботы» в отдельный агент, задача которого анализировать код с этой точки зрения ^[8].)