Full code verification and refactoring by pair programming with AI

I have to verify and refactor source code (every module) by pair programming with AI.

References:

  1. Unit testing system improvements: pheix-research/what-retirement-should-look-like#6 (closed)
  2. Balance module refactoring: pheix-research/what-retirement-should-look-like#5 (closed)

Approach

Prompt

слушай, я собираюсь сделать рефакторинг многомолдуьного приложения на языке Raku. У меня следующая идея - для начала пропросить ИИ сделать ревью каждого модуля на предмет багов, неточностей и так далее. Далее попросить ИИ представить допонительные unit тесты для покрытия функциональности модуля. Что скажешь?

Отличный план! Это системный подход к рефакторингу. Давайте разобьём его на конкретные шаги:

📋 План рефакторинга

  1. Анализ структуры проекта - понимаем какие модули есть и их зависимости 2. Ревью каждого модуля - ищем баги, антипаттерны, потенциальные улучшения
  2. Расширение тестового покрытия - предлагаем unit-тесты для каждой функции/метода
  3. Приоритизация - определяем порядок рефакторинга

🚀 Предлагаю начать так:

  1. Сначала исследуем весь проект - поймём масштаб
  2. Создадим список модулей для последовательного ревью
  3. Для каждого модуля:
    • Анализ кода + рекомендации по улучшению
    • Предложение дополнительных тестов
    • Отчёт с приоритетами изменений

● Searched for 4 patterns, read 2 files (ctrl+o to expand)

Я уже начал анализ вашего проекта. Текущая структура проекта:
Модули (2):

  • WRSLL::Balance — работа с балансами Ethereum
  • WRSLL::Notify — уведомления через Matrix

Исполняемые скрипты (4):

  • bin/crawler.raku
  • bin/grinder.raku
  • bin/addr-matcher.raku
  • bin/trx-sender.raku

Тесты (8 файлов): t/01.t — t/08.t

Предлагаемый процесс

  1. Ревью каждого модуля — анализ на:
    • Потенциальные баги и уязвимости
    • Нарушения best practices Raku
    • Проблемы с производительностью
    • Стилистические issues
    • Возможности для улучшения архитектуры
  2. Дополнение unit-тестов — создание тестов для:
    • Покрытия существующей функциональности
    • Краевых случаев и обработки ошибок
    • Интеграционных сценариев
    • Mock-объектов для изоляции
  3. Анализ скриптов — после модулей

 TBD 

Edited by Konstantin Narkhov