Sonarlint звучит как отличный инструмент для нашей повседневной работы, и он действительно очень многообещающий, если вы думаете о предотвращении проблем еще до того, как они возникнут. Однако в устаревшем продукте (или вообще) все может быть не так хорошо.

Первая проблема заключается в том, что новички в анализе кода устаревших продуктов все еще находятся на стадии его оценки и принятия. Вероятно, они не отфильтровали правила анализа кода до тех, которые полезны для проекта. Представьте, например, что неожиданно вы получаете предупреждение, потому что у вас есть функция с более чем 3 входными данными.

Незрелость, существующая в отношении этих правил анализа кода, вызовет путаницу и может привести к потенциально неправильным практикам. Например, разработчик может проигнорировать предупреждения правила или полностью отключить их, потому что он не понимает его значение в первую очередь или считает, что оно размещено неправильно.

Это может привести к одной из основных проблем Sonarlint — синхронизации с процессом анализа кода сервера SonarQube. Набор правил, который у вас есть на сервере (который создает этот ужасающийпервый отчет об анализе кода для устаревшего продукта), не синхронизирован с теми, которые Sonarlint использует локально на компьютере разработчика. .

Разработчик может отключить правило (где не должен) или новое правило, добавленное сервером, может не соответствовать локальному набору правил Sonarlint.

Проблема синхронизации была частично решена Sonarlint (только для кода C# — «Подключенный режим применяется только для кода C# и VB.Net»), однако вы можете не быть уверенным в том, какие правила были применены, пока код не будет зафиксирован на сервере.

Автоматический запуск анализа кода на сервере при фиксации чего-либо — это процесс, который разработчик не может обойти.

Еще одна проблема, которая может существовать, заключается в том, что вы не можете легко исключить выполнение онлайн-анализа кода для файлов, которые вы не трогали или которые не нуждаются в анализе (например, сторонние библиотеки, включенные в наш проект, особенно библиотеки JavaScript). Это может привести к созданию экрана, полного предупреждений, которые, помимо того, что выглядят просто ужасно, заставят разработчиков использовать предупреждения в конце (там, где их не должно быть, поскольку предупреждения на самом деле что-то значат ).

Похоже, Sonarlint частично решил эту проблему, но только для кода C#. В этом случае, как упоминалось ранее, вы можете синхронизировать список игнорирования правил со списком, найденным на сервере. Однако во всех других случаях (JavaScript) вы можете столкнуться с описанной выше проблемой.

Наконец, и, возможно, более важно, это проблемы с производительностью.

Неуместное огромное количество предупреждений, помимо того, что это ужасно, также означает, что много анализа кода произошло, когда этого не следовало делать. Однако выполнение анализа кода каждый раз, когда вы что-то изменяете или создаете, нелегкий процесс, особенно для проекта с большим количеством больших файлов. Это может стать действительно раздражающим для нашей повседневной работы.

Если сервер выполняет всю эту тяжелую работу (с его превосходными вычислительными ресурсами) в асинхронном режиме, в этом случае звучит намного лучше.

Полезную статью с описанием всех вышеперечисленных подводных камней можно найти здесь.