Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
Миф 1. Рефакторинг не нужен или нужен очень редко.
Любой код имеет определенный цикл жизни, который в итоге завершается тем, что из-за запутанности кода его проще оказывается полность переписать. Единственным известным мне способом продлить жизненный цикл существующего кода является его рефакторинг.
Миф 2. Тщательное проектирование позволяет избавится от рефакторинга.
Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
Миф 3. Рефакторинг это упрощение кода.
На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Миф 4. Рефакторинг не возможен без специальных средств.
Это неверно, поскольку исходный код большинства современных языков уже является удобным представлением для ручного просмотра и модификации. Рефакторинг же не предполагает каких то особенных операций с кодом, не встречающихся в обычном программировании. А для языков со статической типизацией компилятор к тому же оказывает существенную помощь в отслеживании ошибок при рефакторинге.
Миф 5. Специальные средства для рефакторинга не нужны.
Это тоже неверно, поскольку рефакторинг вносит небольшое количество информации (функционал сразу после рефакторинга остается прежним). Следовательно большая часть работы вполне поддается автоматизации, поэтому специальные средства могут значительно ускорить процедуру.
Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
На самом деле современные средства автоматизации хорошо работают только в простейших случаях — переименовании сущностей, смены сигнатуры, вынесении кода в отдельный метод. Для сложных процедур рефакторинга значительно больше возможных вариаций, и обеспечить хорошее покрытие потребностей небольшим количеством автоматизированных процедур крайне сложно.
Миф 7. Рефакторинг надо проводить как можно реже.
Чем раньше производить процедуру рефакторинга, тем меньшее количество кода придется править, так что затягивать до последнего нестоит.
Миф 8. Рефакторинг надо проводить как можно чаще.
Это тоже крайность, далекая от оптимума. Рефактироить имеет смысл только относительно стабильный код. Попытки рефакторить нестабильный код скорее всего просто бессмысленны из-за неопределенности, не позволяющей сразу спроектировать близкое к оптимуму решение.
AndrewVK -> "Мифы о рефакторинге"
A> Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей A> профессиональной деятельности оказались мифами.
Здравствуйте, AndrewVK, Вы писали:
AVK>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Здравствуйте, prVovik, Вы писали:
AVK>>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга. V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Поэтому и написано "как правило". В м оей практике чаще всего это все же усложнение.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Тут ведь как... Архитектуры различаются по 3 признакам:
1) Кривая и прямая, кривая соответственно кривыми руками делается.
2) Соответствующая функционалу или нет.
3) Простая и сложная. Сложная это в смысле более абстрактная, более generic, более хитрая, но проще в таком коде разобраться если прямыми руками делалось, и по объему он как правлило гораздо меньше. Но сложная архитектура может содержать больше ограничний и больше риск нарваться на грабли. В результате рефакторинга к сложной архитектуре приходить безопаснее чем изначально под нее затачиваться.
Сложная архитектура, как правило более нелинейная по отношению к функционалу: можно сложнейший кусок нового функционала привинтить за пару секунд, а можно на другом примитивнейшем кусочке функционала получить граблями по носу. Тут главное не промахнуться, все мелочи учесть при усложнении.
Здравствуйте, AndrewVK, Вы писали: AVK>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
Help will always be given at Hogwarts to those who ask for it.
AVK>Миф 3. Рефакторинг это упрощение кода. AVK>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Миф и то и другое. Рефакторинг может быть как упрощением так и усложнением кода (без "как правило").
Например, в рамках TDD работает такая схема:
1. Зарефакторить имеющийся код для облегчения реализации новой функциональности
2. Описать требования для новой функциональности в виде тестов
3. Реализовать требования простейшим способом (локальный оптимум)
4. Зарефакторить приложение к простейшему виду (глобальный оптимум)
Как видно, рефакторинг может применяться либо проактивно, либо реактивно. В первом случае он загодя формирует необходимый дизайн, во втором случае он формирует дизайн по факту возникновения "некрасивых" решений (так называемых code smells).
В первом случае рефакторинг изначально вводит более сложный дизайн (как правило). Во втором случае сложности могут начинаться на этапе реализации, а конечный рефакторинг все может упростить исключив дублирование, заменив условия полиморфизмом и т.д.
Все еще зависит от того, как определить понятие "упрощение кода". Какой код проще, у которого меньше классов, но больше строк или наоборот, и на каком диапазоне?
Вполне логично предположить, что проще тот, который легче читать и понимать.
Если будет мало классов, но много кода, то придется вникать в код для понимания сути происходящего. Если же классов станет слишком много, то возникнет неразбериха, что тоже нехорошо. Значит должно быть какое-то "золотое сечение" дизайна, например 7:1. Т.е. утрированно — семь строк на метод, семь методов на класс и т.д.
Значит не каждый рефакторинг, увеличивающий количество классов является усложнением? Тот, который приближает соотношение к "золотому сечению" явно можно назвать упрощением.
Твое суждение, что рефакторинг усложняет код (как правило), по-видимому является отражением того факта, что ты предпочитаешь рефакторить до реализации новой функциональности.
Другие разработчики могут предпочитать реактивный рефакторинг, соответственно они будут говорить об упрощении кода.
Лично у меня эти стратегии выбираются неосознанно автоматически в зависимости от проекта и инструментов.
AVK>Миф 8. Рефакторинг надо проводить как можно чаще. AVK>Это тоже крайность, далекая от оптимума. Рефактироить имеет смысл только относительно стабильный код. Попытки рефакторить нестабильный код скорее всего просто бессмысленны из-за неопределенности, не позволяющей сразу спроектировать близкое к оптимуму решение.
Вообще у всякой практики имеется своя область применения и допущения. Например правило частого рефакторинга было введено в контексте XP и TDD в частности. А там для него есть фундамент в виде test-first и необходимость в виде simplest thing.
Практика TDD направлена на "выращивание" дизайна из требований, реализованный в коде — Test-Driven Development. Где частый рефакторинг главным иструментом получения оптимального дизайна для данной ситуации.
Много раз наблюдалось на практике, как затягивание рефакторинга увеличивало усилия по разработке и в конце концов вынуждало проводить Большой Рефакторинг или забивать на хороший дизайн.
Не совсем понятно против чего направлено высказывание из заголовка. Против частого рефакторинга в любом контексте? Разумно. Попробуй часто порефактори JavaScript без тестов.
Необходимым условием проведения частых рефакторингов является наличие адекватного покрытия тестами. Кто применяет правило вне этого контекста, действует на свой страх и риск.
Так что данный миф скорее является примером misuse.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, AndrewVK, Вы писали: AVK>>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
_FR>А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
После долгой практики применение рефакторинга происходит автоматически оптимальным образом. И эти "мифы" можно придумать глядя как пробуют рефакторить другие.
Как всегда, в таких материалах прежде всего заинтересованы начинающие, а кто освоил, тому уже менее интересно. Поэтому и ощущается недостача полной и всеобъемлющей информации о внедрении той или иной практики.
Здравствуйте, _FRED_, Вы писали:
AVK>>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
_FR>А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
Да вот бывает. Кое что я почерпнул даже из этого форума.
Здравствуйте, prVovik, Вы писали:
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Здравствуйте, _vovin, Вы писали: _>После долгой практики применение рефакторинга происходит автоматически оптимальным образом. И эти "мифы" можно придумать глядя как пробуют рефакторить другие.
Спасибо, буду практиковаться. Пока что некоторые места каждые полтора месяца переделываю. Хотя теперь знаю почему: AVK>структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
_>Как всегда, в таких материалах прежде всего заинтересованы начинающие, а кто освоил, тому уже менее интересно. Поэтому и ощущается недостача полной и всеобъемлющей информации о внедрении той или иной практики.
Мне показалось, что следующее: AVK>Миф 4. Рефакторинг не возможен без специальных средств. AVK>Миф 5. Специальные средства для рефакторинга не нужны. AVK>Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
AVK>Миф 7. Рефакторинг надо проводить как можно реже. AVK>Миф 8. Рефакторинг надо проводить как можно чаще.
скорее собьёт толку "начинающих" — тут нужен такой подход, как у Фаулера — делайте так и так и пользуйтесь этим (образно говоря), потому что понять справедливость доказательства "от противного" возможно, ИМХО, только погуляв долго по неверным дорожкам и набивши на них шишек, то есть не раз попробовав сделать не так, так надо. Ну а тем, кто "освоил", как ты сказал, "тому уже менее интересно".
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, prVovik, Вы писали:
V>>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
V>Интересно, а с чем несогласен Lloyd?
С тем, что "Рефакторинг — это оптимизация архитектуры/дизайна".
Здравствуйте, prVovik, Вы писали:
AVK>>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга. V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Согласен. Но посмотри на выделенные жирным куски утверждения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Поэтому и написано "как правило". В м оей практике чаще всего это все же усложнение.
А я как раз больше рефакторинг использую, чтобы причесать код. Без глубоких архитектунных мыслей.
Наличие средств автоматизации рефакторинга позволяет работать в исследовательской монере. Пришла идея... попробовал реализовать не сильно задумываясь о стройности архитектуры и красоте кода... проестировал верность исходной идеи... отрефактори все так чтобы все было касиво и не противоричиво.
Таким образом рефакторинг становится средством решения ложных исследовательских задач которые невозможно (или очень трудно) сразу распланировать и реализовать как надо.
При этом код скорее упрощается. Хотя опять же каковы критерии простоты/сложности. Например, количество методов обычно увеличивается, но их размер уменьшается. Я это считаю упрощением, так как это позволяет более просто воспринимать код.
Хотя конечно иногда понимашь, что ошибся и нужно что-то сделать иначе. Вот тут рефакториг действительно за частую усложняет код.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AndrewVK,
> Миф 2. Тщательное проектирование позволяет избавится от рефакторинга. > Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Миф 2''. Рефакторинг всегда возможен
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами: ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Есть мнение, что рефакторинг — это и есть составляющая процесса тщательного проектирования.
