Комментарии 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", но получилось что-то напоминающее рекламу…
Только что перепроверил: SonarQube версия 6.5
Разделы "Dashboard" -> "Duplications" или "Measures" -> "Duplications".
Показывает процентное соотношение дублируемого кода к общему объёму кода и количество дублируемых блоков.
- Все дублирования отображаются в разделе Issues
Важное замечание: Не работает в самой IDE (по непонятным мне причинам) и не обнаруживает блоки кода(даже методы) с переменными, которые имеют разное название(в т.ч. и локальными для метода).
Атака клонов. Как бороться с дублированием кода?