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

Question

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

До сих пор те из нас, кто был в проекте, "сливались", адаптируясь к существующему соглашению любого классамы работаем над этим, но придет время навести порядок и последовательность.

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

Редактировать, чтобы добавить: я не хочу создавать впечатление, что проект плохой - он на самом деле хорошо спроектирован и в значительной степени хорошо написан.Он просто чувствует свой возраст и неизбежность обслуживания ...

Answer 1

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

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

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

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

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

---

редактирование:

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

Answer 2

Вы можете использовать инструмент для наложения общего формата на исходный код в проекте.Кроме того, см. Michael Feathers, эффективно работающий с устаревшим кодом (где «устаревший код» определен как «код без юнит-тестов»), в котором описано, как постепенно превратить устаревший код в полностью протестированный и-тестабильный код.

Answer 3

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

Answer 4

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

1. Сначала преобразуйте проект, чтобы использовать сборку maven, чтобы я знал, к какой версии относятся зависимости.
2. Это такжедает мне несколько достойных отчетов о качестве кода для использования в качестве эталона, включая checkstyle, findbugs, pmd и покрытие кода.
3. И я (и многие другие) привыкли к этой структуре, поэтому мы знаем, где найти источник, юнит-тесты, ресурсы и т. д.
4. Если это большой проект, то, вероятно, правильная структура - это макет многомодульного проекта maven.
5. Если в настоящее время это один большойof-mud, тогда он становится базовым модулем, который впоследствии может быть преобразован в отдельные модули.
6. Стандартная структура каталогов maven 1015 * обеспечивает место и, следовательно, поощряет модульные тесты.
7. Модульные тесты являются критически важным условием для начала рефакторинга.
8. Создание цикла непрерывной сборки с использованием Hudson .

Answer 5

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

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

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

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

Не просто вытащить эти цифры из воздуха - это хитрость.Иметь возможность оправдать это.

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

Удачи!

Answer 9

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

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

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

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