Comments 15
Я за такие коммиты линейкой по пальцам бью. Нахуа выносить три строчки в отдельный метод, если он нигде не переиспользуется??? Если «трудно читать» — так отдели его комментарием от окружающего кода, для визуальной группировки строчек. Но зачем, сцуко, стек без нужды дёргать, новую область видимости заводить, убеждаться, что все требуемые переменные в неё попадают...
А потом получается 1 сайт - 1 компонент, или 1 бекенд - 1 функция 😁
Я понимаю что Single Responsibility Principle - это что то незнакомое, но god component - это тот еще треш
в одной известной рф компании от меня требовали выносить такие куски кода отдельно для того, чтобы потом проще было писать тесты. Правда такие методы были public или protected, а не private.
от меня требовали выносить такие куски кода отдельно
...а потом передаёшь в такой кусок г...ода восемь параметров и вспоминаешь предков такого требователя тихим незлобным словом.
Как выделение метода соотноситься с 8-ю параметрами ? Может всё таки почитаете книгу М. Фаулера "Рефакторинг. Улучшение существующего кода" ?
Как выделение метода соотноситься с 8-ю параметрами?
Так, что «код, который надо выделить в отдельный метод» использует (в данном примере) 8 разных переменных. Пока он был внутри другого метода — они были для него локальными. А как его выделили в отдельный метод — облом, бабуля, они больше не локальные.
Во-первых, в примерах нет локального метода (мне неизвестно о наличии локальных методов в Java), во-вторых, Вы говорите о преобразовании локального метода в приватный - это вообще другое. Здесь пример выделение фрагмента большого метода в маленький, в-третьих, если локальный метод использует аж 8 переменных - это точно жадная функция и признак плохого дизайна. Еще раз рекомендую прочитать М. Фаулера.
Больше, чем Фаулер, вреда индустрии нанес только Боб Мартин.
Рекомендация их почитать — это как совет потренировать навыки вождения перед экзаменом на права — в компьютерной игре. В реальном мире ни то, ни другое, — не работает вовсе.
выносить такие куски кода отдельно для того, чтобы потом проще было писать тесты
*ненужные тесты
Если «трудно читать» — так отдели его комментарием
Главный признак необходимость выделить в отдельный метод
Но зачем, сцуко, стек без нужды дёргать,
Преждевременная оптимизация до добра не доводит. Оставьте микрооптимизацию JIT-компилатору - он это сделает лучше Вас, сосредоточьтесь на создании простого кода - сложный получиться сам собой.
хороший анализ, спасибо, было бы любопытно увидеть похожий анализ не только по Java, но и по другим языкам
Оригинальная статья странная, и кажется её целью не было нормально что-то поисследовать.
Выборка:
Table 2. Distribution of commits and PRs by associated AI agent.
OpenAI Codex ... 89% commits
Я пытался понять, что такое RefactorMiner, и как они его использовали для категоризации коммитов. Но кажется всё прозаичнее:
4.3. RQ3: What is the purpose of agentic refactoring?
4.3.2. Approach
... The classification uses the Pull Request title, commit message, and detected refactoring types as input. Due to the large sample size of the collected Agentic Refactoring commits, we leverage GPT-4.1-mini to automatically categorize each commit.
В целом складывается ощущение что в оригинале просто льют воды (что в целом случается), однако забавно, что в наблюдениях (по ходу статьи) приведены в основном недостатки ЛЛМ агентов, а в итоговых выводах как бы между строк говорится о том, что ЛЛМ агенты уже во всю рефакторят код, и что пора бы всем их начинать использовать.
Ещё к сожалению, данная статья (перевод, не оригинал) теряет много деталей. Перевод (эта статья):
Доверяйте агенту, чтобы справиться с рутиной. Такой рефакторинг уже полезен с точки зрения типовых исправлений, выравнивания стиля, декомпозиции и сокращения времени на код-ревью.
Оригинал
Implications for Developers
<...> Developers can delegate routine cleanup to agents and focus human effort on design-level restructuring that requires domain knowledge and architectural intent. Given that many refactoring instances (53.9%) occur implicitly within non-refactoring commits (Section 4.1), developers must remain vigilant during code review to validate these tangled changes.
Для сравнения, "доверяйте агенту" против "разработчики имеют возможность делегировать ..., но даже в этом случае нужно быть на чеку ..."
Дальше разбирать лень, в оригинале ещё несколько интересных наблюдений сделано (можно погрепать по "finding"). Если коротко, ЛЛМ агенты хороши, если вам надо повысить метрики по перекладыванию кирпичей из одной кучи в другую.
Быстро по тезисам из этой статьи тогда, раз уж такое дело
Рефакторинг <...> улучшает читаемость и сопровождение системы
Тогда и только тогда когда это не бессмысленный рефакторинг дробления функций на более мелкие и потом сбор их них больших функций.
LLM-агенты дополнительно позволяют автоматизировать рефакторинг кода,
Кажется, не позволяют, и к этому выводу приходят в оригинальной статье
[по сравнению с человеком,] агент скорее занимается «повседневным уходом» за кодовой базой и реже трогает архитектуру системы.
Кажется даже очевидно почему — я уверен, в выборке для обучения просто огромное количество ответов со stackoverflow о том, как из одной большой функции сделать 2 поменьше. И там же на стаковерфлоу примерно 0 ответов о том, как дизайнить архитектуру приложения (что логично).
Как часто и как выглядит рефакторинг у агентов
Это довольно распространенная практика: 26.1% Java-коммитов явно посвящены рефакторингу и демонстрируют больше рефакторинговых операций за счёт того, что они сконцентрированы в одном месте. То есть это не побочный эффект других правок, а именно продуманная задача (часто в отдельном PR).
Несколько раз перечитывал и не понял, что имеется в виду.
_
P.S. у ЛЛМ ботов нет "сознания", L в LLM значит "Language", то есть они буквально перемешивают тонны текста и выдают результаты основываясь на статистических данных. Как уже выше было сказано, объём данных с ответом на вопрос "как вычленить две функции из одной" гораздо выше чем "как спроектировать приложение Х". Вот в целом и всё. Для качественного прыжка необходим другой подход, какая-то новая архитектура модели машинного обучения, или что-то ещё, — кто знает. Пока LLM упираются в стену при недостатке данных для обучения, а также ломаются при наличии небольшого объёма "плохих" (aka poisoned) данных.
Как ИИ-агенты научились рефакторить код: что получается хорошо, а что не очень