Заметки программиста

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

В этом посте я, как и обещал, расскажу о метриках кода, представленных в правой части мониторинговой панели — это показатель спутанности пакетов ( package tangle index ), недостаток связности в методах ( LCOM4 ) и отклик для класса ( response for class ). Показатель спутанности пакетов Эта метрика учитывает циклические зависимости между пакетами. Это отношение между количеством циклических зависимостей и общим числом зависимостей. Понятное дело, что чем ближе этот показатель к 0, тем лучше. Чтобы увидеть циклические зависимости, щелкайте по значению показателя или выбирайте в левом меню пункт “Design”. Вот легенда к матрице, которую вы увидите Недостаток связности в методах Класс, как мы помним, состоит из полей и методов. В каждом из методов используется некий набор полей и/или вызываются другие методы. Методы связаны между собой, если один из них вызывается из другого, или они используют одно и то же поле класса. LCOM4 определяется количеством груп связанных методов в классе. Если L

Прошлый раз я забыл написать, что после старта платформы нужно зайти в браузер по адресу http://localhost:9000 (если, конечно, вы не разворачивали на своем JEE сервере с собственными настройками). Но вы все равно бы ничего интересного там не увидели. Ведь надо каким-то образом познакомить Sonar с кодом вашего проекта. В веб-интерфейсе этого не сделать (поверьте, я потратил некоторое время в поиске такой возможности — сэкономил на чтении документации :)). Для этого нам понадобится maven. Для начала надо поместить свой артефакт в локальный репозиторий maven. В переменную окружения MAVEN_OPTS записываем что-то вроде    -Xmx512m -XX:MaxPermSize=128m Можно и больше выделить памяти, если есть возможность. Потом даем команду    mvn sonar:sonar , если вы все еще используете версию 2.x или    mvn org.codehaus.sonar:sonar-maven3-plugin:2.13:sonar , если вы перешли на версию 3.x. После заветного “BUILD SUCCESSFUL” можно идти в браузер и обновлять страничку Sonar'а. Там вы увидите саму

После продолжительного затишья попробую возобновить свою блоггерскую деятельность. Так сложилось, что последнее время я оказываюсь в роли борца за качество кода. С одной стороны — заказчик, у которого сроки поджимают, а с другой — программист, следующий правилу: “Работает — не трогай!”. Кодовая база растет, в программе появляется новый функционал и вместе с тем накапливается технический долг, сказывающийся на стоимости сопровождения приложения и скорости добавления новых “плюшек”. До определенного времени мало кто обращает внимание на качество кода, считая его вполне приемлемым. Да, иногда вспоминаем про рефакторинг, что-то переделываем сразу, а, бывает, прикинув необходимые на его проведение временные затраты, откладываем в бэклог до лучших времен. Поди улови тот момент, когда качество было приемлемое, и “вдруг” оказалось никудышным. Значит, необходимо отслеживать качество кода. При этом желательно автоматизировать этот процесс. А так как потребность назрела давно, были разработаны н