The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Существует множество инструментов для контроля качества Java-кода, включая Checkstyle, PMD, FindBugs, Cobertura и т. д. Обычно все они используются для анализа качества и создания красивых отчетов. Очень часто эти отчеты публикуются серверами непрерывной интеграции, такими как Jenkins.
Qulice идет еще дальше. Он собирает несколько инструментов для проверки качества, настраивает их в максимально строгом режиме и прерывает сборку, если хотя бы один из них не пройдет проверку.
Серьезно. В Checkstyle более 130 проверок, в PMD более 400 правил, а в FindBugs более 400 ошибок. Все они должны сказать: “Да, нам нравится ваш код”. В противном случае, ваша сборка не должна пройти.
Что вы думаете? Было бы удобно для вас, чтобы ваш код был отклонен каждый раз, когда он нарушает только одну из 900 проверок? Было бы продуктивно для команды принуждать разработчиков так сильно фокусироваться на качестве кода?
First Reaction
Если вы присоединитесь к одной из наших команд в качестве разработчика Java, вы будете разрабатывать свой код в ветках, а затем Rultor выполнит слияние ваших изменений в master. Однако перед фактическим слиянием Rultor запустит автоматизированный сценарий сборки, чтобы убедиться, что ваша ветка не вызывает ошибок.
Как инструмент статического анализа, Qulice является всего лишь одним из шагов в автоматизированном сценарии сборки. Фактически, это плагин Maven, и мы автоматизируем сборку Java с помощью Maven 3x. Таким образом, если ваши изменения нарушают любое из правил Qulice, весь ваш ветвь будет отклонен.
Ваша первая реакция - я видел это сотни раз - будет отрицательной. Вы можете даже быть настолько разочарованы, что покинете проект немедленно. Вы можете сказать что-то вроде этого (я цитирую реальные истории из жизни):
“Эти правила качества полностью уничтожают мою творческую составляющую!”
Вместо того чтобы тратить время на эти неправильно расставленные запятые и фигурные скобки, нам лучше заняться разработкой новых функций!
“Я сделал много успешных проектов в своей жизни, никогда не слышал о такой смешной проверке качества…”
Эта первая реакция совершенно логична. Я видел, как многие люди говорят такие вещи как в открытых и коммерческих проектах. Не только в Java, но и в PHP (с phpcs и phpmd) и Ruby (с rubocop и simplecov).
Как мне ответить? Продолжайте чтение.
On Second Thought
Мой опыт говорит мне, что чем раньше кто-то сможет привыкнуть к строгому контролю качества Qulice, тем быстрее он/она сможет учиться и развиваться; тем лучше программист он/она; и тем дальше он/она может продвинуться с нами и нашими проектами.
Имея это в виду, я рекомендую всем новым участникам проекта быть терпеливыми и попытаться привыкнуть к этому новому подходу к качеству. Через несколько недель те, кто остается на этом пути, начинают понимать, почему такой подход полезен для проекта и для них, как инженеров Java.
Почему это хорошо? Читайте дальше.
What Do Projects Get From Qulice?
Давайте возьмем одно простое правило в качестве примера. Вот кусок кода на языке Java, о котором Qulice пожаловался бы (из-за правила DesignForExtension из Checkstyle):
public class Employee {
public String name() {
return "Jeff";
}
}
Что не так с этим кодом? Метод name() не является финальным и может быть переопределен классом, который расширяет Employee. С точки зрения проектирования это неправильно, поскольку дочерний класс может нарушить работу родительского класса, переопределяя его метод.
Каков правильный дизайн? Вот этот:
public class Employee {
public final String name() {
return "Jeff";
}
}
Теперь этот метод является окончательным и не может быть переопределен дочерними классами. Это намного более безопасный дизайн (согласно Checkstyle, и я согласен).
Итак, предположим, мы сделаем это правило обязательным для всех классов в проекте. Что проект получает от этого? Он может обещать своим участникам (программистам) более высокое качество работы по сравнению с другими проектами, которые не имеют такого ограничения, в основном из-за:
Предсказуемость дизайна — Мне не нужно прокручивать весь класс, чтобы убедиться, что в нем нет методов, которые могут быть случайно переопределены. Я точно знаю, что это не может произойти в этом проекте. Другими словами, я знаю, чего ожидать.
Меньше скрытых приемов — Более предсказуемый дизайн обеспечивает лучшую видимость ошибок и хитростей. Стандартизация исходного кода делает его однородным. Это означает, что его легче читать и обнаруживать проблемы.
Стандарты отрасли—Решение об использовании этого дизайна принимается Checkstyle, а не проектным архитектором. Для меня, как разработчика проекта, это означает, что я следую стандартам отрасли. Это делает проект (и его руководителей) более уважаемыми.
Обучение — Могу поспорить, что большинство из вас, кто читает этот пост, не знали о правиле дизайна, которое было объяснено выше. Просто прочитав эту статью, вы узнали что-то новое. Представьте, сколько вы можете узнать, сделав свой код соответствующим всем 900 правилам Qulice (Checkstyle + PMD + FindBugs).
Пункт о обучении приводит нас к последней, и самой важной, мысли для обсуждения.
What Do I Get from Qulice?
Как программист, я надеюсь, что вы уже осознаете, какую пользу вы получаете, работая в проекте, который устанавливает настолько высокую планку качества, как требуется в Qulice. Да, вы узнаете много нового о написании качественного Java кода.
Кроме того, я бы даже сказал, что вы получаете бесплатные уроки с каждой новой строкой кода, которую пишете. А преподаватель - это программное обеспечение, созданное сотнями разработчиков Java за последние десять лет. Qulice просто объединяет эти программные инструменты вместе. По правде говоря, разработчики являются настоящими авторами проверок качества и правил.
Итак, что я говорю тем, кто жалуется на слишком строгое соблюдение правил качества? Я говорю следующее: “Хотите ли вы учиться и совершенствоваться или просто получить оплату и уйти от этого?”
ps. Вы можете использовать мой settings.jar для IntelliJ, они довольно строгие и помогут вам очистить ваш код еще до того, как Qulice начнет жаловаться.
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-08 at 16:09
