Как и как часто вы проводите рефакторинг своего кода?

Question

Мой вопрос смутно относится к этому . Тем не менее, это не касается методов или практик.

Я читаю Прагматичный программист , и он настоятельно рекомендует рефакторинг кода так часто, как вы можете. Тем не менее, это не вдаваться в подробности о том, как это сделать и как часто. Как вы, ребята, занимаетесь рефакторингом своего кода и как часто вы проводите рефакторинг?

Answer 1

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

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

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

1. Какая выгода от рефакторинга? Спектакль? Снижение сложности? Повторное использование
2. Каков уровень влияния изменений? Значительные изменения, как правило, связаны с большим количеством испытаний, связанных с ними, и создают большую степень риска.
3. Можно ли выполнить рефакторинг чисто? Неполный рефакторинг может привнести больше энтропии, чем отнять. Например, у вас есть несколько методов, которые сделали бы отличный служебный класс. Если вы введете класс утилит, можно ли будет заменить все существующие (и потенциально скопированные и вставленные) методы вызовами класса утилит? Существует ли еще один существующий класс утилит с аналогичной функциональностью?

Answer 2

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

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

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

Я также реорганизовал несколько процедур проверки данных и вставки данных в меньшие. Это помогает разбить бизнес-логику в приложении и может помочь «зонально» попасть туда, куда вам нужно. Например, в приложении есть шаг, который определяет, можно ли вставить строку в базу данных. Вместо того, чтобы сделать этот один шаг, я сделал это около 10, что включает чтение данных, проверку правильного размера и типа данных, что я показываю в метке и т. Д. Теперь проще изменить бизнес-логику определенного раздела .

Answer 3

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

• Развертывание медленных петель
• Перемещение определений переменных в начало функции.
• Замена более медленных алгоритмов-прототипов проверенными более быстрыми алгоритмами.

Answer 4

Специально для VS 2008 и C #

Все время. Я склонен к программированию с постоянно работающим StyleCop и Code Analysis. Даже Resharper используется, и если я где-нибудь вижу красный, пришло время рефакторинга. Конечно, я использую эти инструменты только для того, чтобы упростить это и заставить меня сделать это.

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

Answer 5

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

Answer 6

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

(Это еще одно преимущество DVCS: я могу фиксировать правильный, но неверно учтенный код, не нажимая.)

Answer 7

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

Answer 8

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