Как отсеять зависимости в большом проекте?

Question

Я собираюсь унаследовать довольно большой корпоративный Java-проект с большим количеством сторонних зависимостей. Включено не менее семидесяти JAR-файлов, и некоторые из них могут показаться неиспользованными, например, Я знаю, что spring.jar не используется.

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

Как можно избавиться от них? Конечно же, очевидно, что некоторые зависимости полезны, так как не нужно заново изобретать колесо.

Я, очевидно, заинтересован в проектах на основе Java, но я рад ответить на вопросы на разных языках, которые люди считают полезными.

Answer 1

Лично я думаю, что вы должны начать с оценки масштаба проблемы. Это будет довольно болезненно, но я бы составил список зависимостей и определил, какие именно части проекта используют какие.

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

Получив эту информацию, вы хотя бы узнаете, с чем имеете дело.

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

Я бы также осмотрелся, чтобы увидеть, есть ли что-нибудь маленькое, что вы могли бы просто переписать и включить в свою собственную базу кода.

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

Тогда вы просто задаетесь вопросом, лучше ли сильно зависеть от нескольких поставщиков или меньше зависеть от многих поставщиков !! ; О)

Answer 2

структура101 http://www.headwaysoftware.com/products/structure101/index.php Это отличный инструмент для отображения зависимостей. Я использую его пару лет.

Answer 3

Если вы используете подход «удалять вещи, пока он не скомпилируется», вы должны быть очень осторожны с переходными зависимостями времени выполнения. Если есть набор тестов хорошего качества, он может помочь, но вам, безусловно, нужно запустить инструмент покрытия тестов, такой как Cobertura, чтобы убедиться, что тестируется достаточное количество кода для реализации вашего полного графика зависимостей.

Сколько кода вы говорите? Откровенный подход, предложенный Джоэри, откровенно кажется мне лучшим; у него есть дополнительное преимущество, благодаря которому вы, по крайней мере, поверхностно знакомы со всеми частями системы. Если вы просто наследуете большой проект, это то, что вам все равно стоит потратить время.

Answer 4

Мы прошли подобное упражнение на базе кода Delphi. Мы значительно упростили наши внешние зависимости. В основном, мы пошли примерно так:

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

Это было, однако, довольно много работы.

Answer 5

Я читал о подходе с использованием инструментов здесь , никогда не пробовал, но звучит разумно.

Answer 6

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

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

Если вы имеете дело с автономным приложением, вы можете дать JVM опцию -verbose: class, чтобы увидеть, какие классы загружаются. Это должно дать вам такие сообщения, как:

[Opened C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]
[Loaded java.util.regex.Pattern$Single from C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]

Answer 7

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