Как и Как часто Вы осуществляете рефакторинг свой код?

Specific to VS 2008 and C#

All the time. I tend to code with StyleCop and Code Analysis permanently running. Even Resharper is used, and if I see red anywhere, it is time to refactor. Granted I only use these tools to simplify doing it and to force me to do it.

However as I rule I only refactor my own code and new code. Legacy code and code written by others go untouched until instructed to do so.

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

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

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

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

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

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

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

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

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

I refactor very often. The classic scenario is when I end writing big methods and I like to break them apart into smaller pieces. There are many others and they happens with some frequency. Refactoring helps me a lot to keep a balance between coding fast, but keeping my code as tidy as I can.

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

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

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

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

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

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

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

I'm not a big fan of refactoring just for refactoring sake. I always try to keep the code as clean as possible, avoid shortcuts and do it rigth the first time. Each time I add a new feature I refactor on the go if needed, and consider that a part of the feature implementation.

If you can afford to work that way, big and "scary" refactorings are not needed as often as if you don't do regular minor cleanups.

Of course, when scope of the project changes the refactoring is often needed regardless of the shape in which the code is, but the leaner the code is the refactoring is easyer and faster.

Главное - никогда не сообщать своему боссу / клиенту, что вы проводите рефакторинг. Всегда включайте рефакторинг в обычный поток работы. Не стоит постоянно утомлять объяснения, почему за это стоит платить.

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

When I write a first pass of code, I usually try not to bog myself down with thinking too far into the future about possible reuse scenarios. Then, as more reuse scenarios come up the further I get into development, the more I refactor my old code to increase its levels of abstraction and reuse.

So really it's an iterative process; the more I go over and use code I already wrote for new purposes, the more I find it necessary to refactor.

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

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

Всякий раз, когда я вижу дублированный код.

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

Все меньше и меньше я подхожу к выпуску :)

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

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

I refactor only when I have the code covered by test cases.

Есть уровни и уровни рефакторинга.

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

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

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

m не усугубит ситуацию из-за рефакторинга плохо покрытого кода.

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

m не усугубит ситуацию из-за рефакторинга плохо покрытого кода.

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

Its kind of like cleaning a house, you ought to pick up every day and do the little tasks that need to be done to keep things clean. Then (once a week or so) you take several hours and give the house a good cleaning from top to bottom. Finally (once a year or so) you do a good Spring-cleaning, haul out all the junk and start fresh.

Refactoring is about keeping a clean code-base and it is a perpetual tasks that is never finished.