Комментарии 6
Здравствуйте!
К сожалению, на больших проектах я пока что могу запускать только статический анализ. Потому что для запуска динамического пока нужно прописать во всех файлах проекта импорты и еще с зависимостями разобраться (это одна из его проблем).
Но на результат работы статического анализа на JUnit-е (конкретнее - https://search.maven.org/search?q=g:junit%20AND%20a:junit) можно посмотреть тут: https://docs.google.com/document/d/1E-IMuTFUjG2PTOiVe2M3nq_fGeIU65BmD2go6WuesQU/edit?usp=sharing
Или я что-то пропустил в российском образовании, или девушка, сделавшая на втором курсе такой проект - вундеркинд.
Мой респект.
Здравствуйте!
Благодарю за критику.
Постараюсь прокомментировать каждое из данных замечаний.
Насчёт измерителей покрытия - я постаралась найти какие-то аналоги, которые хотя бы отдалённо решают мою задачу. Конкретно измерители покрытия могут предоставить информацию о том, какие методы при прогоне тестов вызывались чаще (ну или сколько раз тот или иной метод вызвался, суть та же). Вы правы в том, что результат оценки будет зависеть от "добросовестности программиста". Но если считать, что проект и тесты к нему адекватные и написаны качественно, то, кажется, такой подход все же имеет право на существование.
Следующее замечание было про моё понимание важности.
Здесь Вы тоже правы, но дело в том, что на самом деле так и планировалось. В данном проекте более важными считались наиболее часто вызываемые части кода (в том числе базовые классы и т. п.) Такая задача была передо мной поставлена и такую задачу я решала. И мне это кажется довольно логичным. Например, ошибки в часто вызываемых фрагментах кода пагубно влияют на довольно большие части проекта и являются критичными. Поэтому от них следует избавляться (или как-то их обрабатывать) в первую очередь. На решение таких ситуаций и нацелен проект.
И сейчас я с ходу не могу придумать, как учитывать редко используемые, но при этом важные части кода со сложной логикой, кроме как с помощью экспертной оценки. Или, как мне подсказали, можно ранжировать код по его сложности и наполненности, но это уже совсем другая задача.Насчёт метрик, так уж сложилось, что я воспринимаю это слово более общо, потому что часто слышу его в разных подобных моему контекстах. Поэтому под словосочетанием "метрика ранжирования" подразумевалось скорее "критерий (количественный), по которому будет происходить ранжирование". Но наверное это правда не очень корректно, спасибо за замечание.
И последнее, про Pagerank.
Я не совсем поняла, в чем именно с Вашей точки зрения заключается его недостаток, если считать, что нас устраивает ранжирование, при котором "базовые классы и т.п." являются наиболее важными (причину такого подхода объяснила выше при ответе на первое замечание).
Но если действительно есть какие-то алгоритмы, которые были бы более уместны в случае почти DAG-ов, я была бы рада о них узнать.
Работа с ASM была нетривиальной, потому что эта библиотека основана на паттерне, который называется визитор.
Плагин для ранжирования кода по важности или как я пыталась облегчить жизнь программистам