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 проверок? Было бы продуктивно для команды, чтобы заставлять разработчиков так сильно сосредотачиваться на качестве кода?
Если вы присоединитесь к одной из наших команд в качестве разработчика Java, вы будете разрабатывать свой код в ветках, а затем Rultor сольет ваши изменения в master. Однако перед непосредственным слиянием Rultor будет запущен автоматический сценарий сборки, чтобы убедиться, что ваша ветка не нарушает его.
В качестве инструмента статического анализа Qulice является только одним из этапов автоматического сценария сборки. Фактически, это плагин Maven, и мы автоматизируем сборки Java с помощью Maven 3x. Таким образом, если ваши изменения нарушают какое-либо из правил Qulice, ваша ветка будет отклонена.
Ваша первая реакция - я видел это сотни раз - будет отрицательной. Вы можете быть настолько разочарованы, что решите немедленно покинуть проект. Вы можете сказать что-то вроде этого (я привожу реальные истории):
Вместо того чтобы тратить время на эти неправильно расставленные запятые и скобки, нам лучше заняться разработкой новых функций!
“В своей жизни я выполнил множество успешных проектов, но никогда не слышал о такой нелепой проверке качества…”
Эта первая реакция вполне логична. Я видел, как многие люди говорили такое в открытых и коммерческих проектах. Не только в Java, но и в PHP (с phpcs и phpmd) и Ruby (с rubocop и simplecov).
Как мне ответить? Читайте дальше.
Мой опыт говорит мне, что чем раньше человек сможет привыкнуть к строгому контролю качества Qulice, тем быстрее он сможет учиться и развиваться; тем лучше программист он будет; и тем дальше он сможет продвинуться с нами и нашими проектами.
Имея этот опыт в виду, я рекомендую всем новым участникам проекта быть терпеливыми и попытаться привыкнуть к этому новому подходу к качеству. Через несколько недель те, кто продолжает придерживаться этого подхода, начинают понимать, почему он хорош для проекта и для них, как Java-разработчиков.
Почему это хорошо? Читайте дальше.
Давайте возьмем одно простое правило в качестве примера. Вот небольшой фрагмент кода на Java, о котором Qulice была бы недовольна (из-за правила DesignForExtension из Checkstyle):
Что не так с этим кодом? Метод name() не является финальным и может быть переопределен классом, который расширяет Employee. С точки зрения дизайна это неправильно, поскольку дочерний класс может нарушить функционал суперкласса, переопределив его метод.
Какой должен быть правильный дизайн? Вот этот:
Теперь метод является окончательным и не может быть переопределен дочерними классами. Это намного более безопасное проектирование (согласно Checkstyle, и я согласен).
Итак, предположим, что мы делаем это правило обязательным для всех классов в проекте. Что проект получает от этого? Он может обещать своим участникам (программистам) более высокое качество работы по сравнению с другими проектами, которые не имеют такого ограничения, в основном из-за:
Меньше скрытых трюков — Более предсказуемый дизайн ведет к лучшей видимости ошибок и трюков. Стандартизация исходного кода делает его однородным. Это означает, что его легче читать и обнаруживать проблемы.
Стандарты отрасли — Решение об использовании этого дизайна принимает Checkstyle, а не проектный архитектор. Для меня, в качестве разработчика проекта, это означает, что я следую отраслевым стандартам. Это делает проект (и его лидеров) более уважаемыми.
Обучение—Я уверен, что большинство из вас, кто читает этот пост, не знали о правиле дизайна, объясненном выше. Просто прочитав эту статью, вы узнали что-то новое. Представьте, сколько вы могли бы узнать, сделав свой код соответствующим всем 900 правилам Qulice (Checkstyle + PMD + FindBugs).
Вопрос об обучении приводит нас к последней и самой важной мысли для обсуждения.
Как программист, я надеюсь, вы уже понимаете, что получаете, работая в проекте, который ставит свою планку качества так высоко, как требует Qulice. Да, вы узнаете много нового о написании качественного кода на Java.
Кроме того, я бы сказал, что вы на самом деле получаете бесплатные уроки с каждой новой строкой кода, которую пишете. И учителем является программное обеспечение, написанное сотнями разработчиков на Java за последние десять лет. Qulice просто объединяет эти программные инструменты вместе. Правда, на самом деле, разработчики являются настоящими авторами проверок качества и правил.
Итак, что я говорю тем, кто жалуется на слишком строгие правила качества? Я говорю: “Вы хотите учиться и совершенствоваться, или вам просто хочется получить оплату и уйти от этого?”
ps. Вы можете использовать мой settings.jar для IntelliJ, они достаточно строгие и помогут вам очистить ваш код еще до того, как Qulice начнет жаловаться.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:42
