Существует множество инструментов для мониторинга качества кода вашего решения с помощью статического анализа кода и последующего отображения списка проблем, которые необходимо исправить. Многие идут с красивыми графиками и информационными панелями.
Выше - SonarQube, один из самых популярных инструментов в этой сфере. Другой пример - плагин Checkstyle Jenkins.
Я использовал оба этих инструмента в недавних проектах. Концепция привлекательна: вы можете отслеживать качество кода и принимать меры, если оно превышает пороговое значение. Однако я никогда не считал этот подход эффективным в командной среде.
В большинстве проектов разработки разработчики стремятся максимально быстро реализовать функциональность. У них есть скраммастеры и владельцы продуктов, которые бьют по барабану каждый день. По моему опыту, разработчики будут каждый раз игнорировать предупреждения о линтах и ошибки в коде, если у вас нет процесса, обеспечивающего его соблюдение. Они объясняют, что могут исправить их позже, после того, как их функции начнут тестироваться.
Проблема в том, что «позже» - ужасное время для решения проблем с ворсом. Функциональность, вероятно, уже прошла регрессионное тестирование, и подробности кода больше не актуальны для разработчика. Изменение кода на этом этапе представляет риск неожиданных побочных эффектов.
Единственный способ, который, как я обнаружил, действительно обеспечить последовательное и безопасное решение проблем с качеством кода, - это остановить их до того, как они начнутся, - отказав сборке непрерывной интеграции, если они есть. Не позволяйте коду с новыми проблемами качества попадать в среду, где его могут видеть тестировщики. Пока вы сохраняете этот барьер, разработчики будут вынуждены решать проблемы до того, как объявят свои функции завершенными. Невозможно срезать углы.
Я также рекомендую не различать предупреждения и ошибки. Подавляющее большинство ошибок, связанных с ворсом, можно устранить всего за несколько минут. Нет причин игнорировать даже незначительные проблемы. Если вас постоянно не беспокоят определенные предупреждения, просто отключите их в файле конфигурации. Вы также можете применить эти концепции к покрытию тестов: не приступайте к написанию тестов, когда уровень покрытия падает слишком низко. Вместо этого установите минимальный порог покрытия и завершите сборку непрерывной интеграции, если она не будет достигнута.
Вы можете упростить процесс ошибки, используя инструменты, которые устраняют проблемы с сохранением файлов, такие как плагины IDE для красивее и линтеров. Но вот ключ: не полагайтесь только на красный подчиненный IDE, чтобы предупредить разработчиков. Вы также должны проверить наличие проблем в precommit или preush hook, чтобы избежать каких-либо проблем, незаметных для вас и сбоя сборки. Постоянное соблюдение правил на локальных машинах разработчиков имеет решающее значение - в противном случае люди будут жаловаться на постоянные сбои сборки и рекомендовать отключить на них проверку линта.
(Hound здесь является интересным промежуточным звеном - он обеспечивает соблюдение правил как часть запроса на вытягивание. Это лучше, чем ничего, но похоже, что принудительное применение на локальных машинах разработчиков, а затем опять же, как часть сборки CI, должно выполнять свою работу. просто отлично. Если в вашем PR появляются проблемы со стилем, и вы применяете их локально, более эффективная обратная связь - сказать разработчику прекратить добавлять no-verify к коммитам, а не комментировать каждую проблему, которую нужно исправить.)
Если у вас много существующего кода с проблемами lint, я рекомендую либо A) вывести существующее количество ошибок в файл и написать сценарий времени сборки, чтобы убедиться, что количество ошибок не увеличилось в каждом файле, или B) добавление комментариев отключения / игнорирования к каждой отдельной ошибке вместе с TODO для оценки. Вариант B требует больше усилий на один раз, но он позволяет более строго применять правила lint в отношении нового кода. НЕ просто отключайте линт для целых файлов.
И последнее замечание: инструменты различаются по простоте запуска во время сборки. Большинство линтеров (например, eslint, PMD, FindBugs) делают это легко, но с SonarQube это на удивление сложно. Если ваш инструмент не поддерживает принудительное исполнение во время сборки, я рекомендую сменить инструмент.
