Сперва хотелось бы ещё раз уточнить, что на момент инициирования разработки какого-либо плана не существовало вовсе, а её автор (точнее сказать, оформитель сгенерированных текстов) не обладает достаточной компетенцией в каком-либо из языков программирования (опытным пользователям стоит обратить своё внимание на проект Bashly). Мотивом же написания данной статьи послужило желание уточнить у профессионального сообщества актуальность данного подхода, поэтому не судите строго.

Итак, удалось организовать два проекта, которые в дальнейшем возможно объединить, упростить или полностью адаптировать под свои задачи. Результатом первого проекта («Bash Script Template Framework») является шаблон модульного скрипта, скорее по своей функциональности напоминающий скрипт инициализации. Результатом второго проекта («Projects Management System») является система версионирования с возможностью расширения. Bash как язык проектов оформился в процессе, когда языковая модель предложила изменить shebang на Bash с указанием версии 4+, но для лучшей «портабельности» хотелось бы их сделать POSIX-совместимыми.

Структура первого проекта разбита на директории, в которых содержатся исходники для сборки финального скрипта-шаблона. Код в исходниках по своей сути — комментарии, которые после сборки должны автоматически выноситься в готовую документацию в виде README.md. Для этой цели предусмотрен скрипт md-generator, и можно ознакомиться с примером его работы. Структура также подразумевает, что по названию папок должно быть предельно ясно, какие части результирующего шаблона они содержат. Правда, название sections немного не соответствует первоначальной идее: в ней содержатся файлы Bash-команд, которые должны исполниться сразу после запуска, то есть без «subshell»-а. Сборка происходит, начиная с папки «head», которая содержит shebang и шапку будущего шаблона, после чего подтягиваются протестированные «части» из папок sections и functions.

Папка functions содержит файлы с функциями (каждой функции также соответствует отдельный файл), например, «usage» — содержит заготовку обработчика аргументов, «trap_exit» — обрабатывает выход и так далее. Стоит отметить, что «trap_error» нуждается в доработке: она содержит советы от ИИ, как реализовать, но есть и дилемма — debug не рекомендуется использовать в prod-ready-реализациях. Требует комментариев и весь процесс логирования в шаблоне. Так как скрипт теоретически, а как оказалось, и практически, может «упасть» до его полной инициализации (до вызова «new_function»), то логирование реализовано следующим образом: сперва все ошибки выводятся только в терминал, затем — в crashlog (до тех пор, пока не будет установлен флаг LOG_FILE_INIT_STATUS), и далее, во время нормальной работы, вся информация записывается в обычный лог.

По окончании инициализации скрипт производит поиск файла .env; предусмотрена логика, что он может быть опциональным. В данном файле на сейчас реализована только опция DRY_RUN, которая запланирована для использования во всех далее импортируемых функциях, но может быть также передана в качестве параметра запускаемым из шаблона скриптам. Следует отметить, что наследование значений данной опции в процессе инициализации шаблона требует коррекции, так как опция DRY_RUN может повлиять на поведение собственных «внутренних» функций в процессе инициализации.

В результате выполнения готового шаблона выполняется функция под названием «new_function», собственно, ради которой и весь «огород». Данная функция-«заглушка» предусмотрена для использования в качестве шаблона для расширения функциональности шаблона с переиспользованием всей вышеперечисленной функциональности. Для автоматизации сборки шаблона скрипта предусмотрены Makefile-ы, а для тестирования присутствуют генераторы тестов на базе Bats-core; об этом в исходниках содержатся исчерпывающие комментарии, так что не стоит на этом подробно останавливаться. Лучше более детально рассмотреть процесс разработки как таковой.

Для того чтобы сгенерировать данный шаблон, был использован query_generator; он расположен в папке code_review — на весь проект возможно использование нескольких таких директорий и генераторов. Сам query_generator является основой для документирования и процесса разработки. Основная идея которого заключается в генерации запроса (prompt-а) для языковой модели на основе файлов проекта, внесении изменений в файлы проекта, тестировании и повторении цикла. Для глубокой проработки при помощи LLM любого из компонентов проекта возможно использование файла отладчика (debugger), смысл которого подобен генератору, но больше заточен для запуска скриптов, как это реализуется командой make.

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

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

Благодарю за внимание. Комментарии, советы и участие приветствуются. Исходные тексты здесь:

• Bash Script Template Framework

• Projects Management System