#clojure #metrics
#clojure #показатели
Вопрос:
Мы рассматриваем возможность написания статического анализатора для сбора программных показателей для кода Clojure. Конечно, он будет обрабатывать очевидные вещи, такие как количество файлов, функций, параметров для каждой функции и т.д. Интересно, существуют ли какие-либо показатели, специфичные для кода Clojure. Есть идеи?
Ответ №1:
В среднем — я думаю, что программные показатели — сомнительная идея — они обычно отвлекают вас от действительно важного вопроса, который заключается в том, «какую ценность мы предоставляем клиенту ??».
Сказав это, я признаю, что они могут быть необходимым злом в некоторых контекстах и иногда могут дать вам некоторые полезные сведения о вашей кодовой базе.
Итак, вот несколько, которые могут быть специфичны для Clojure.
- Количество определений верхнего уровня (возможно, выраженное как отношение к общему количеству символов?)
- Связь Java: % символов, связанных с взаимодействием Java (new, className., .someMethod и т.д.) — В идеале связь должна ограничиваться конкретными модулями, ответственными за взаимодействие Java, т. е. должна составлять очень низкий% везде, кроме библиотек, которые управляют взаимодействием.
- Средний максимальный уровень вложенности определяемых функций (я думаю, 5ish хорошо, 10 плохо ??)
- Плотность макросов: % форм, требующих расширения макросов
- % функций со строками документации
- % символов или параметров функции, определенных с помощью подсказок типа
- Средний размер анонимных функций (вероятно, они должны быть небольшими!)
- процент используемых функций в clojure.core (дает некоторое представление о «диапазоне словарного запаса» и сложности кода)
- (Спасибо, никик!) количество созданных типов ссылок (динамические переменные, atom, ref и agent) — важно, если вы хотите тщательно контролировать свое изменяемое состояние!
p.s. если у вас это получится, было бы действительно интересно увидеть различия в результатах в некоторых проектах clojure с открытым исходным кодом!
Комментарии:
1. Я понимаю настрой против метрик. Я думаю, что показатели полезны только для увеличения проблемных областей. Кстати, хороший ответ.
2. Подсчет ссылочных типов действительно невозможен. Подсчет ссылок / атомов / агентов и динамических переменных (в 1.3).
3. @nickik — полностью согласен, что типы ссылок очень важны. хотя сложно определить, какую метрику вы бы использовали в статическом анализаторе? Проблема, которую я предвижу, заключается в том, что они часто распределяются динамически, поэтому необязательно просто подсчитывать символы ref / atom / agent, например ….. в любом случае, они добавлены в список
4. Я думаю, что делать это статически так же хорошо, как отслеживать количество реальных объектов. Если вы создаете атомы только в одном месте, сложность, вероятно, будет одинаково ограниченной: даже если эта функция вызывается тысячу раз, на самом деле она не более сложная.