Критерии оценки качества рефакторинга

где взять эти критерии? как их сочинить?

Манагер что-ли?
Кода стало меньше, работать/собираться стало быстрее, код стал понятнее, функционала получилось столько же или больше, разработка шла быстрее.

мб какое-нибудь среднее время исправления бага?

Вот. Еще и баги правятся быстрее.

спасибо

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

оценить качества рефакторинга кода код на Java Boot Spring

переписать на нормальный язык?

где взять эти критерии? как их сочинить?

Никто не делает рефакторинг ради рефакторинга - работает, не трожь. Есть же причины по которым надо код переписать?

Достижение (или не достижение) результата и есть оценка качества.

Никто не делает рефакторинг ради рефакторинга

Еще как делают. Понапишут дерьма - фреймворк плохой, переписывают. Опять получается дерьмо. Значит опять фреймворк плохой. Переписывают. Язык плохой. Пишут сначала на одном, потом на другом. Реальная история.

Реальная история.

Ты так говоришь как будто эта история какая-то плохая. Это нормальная история. Редко когда удаётся сразу подобрать всё сразу как надо. В процессе написания вылезают неочевидные но серьёзные нюансы.

Ни по каким, разумеется. Качество кода объективными критериями не оценивается. Если ввести какие-то критерии, программисты немедленно найдут как их обойти.

смотря что понимается под качеством и собственно критериями

А чего сразу раст?

нет никаких критериев. рефакторинг не делается только для самого факта. Рефакторинг делается для того что бы решить какую-то проблему. Если проблемы нет, то и рефакторить не надо. А если есть и решились отрефакторить код то единственным обьективным критерием есть решилась ли проблема посля рефакторинга и не появилось ли новых… Когда дядька Боб говорит «делайте рефакторинг как можно чаще» он имеет в виду «решайте архитектурные проблема софта не костылями а рефакторингом»

Считаешь метрику «WTF per minute» для нового разработчика, который пытается самостоятельно разобраться в проекте. До и после рефакторинга.

Рефакторинг это не про изменение внешнего вида без изменения логики? Иначе это переписать.

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

Ты так говоришь как будто эта история какая-то плохая

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

Рефакторинг это про код без изменения бизнес-логики и внешних интерфейсов. С изменением - это уже не рефакторинг, а разработка по новой.
Например, я переписал начисление с жабки на ноду - это рефакторинг, т.к. делает всё тоже самое, никто ничего не переписывал, никто ничего не заметил, кроме того, что считает город 30 мин, а не 6 часов, жрёт 2 гб, а не 22, работает на 2-х ядрах, а не на 48.
Пацаны сделали пистон 3 после пистона 2 - это новый проект. Хотя вроде тот же язык, тот же пистон, но есть нюанс.

На джавах не пишу (вселенная миловала), но для себя вывел такие правила

• Уменьшение количества связности между системами модулей (полезно визуальную картинку нарисовать, обычно сразу видно где что не так)

• если в модуле реквайрится больше ~10 других , то либо это центральный модуль (и он может быть такой единственный в сервисе), либо знак того, что пора задуматься, очень вероятно, что что-то не так с архитектурой

• для всяких utils/* даже 10 это уже много, модулю для работы с json ни к чему знать про структуру этого json-а, это уже бизнес-домен

• Вынос повторяющегося кода (тут главное не переборщить в ущерб читабельности), есть специальные инструменты для поиска похожих кусков кода.

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

Ну не осилили пацаны, что главное - интерфейсы взаимодействия, а язык с фреймворками - это вторичный кал.

Тут дело в том, что язык может очень сильно облегчить (или наоборот, усложнить) работу с этими интерфейсами

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

сначала надо с литературой ознакомиться - https://github.com/miloyip/game-programmer
параграф 3, левая ветка :-)

Подскажите, а чем этот граф построить, может это в Idea встроено, или сторонее средство?

Для сишки есть cflow, вывод которого можно анализировать простенькими сценариями, для питона можно глянуть pydeps и pycallgraph и pyan, но тут главное правильные критерии качества графа подобрать(т.к. рост числа рёбер таких графов происходит и при разрастании возможностей, а не только при увеличении сложности кода), для других языков придётся поискать или даже руками писать. Ещё знаю, что граф Си/Си++ умеет строить Visual Studio, но там на выходе нужно если правильно помню xml разбирать.

В книге Мартина Фаулера «Рефакторинг» есть критерии. В интернете можно найти статьи, написанные на основе книги:

• Статья Википедии
• Статья на Хабре

Дублирование кода.
Длинный метод.
Большой класс.
Длинный список параметров.
Расходящиеся модификации.
Стрельба дробью.
Завистливые функции.
Группы данных.
Одержимость элементарными типами.
Операторы типа switch.
Параллельные иерархии наследования.
Дублированный код.
Ленивый класс.
...

Спасибо за интересный ответ!

техдолг по определению является проблемой. Потому что термин техдолг означает «окостыливание реальной проблемы, вместо ее решения». Другое дело если «техдолг» стал нормальным продакшн кодом который просто работает, то зачем его переделывать?

Есть много готовых инструментов которые делают подобную аналитику. Тот же SonarQube.

Его можно встроить в IDE, чтобы помогал при разработке. Можно в code review.

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

спасибо

Это нереально. От балды можно что угодно нарисовать, какие угодно графико построить, вручную, автоматически, полуавтоматически, но качество кода ты оценить не сможешь. Хороший код есть, но проблема оценки заключается в том, что нужно оценить простоту чтения и модификации, которые субъективны, хотя и есть некоторые объективные факторы. Грубо говоря, это как оценить «красивее картина стала или нет» — кому-то и «подристать на холст» будет красотой. Собственно, эдак половине «подристать на холст» — это искуство, а нарисовать квадратов с треугольниками — наука.

Для условно объективной оценки в идеале нужно взять сотню программистов, дать им разные задачи на модификацию кода, и посмотреть, как они справятся с этими задачами — ближе всего к этому ответу подошел Legioneer: Критерии оценки качества рефакторинга (комментарий)

Но проблема в том, что никто не может позволить себе бросить кучу ресурсов вникуда. А если испытуемые будут писать код, который пойдет в прод, то проблема будет в том, что каждый раз при оценке вы будете отставать на одну итерацию, то есть, вы оценили старый код, но это не тот код, который сейчас в проде. И так каждый раз оцениваете вы задним числом, как тёща. Даже если использовать эту оценку для того, чтобы отобрать говнокодеров от способных прогарммистов — а что если говнокодеры уже «научились»?