Pull to refresh

Comments 7

Во-первых, говоря о компилируемых языках программирования, никакой потери производительности быть не должно. Если она и есть — это камень в огород автора оптимизаций в компиляторе.
Да и интерпретируемые языки в наши дни тоже, в большинстве случаев, никакой потери производительности не понесут.
А если ещё вспомнить что частоты современных процессоров измеряются гигагерцами, то лучше заняться оптимизацией в других местах.

Во-вторых зависимости, которые вы сами поддерживаете, чем-то плохим не считаются.
Каждый экземпляр копипасты, по такой логике, тоже является зависимостью. Программа же не будет работать если его выкинуть.
Так что тут имеет место сокращение зависимостей от собственной лени.

В-третьих, про ошибки просто чушь собачья. Чтобы не было таких ошибок — код нужно тестами покрывать.
Одна ошибка в одном месте исправляется за один раз.
Исправлять кучу одних и тех же ошибок в разных местах — вот где можно наделать новых или просто пропустить старых. Тем более если про тесты не слышали.
В целом я с Вами согласен, но все-таки я бы не был так радикален.

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

С зависимостями совсем все неоднозначно. Там всё становится плохо, если дубликаты расположены в разных модулях. В статье была ссылка на неплохое рассуждение на эту тему. Если вкратце, то мысль такая — стоит ли создавать новую зависимость (и поддерживать ее) ради нескольких строк кода? Хотя я скорее бы предпочел явную зависимость, чем неявную в виде клонов. Но этот вопрос довольно много обсуждается.

Про ошибки я не совсем понял. Если речь о примере 3, то чушь собачья — это то, что такие ошибки существуют? Данный пример ведь из реального довольно популярного проекта Spring, там и тесты есть. Конечно, исправлять ошибки во всех дубликатах — это чревато, об этом и пример.

В любом случае, спасибо что внимательно прочитали статью.
Я когда-то даже диссертацию начинал писать по поиску и устранению дубликатов в коде, но забил в итоге на это.
Лет 5 назад clone-finder'ы существовали в основном в виде отдельных утилит, которые запускались с бубном, и никто ими не пользовался. Отрадно видеть, что сейчас поиск дубликатов становится фичей любой IDE pro-уровня.

Посмотрите на SonarQube и плагин для IDEA, Eclipse, Visual Studio, Visual Studio Code и Atom'а — SonarLint.
SonarLint(или только SonarQube. к сожалению сказать точно не могу) предоставляет инспекции в которых клонов видно больше чем в стандартных IDEA инспекциях.


  • много дополнительных уязвимостей и кодсмеллов.


  • SonarLint интегрируется с SonarQube'ом так что свои инспекции можно самому настраивать и видеть их в IDE.

Ну и просто, если вы вдруг не знали, SonarCloud — бесплатен для OpenSource проектов и может легко использоваться в связке с GitHub + TravisCI + SonarCloud


P.s. Хотел написать просто: "добавьте к списку плагинов для поиска клонов SonarLint", но получилось что-то напоминающее рекламу…

К сожалению, у меня не получилось найти дубликаты с помощью этого плагина (в том числе и с использованием сервера). На stackoverflow говорят, что он эту возможность не поддерживает. Пожалуйста, поправьте, если это не так.

Только что перепроверил: SonarQube версия 6.5


Разделы "Dashboard" -> "Duplications" или "Measures" -> "Duplications".


Показывает процентное соотношение дублируемого кода к общему объёму кода и количество дублируемых блоков.


  • Все дублирования отображаются в разделе Issues

Важное замечание: Не работает в самой IDE (по непонятным мне причинам) и не обнаруживает блоки кода(даже методы) с переменными, которые имеют разное название(в т.ч. и локальными для метода).

Спасибо за ответ. Жалко, что поиск клонов все-таки не интегрирован в IDE.
Sign up to leave a comment.

Articles