До выхода книги Мартина Фаулера «Рефакторинг: улучшение дизайна существующего кода» мы привыкли называть серьезные изменения в коде «реархитектурой», а незначительные изменения - «очисткой». ИМО, методы рефакторинга - это все здравый смысл / очевидные вещи, которыми мы занимаемся вечно.
Как вы думаете, рефакторинг был чем-то новым? Может быть, просто способ обмануть управление распределением времени на очистку кода?
design
refactoring
terminology
Чак Стефански
источник
источник
Ответы:
Рефакторинг старше холмов, так что нет, ничего нового.
И рефакторинг не убирает. Ну, это может быть, но это не ограничивается уборкой.
Он корректирует архитектуру вашего приложения (будь то в больших или малых масштабах), сохраняя при этом поведение.
Это означает, что, хотя некоторая часть вашего приложения вчера могла быть совершенно чистой и исправной, сегодняшняя новая функция требует корректировки этой части для соответствия новой функции.
Вы не хотите нарушать существующую функциональность, поэтому вы корректируете структуру своего приложения, сохраняя при этом поведение - что является рефакторингом.
При этом независимо от того, какие изменения внесены в код, всегда следует запускать его тесты ... на всякий случай.
источник
Это просто убирает код. По сути, программисты (особенно Мартин Фаулер) заметили, что они склонны выполнять одни и те же задачи каждый раз, когда приводят в порядок свой код. Они определили и пометили методы уборки и связанные с ними проблемы кода и presto! Рефакторинг родился.
То же самое и с шаблонами проектирования - люди заметили, что они склонны использовать одни и те же подходы к конкретным проблемам снова и снова. Они обозначили и определили подходы, и теперь кажется, что вы не настоящий программист, если только вы никогда не используете в своем коде только дюжину или около того шаблонов.
Там нет магии рефакторинга; это просто новый набор жаргона для описания старой практики.
источник
Мы делаем три отдельных действия в нашей компании с выделенным временем для трех:
Пример: разделение уродливого и нечитаемого метода из 100 строк, который выполняет четыре действия на четыре метода, которые можно использовать повторно, по 25 строк в каждом.
Пример: удаление закомментированного кода, убедившись, что этот код больше не нужен.
Пример: добавление
Culture.Invariant
вstring.Format
(или другую культуру , которая является более подходящим).Так что в моем случае рефакторинг очень сильно отличается от очистки . При выполнении очистки мне не нужно снова запускать модульные тесты: если код работал раньше, он будет работать после очистки. Другими словами, это не потому, что я удалил пустую строку или добавил комментарий, что код перестанет работать. С другой стороны, когда я выполняю рефакторинг сложных частей старого кода, я могу сделать несколько ошибок, поэтому после рефакторинга я должен запустить модульные тесты.
источник
Рефакторинг добавляет знания в ваш код. Если вы знаете, что что-то неправильно названо, вы даете ему лучшее имя. Если вы знаете, что что-то можно сделать лучше, вы превращаете это в нечто лучшее.
Это много шагов - маленьких и больших - которые, мы надеемся, приведут к лучшей программе.
источник
Я согласен с «рефакторинг - это модное слово для очистки кода», но не с «просто». Люди используют причудливые слова по причине: иногда потому, что они хотят выглядеть умно, а иногда потому, что они передают более или более точное значение, и рефакторинг ИМХО (даже если иногда неправильно) обычно относится к последнему.
«Очистить» может означать что угодно, от «немного переформатировать» до «переписывать большие куски».
«Рефакторинг» означает, в частности, что-то вроде «небольших постепенных изменений в коде, предназначенных для поддержания той же функциональности при одновременном преобразовании его в лучший дизайн». И есть множество лучших практик, касающихся того, что вы делаете: некоторые из них ad-hoc, но есть общие принципы, такие как использование модульных тестов, извлечение части функций в новые функции или классы и т. Д., Которые люди могут и должны изучить ,
Вы говорите «просто обманываете управление распределением времени на очистку кода». Но если выражение «рефакторинг» правильно передает концепцию, что постоянные инвестиции в ясность теперь принесут дивиденды в эффективности в будущем, то это не «хитрость», это четкое и эффективное общение.
источник
Рефакторинг - это кодирование, как нормализация - реляционные данные. Это процесс абстрагирования понятий в более четкие, ясные и эффективные представления их роли в приложении.
источник
Это зависит от того, как вы понимаете термин рефакторинг. Для большинства людей это процесс улучшения структуры без изменения поведения. Если вы согласны, то да, это было сделано задолго до выхода этой книги. Я знаю, потому что я (среди прочего) переименовывал классы, извлекал классы и извлекал методы до того, как книга была написана. Я не назвал это рефакторингом, но по сути я делал то же самое.
Лично для меня рефакторинг - это то, что люди сейчас называют «автоматическим рефакторингом кода», т. Е. Поддержка различных методов рефакторинга в IDE. Это реальное улучшение того, что я делал раньше (что действительно было очень больно). Я могу внести изменения в один класс и не беспокоиться о том, как это повлияет на остальную часть программного обеспечения. Я думаю, что Мартин формализовал метод рефакторинга до того момента, когда он мог бы быть представлен в виде алгоритма и таким образом реализован в различных IDE.
Так что если вы понимаете рефакторинг как процесс, то в этом нет ничего нового. Если вы видите это как автоматизацию, то да, это огромное улучшение. Попробуйте переименовать несколько базовых классов (буквально, а не с помощью опций рефакторинга вашей IDE) в достаточно крупном проекте, чтобы понять почему :)
источник
Рефакторинг - это действительно «очистка» кода, но также реструктуризация кода. В моей команде рефакторинг обычно последний. Когда у нас есть случай «рефакторинга», мы выделяем время для реструктуризации нашего кода, например, чтобы привести его в соответствие с новой архитектурой или информационной моделью или сделать его более эффективным.
Код «очистки» - это то, что мы делаем непрерывно без специально отведенного для этого времени. Для меня «очистка» - это обычно переименование, удаление комментариев и т. Д.
источник
Я бы сказал нет
Там может быть очистка в процессе рефакторинга, но это не суть.
Очистка происходит с предположением, что предыдущий код не является чистым. На самом деле разработчики проводят рефакторинг своего кода, даже если исходный код уже чист.
СУХОЙ является ключевым фактором в рефакторинге.
При добавлении новых кодов в существующую кодовую базу рефакторинг выполняется естественным образом по принципу СУХОЙ.
Просто мой 0,02
источник
Очистка вашего кода - это как уборка вашего дома, рефакторинг - это как разрушение стены и, возможно, установка ее в другом месте
источник
Когда кто-то еще убирает ваш дом, вы ничего не можете найти, потому что цель - убрать вещи с дороги. Рефакторинг построил бы и обозначил комнаты, шкафы, шкафы, полки, мусорные ведра и т. Д. Он по-прежнему вмещает в себя почти все то же самое (вы все равно можете приготовить бутерброд с сыром на гриле и съесть его в гостиной), но он должен сделать это. легче найти и, возможно, иметь эффективные места для размещения новых вещей.
источник
Термин «рефакторинг» элегантно заимствован из алгебры. Это означает упрощение условий для получения одинакового результата. Он был не только элегантным, но и революционным - он требовал жесткого конечного подхода к вашему коду на уровне, который многих удивил. И поэтому сам термин был значительным и полезным.
источник
Нет. Рефакторинг - это улучшение структуры без изменения поведения. Рефакторинг в строгом смысле влечет за собой хорошую тестовую дисциплину. Это не обязательно требуется, когда вы «убираете вещи».
источник
Они немного пересекаются по краям, но для меня это разница между уборкой дома и реконструкцией дома. Очистка, для меня, не подразумевает структурных изменений, в то время как рефакторинг делает.
источник
«Рефакторинг» - это то же самое, что и «реархитектура», но с более сильным значением «никаких изменений в функциональности». Это также более понятно с точки зрения цели ре-архитектуры, которая часто состоит в том, чтобы «разложить» общий код на куски многократного использования.
источник