Как Вы осуществляете рефакторинг большую грязную кодовую базу?

Вы можете посмотреть книгу Мартина Фаулера Рефакторинг . Это книга, которая популяризировала этот термин и технику (моя мысль, когда я проходила его курс: «Я делал много этого все время, я не знал, что у нее есть название»). Цитата из ссылки:

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

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

Вот каталог рефакторингов .

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

Рефакторинги, которые вам покажутся наиболее полезными, это Переименовать метод (и даже более тривиальные переименования, такие как поле, переменная и параметр), Извлечь метод и Извлечь класс. Для каждого выполняемого вами рефакторинга напишите необходимые модульные тесты, чтобы сделать рефакторинг безопасным, и запускайте весь набор модульных тестов после каждого рефакторинга. Заманчиво - и, будем честны, довольно безопасно - полагаться на автоматические рефакторинги вашей IDE, без тестов - но это хорошая практика, и тесты пригодятся в будущем, когда вы будете добавлять функциональность в свой проект.

очень медленно: D

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

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

Просто дополнительный рефакторинг, который важнее, чем вы думаете: назовите вещи правильно!

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

Также документируйте свои материалы. Всякий раз, когда ответ на ПОЧЕМУ? не ясно передан ответом на КАК? (будучи кодом) вам нужно будет добавить некоторую документацию. Принятие проектных решений, вероятно, является самой важной задачей, поскольку это очень сложно сделать в коде.

Купите среду IDE с хорошей поддержкой рефакторинга. Я думаю, что IntelliJ - лучший, но теперь он есть и в Eclipse.

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

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

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

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

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

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

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

Это может быть удивительно освежающим, когда правильно переделанная программа делает то же самое, что делала раньше, только более "чисто". ;)

Как уже говорили другие, юнит-тесты - ваш лучший друг! Они помогут вам убедиться, что ваш рефакторинг работает, а если вы начинаете с "нуля", то это идеальное время для их написания.

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

Удаление переменных из общей области видимости, как вы это делаете, - отличное начало, поскольку вы разделяете обязанности. В конечном итоге вы хотите, чтобы каждый класс выражал единственную ответственность. Вот еще несколько вещей, на которые вы можете обратить внимание:

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

Я Во-вторых, все рекомендации по рефакторингу Фаулера , но в вашем конкретном случае вы можете посмотреть на Майкла Фезерса Эффективная работа с устаревшим кодом , который действительно идеально подходит для вашей ситуации.

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

Большая часть книги - это обсуждение поиска (или создания) швов в вашей кодовой базе - швы - это естественные «линии разлома», если хотите, где вы можете проникнуть в существующую систему. чтобы начать его тестирование и продвигать его к лучшему дизайну. Трудно объяснить, но хорошо стоит прочитать.

Есть краткая статья , в которой Фезерс конкретизирует некоторые концепции из книги, но действительно стоит выследить все это целиком. Это один из моих любимых.

Выбросьте это, постройте новое.

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

Я думаю, вам стоит использовать Eclipse в качестве IDE, потому что у него много плагинов и он бесплатный. Вы должны следовать паттерну MVC и писать тестовые примеры с помощью JUnit. Eclipse также имеет плагин для JUnit и предоставляет возможность рефакторинга кода, так что это сократит вашу работу. И всегда помните, что написание кода не так важно, главное - писать чистый код. Так что теперь везде давайте комментарии, чтобы не только вы, но и любой другой человек, читая код, чувствовал, что читает эссе.

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

Для кода Java мой любимый первый шаг - запустить Findbugs, а затем удалить все мертвые хранилища, неиспользуемые поля, недоступные блоки catch, неиспользуемые частные методы и вероятные ошибки.

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

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