Очистка большого, унаследованного Java-проекта

Ответ 1

Я считаю Eclipse невероятно мощным инструментом для таких операций.

Многие люди клянутся инструментами командной строки и текстовыми редакторами для программирования, но есть сильные преимущества использования полной IDE для основного рефакторинга:

• Автоматическая компиляция в реальном времени показывает вам ошибки, как они происходят, и везде, где они происходят. Просто потому, что вы делаете изменения, и ничего в классе или немедленных перерывах пакетов не означает, что вы не создали проблем в другом месте. Красные флаги будут подниматься вверх по дереву пакетов в eclipse, ведущем вас непосредственно к ним.
• Графическое переименование и перемещение. Переименование элементов вашего кода может иметь гораздо больший эффект, чем то, что вы знаете. Eclipse покажет вам детали каждого экземпляра рассматриваемого элемента и как он будет изменен переименованием.
• Автоматическое управление импортом позволяет вам решить проблему, связанную с обеспечением всех ваших импортных заказов. Eclipse автоматически добавит импорт по мере их использования и отметит неиспользованные с помощью лампочек действия для удаления одного щелчка.
• Используйте стили кода, чтобы все исходные файлы использовали одинаковый формат для всего. Пространства, отступы, новые строки, скобки могут быть отформатированы для вас. Это работает при создании нового кода, а также для обновления существующих файлов.

В дополнение к набору инструментов Eclipse вы можете использовать другие современные инструменты Java для обеспечения постоянного функционирования вашего кода.

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

изменить:

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

Ответ 2

Вы можете использовать инструмент , чтобы наложить общий формат исходного кода в проекте. Помимо этого, см. "Эффективная работа Майкла Фейрса с устаревшим кодом" (где "устаревший код" определен как "код без модульных тестов" ), в котором описывается, как постепенно превращать устаревший код в полностью проверенный и тестируемый код.

Ответ 3

Что мне нравится делать в этой ситуации:

• Сначала конвертируйте проект, чтобы использовать сборку maven, чтобы я знал, в какой версии находятся зависимости.
• Это также дает мне некоторые достойные отчеты о качестве кода для использования в качестве эталона, включая checkstyle, findbugs, pmd и покрытие кода.
• И я (и многие другие) используются для этой структуры, поэтому мы знаем, где найти источник, модульные тесты, ресурсы и т.д.
• Если это большой проект, то макет многомодового проекта maven, вероятно, является правильной структурой для использования.
• Если в настоящий момент это один большой бит-грязь, то это становится основным модулем, который впоследствии может быть реорганизован в отдельные модули.
• стандартная структура каталога maven обеспечивает место и, следовательно, поощряет модульные тесты.
• Модульные тесты являются критическим предварительным условием до начала рефакторинга.
• Установите цикл построения непрерывной интеграции, используя Hudson.

Ответ 4

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

Ответ 5

Я прошел этот процесс несколько раз, я обнаружил, что решение требует знания следующего:

• Будут ли политические беспорядки в концепции фиксации этих вещей?
• Есть ли теперь принятый стандарт того, как эти вещи должны выглядеть/отформатированы?
• Есть ли отличные тестовые примеры?

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

"согласованный набор стандартов кодирования приведет к:  - на 30% меньше ошибок  - На 30% быстрее развитие  - Снижение эксплуатационных расходов на 80%  - 100% из нас кодеры будут намного счастливее с этим изменением "

Не просто вытащить эти цифры из воздуха - это трюк. Уметь оправдать это.

Ясно, что нет смысла начинать эту работу, если вы не купите у людей, которые в настоящее время добавляют к проекту. Каждый должен согласиться и начать ретро-установку этих идеалов в код, который в настоящее время существует. Помните, что не все используют IDE (например, я кодирую все мои java в VIM), и поэтому вы должны убедиться, что этот формат продиктован вики, чтобы все могли видеть (особенно новые члены команды) и что на странице вики есть загрузки для разных редакторов в использовании.

Так как очень вероятно, что мы говорим не только о форматировании кода, но и о переименовании переменных, а также об изменении шаблонов, это влияет на общедоступный api ваших классов, поэтому вам действительно нужно убедиться, что у вас очень стабильный набор тестовых примеров, Если тестовые примеры отсутствуют, вы всегда должны начинать снаружи в модели своих тестов, чтобы они взаимодействовали, как ваши пользователи. Затем вы можете пройти через рефакторинг со степенью уверенности. Когда у вас есть код, похожий на ваши мечты, вы можете войти и добавить тесты ближе к каждому объекту. Нет ничего более болезненного в том, чтобы создавать все ваши тестовые примеры, а затем менять API и изменять все ваши тестовые примеры; каждый раз, когда я видел это, это приводит к значительному снижению охвата тестированием.

Ответ 6

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

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

Кроме того, для Eclipse существуют плагины с надстройками.

Ответ 7

Это довольно распространенная задача, не очень радостная, но ни кошмар... Это может быть хуже, если закодировано на других языках (Perl, PHP, С++, -gasp- VB...); на самом деле, Java является одним из лучших для вашего сценария.

Получите достойную IDE (Eclipse) и хорошо разбирайтесь в зависимостях и циклах вызовов. Это займет много времени, чтобы ознакомиться со всем, поэтому сначала попробуйте сделать только небольшие изменения.

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

Существует много книг, посвященных "Реинжиниринговому программному обеспечению Legacy" и связанным с ним вопросам.

Ответ 8

У меня был такой опыт. Я согласен с людьми, которые рекомендуют maven build, eclipse, Checkstyle, рефакторинг больших классов и т.д. Я понимаю, что вы не можете достичь полного охвата тестирования до того, как начнете работать. Я бы рекомендовал 1. переформатировать код в пакетном режиме с помощью checkstyle или аналогичного инструмента 2. включить все разумные предупреждения в Eclipse и код рефакторинга, которые вызывают такие предупреждения, если этот рефакторинг тривиален. В других случаях ставьте @SupressWarning и специальный TODO, чтобы вернуться к этому коду позже. 3. используйте автоматическое тестирование с ошибками, то есть разработайте тесты для модуля, который вы собираетесь изменить.

Удачи!

Ответ 9

Я также рекомендую использовать функции IDE для улучшения качества кода. Для eclipse это то, что я сделал бы:

В настройках java > code style > formatter - определите свой собственный формат и добавьте его. после этого щелкните правой кнопкой мыши проект и источник < очистить. Выберите профиль и настройте его. Есть много вещей, которые вы можете сделать здесь, например, форматирование кода, очистка импорта, преобразование устаревших для циклов в улучшенные, очистка неиспользуемого кода и многое другое.

После этого я бы сделал то, что предлагали здесь другие люди, а также использовать checkstyle, pmd, findbugs и т.д.