Практический рефакторинг

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

  • Что, по вашему мнению, рефакторинг?
  • Как и когда вы это делаете?
9 ответов

Что, по вашему мнению, рефакторинг?

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

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

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

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

Как и когда вы это делаете?

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

Когда вы можете это сделать, важно убедиться, что код, который вы написали, не будет калечить вас (или ковылять) в будущем. Если вы набрали ярлыки вверх, чтобы отправить продукт вовремя, тогда вы можете получить шанс в течение будущих периодов посвятить небольшое время рефакторингу. Идея иметь "время простоя", однако, является, очевидно, просто мифом в деловом мире;)

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

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

С другой стороны, рефакторинг может быть приятным (хотя иногда это может быть безумным)


Рефакторинг - это процесс просмотра старого кода и его подтягивания, при этом он все равно работает. Есть несколько способов сделать рефакторинг:

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

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


О том, когда делать рефакторинг:

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


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

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


Рефакторинг меняет дизайн существующего кода, оставляя функциональность одинаковой.

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


Рефакторинг - это процесс создания поддерживаемого кода из недостижимого кода-ад.

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

function show_movies($num=10, $maxpages=10, $order_by="M.produced DESC", $rand=0)
{
 global $template, $off, $cat, $cat_long, $cat_field, $lang, $mid, $cat_long2, $sfm;
 global $sea, $seaquery, $lng, $sub, $aff, $spe, $da, $cat_not, $PHP_SELF, $HTTP_HOST;
 global $q, $_SESSION, $VC_LANG, $john;
 [... snip 356 lines of code that works with all those variables ...]
}

(К сожалению, это код, с которым мне приходится работать, и у меня нет времени на его рефакторинг... о, а если кто-то задается вопросом, $john разрешает режим отладки и приходит из GET через register_globals... я ненавижу свою жизнь)

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

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


Рефакторинг - все о том, как сделать ваш код более удобным.

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


Рефакторинг просто означает изменение дизайна программы или части программы. В объектно-ориентированном программировании это часто означает, что вы пересматриваете свои иерархии классов.

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

Некоторые IDE, такие как Visual Studio, имеют инструменты для рефакторинга, например, возможность выбирать код и извлекать его в метод или легко переименовывать переменную. Без них рефакторинг должен выполняться вручную, так как это часто делается на таких языках, как С++, которые трудно автоматизировать рефакторинг.


Что, по вашему мнению, рефакторинг?

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

Как и когда вы это делаете?

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

licensed under cc by-sa 3.0 with attribution.