Comments 20
Google error-prone еще
Спасибо за статью. Подпишусь под каждым словом. Добавлю, что SonarQube особенно хорош для больших гетерогенных проектов, например BE (Java), Android приложение (Kotlin), iOS (ObjC/Swift).
Этот человек несёт персональную ответственность за технические решения, принимаемые на проекте, а также следит за качеством кода.Что означает эта ответственность? Вы его уволить в случае чего захотите (или того, кто его нанял на эту позицию), или побить захотите, чтобы он все выходные проверял чьё-то качество кода?
Нет, без рукоприкладства, конечно)
На проекте должен быть кто-то, кто принимает технические решения. Такой человек должен быть один, иначе будет коллективная безответственность. Этот человек разруливает спорные/конфликтные ситуации по технической части. Например, один разработчик хочет Кафку для нового проекта, а другой - RabbitMQ. И они никак не могут договориться. Архитектор должен сделать выбор. Он не должен идти на компромиссы и стараться угодить всем. Он может выбрать, например, Pulsar)
Эта ответственность чаще всего зашивается в KPI и премиальную часть.
Если такой человек раз за разом принимает неудачные решения, то однозначно, что роль архитектора не для него. Вовсе не обязательно его за это увольнять (если это не был специально нанятый архитектор в команду).
а большинство людей негативно воспринимает нововведения; особенно те, которые их как-то ограничивают
Может быть мне так везло, но я в разработке встречал в основном адекватных людей, вполне понимающих для чего и зачем нужен сабж.
В нашем энтерпрайзе мы использовали как обязательные (по требованию отдела безопасности) - Fortify, Checkmarx, Black Duck, а вот Sonar использовался только как добровольная дополнительная проверка на уровне проекта.
Из свежих и интересных ещё стоит упомянуть Qodana от Jetbrains.
Для меня киллер-фичей стала проверка на совместимость лицензий зависимостей, используемых на проекте, с заданными политиками. Также умеет агрегировать репорты от других анализаторов.
У sonar'a есть хорошая интеграция с битбакетом - где он подтягивает информацию о покрытии кода для PR, помечая цветом с боку о покрытии или нет. Удобно для ревьюрера.
Я не знаю, в чем отличие наших проектов от проектов автора, или в чем отличие команды, но наверное оно есть. Может быть, проекты в основном интеграционные, или просто нестандартные, может быть квалификация команды влияет (ну то есть, влияет скорее всего — скажем, синьоры не склонны делать «детские» типовые ошибки, а именно эти ошибки как раз хорошо ловятся линтерами).
Упомянутый тут Checkmarx, скажем, дает одни ложные срабатывания, просто без исключений.
Встречался с сообщениями от него и они все были по месту.
Хотя местами их и приходилось выключать:
то из-за того что эта ошибка в тестовом коде и нам тут проще знать что она возможна чем чинить её
то из-за того что это редкий
false positive, но там реально сложно понять что в нашем случае проблему эксплуатировать не получится
Ну для меня вот это
Упомянутый тут Checkmarx, скажем, дает одни ложные срабатывания, просто без исключений.
это совсем не
Ну так я и не говорю, что оно совсем не работает.
Потому я и добавил описание свого кейса, в котором Checkmarx не давал много срабатываний, а те что были - оказались в основном адекватными, хотя несколько мы исправлять не стали.
ИМХО обычный code coverage(например JaCoCo) не очень полезен, так как line coverage можно набить и тестами, которые будут просто запускать код, но не выполнять ни единой проверки. Предпочитаю вместо этого использовать mutation testing, например https://pitest.org/
Мне кажется, вы сильно утрируете. Обычный code coverage прекрасно решает свою задачу. На code review будет видно, что проверки в тестах бесполезны, и задача вернётся на доработку.
Мутационное тестирование - очень интересная вещь, но не для всех, я бы сказал. Я сейчас внедряю pitest на личных проектах. При использовании со Spring есть сложности. Если у вас есть рекомендации/опыт внедрения, поделитесь, пожалуйста, буду очень благодарен.
Мутационное тестирование штука интересная, но она сильно увеличивает время выполнения тестов.
Да личных библиотек - использую, а вот для бизнес-приложений - нет, так как ресурсы потраченные на его внедрение просто не окупаются.
ИМХО обычный code coverage(например JaCoCo) не очень полезен, так как line coverage можно набить и тестами, которые будут просто запускать код, но не выполнять ни единой проверки
+1. Покрывать нужно конечные сценарии, а не код сам по себе
Статический анализ кода в современной Java-разработке