Блог

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

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

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

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

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

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

Как только у вас появится эта информация, вы, по крайней мере, будете знать, с чем имеете дело.

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

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

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

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

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

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

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

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

 [Opened C:Program FilesJavajre1.6.0_04librt.jar]
[Loaded java.util.regex.Pattern$Single from C:Program FilesJavajre1.6.0_04librt.jar]
 

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

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

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

Однако это была довольно большая работа.

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

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

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