Мифы о рефакторинге
18.11.2004
|
AndrewVK
 |
Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
Миф 1. Рефакторинг не нужен или нужен очень редко.
Любой код имеет определенный цикл жизни, который в итоге завершается тем, что из-за запутанности кода его проще оказывается полность переписать. Единственным известным мне способом продлить жизненный цикл существующего кода является его рефакторинг.
Миф 2. Тщательное проектирование позволяет избавится от рефакторинга.
Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
Миф 3. Рефакторинг это упрощение кода.
На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Миф 4. Рефакторинг не возможен без специальных средств.
Это неверно, поскольку исходный код большинства современных языков уже является удобным представлением для ручного просмотра и модификации. Рефакторинг же не предполагает каких то особенных операций с кодом, не встречающихся в обычном программировании. А для языков со статической типизацией компилятор к тому же оказывает существенную помощь в отслеживании ошибок при рефакторинге.
Миф 5. Специальные средства для рефакторинга не нужны.
Это тоже неверно, поскольку рефакторинг вносит небольшое количество информации (функционал сразу после рефакторинга остается прежним). Следовательно большая часть работы вполне поддается автоматизации, поэтому специальные средства могут значительно ускорить процедуру.
Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
На самом деле современные средства автоматизации хорошо работают только в простейших случаях — переименовании сущностей, смены сигнатуры, вынесении кода в отдельный метод. Для сложных процедур рефакторинга значительно больше возможных вариаций, и обеспечить хорошее покрытие потребностей небольшим количеством автоматизированных процедур крайне сложно.
Миф 7. Рефакторинг надо проводить как можно реже.
Чем раньше производить процедуру рефакторинга, тем меньшее количество кода придется править, так что затягивать до последнего нестоит.
Миф 8. Рефакторинг надо проводить как можно чаще.
Это тоже крайность, далекая от оптимума. Рефактироить имеет смысл только относительно стабильный код. Попытки рефакторить нестабильный код скорее всего просто бессмысленны из-за неопределенности, не позволяющей сразу спроектировать близкое к оптимуму решение.
Миф 1. Рефакторинг не нужен или нужен очень редко.
Любой код имеет определенный цикл жизни, который в итоге завершается тем, что из-за запутанности кода его проще оказывается полность переписать. Единственным известным мне способом продлить жизненный цикл существующего кода является его рефакторинг.
Миф 2. Тщательное проектирование позволяет избавится от рефакторинга.
Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
Миф 3. Рефакторинг это упрощение кода.
На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Миф 4. Рефакторинг не возможен без специальных средств.
Это неверно, поскольку исходный код большинства современных языков уже является удобным представлением для ручного просмотра и модификации. Рефакторинг же не предполагает каких то особенных операций с кодом, не встречающихся в обычном программировании. А для языков со статической типизацией компилятор к тому же оказывает существенную помощь в отслеживании ошибок при рефакторинге.
Миф 5. Специальные средства для рефакторинга не нужны.
Это тоже неверно, поскольку рефакторинг вносит небольшое количество информации (функционал сразу после рефакторинга остается прежним). Следовательно большая часть работы вполне поддается автоматизации, поэтому специальные средства могут значительно ускорить процедуру.
Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
На самом деле современные средства автоматизации хорошо работают только в простейших случаях — переименовании сущностей, смены сигнатуры, вынесении кода в отдельный метод. Для сложных процедур рефакторинга значительно больше возможных вариаций, и обеспечить хорошее покрытие потребностей небольшим количеством автоматизированных процедур крайне сложно.
Миф 7. Рефакторинг надо проводить как можно реже.
Чем раньше производить процедуру рефакторинга, тем меньшее количество кода придется править, так что затягивать до последнего нестоит.
Миф 8. Рефакторинг надо проводить как можно чаще.
Это тоже крайность, далекая от оптимума. Рефактироить имеет смысл только относительно стабильный код. Попытки рефакторить нестабильный код скорее всего просто бессмысленны из-за неопределенности, не позволяющей сразу спроектировать близкое к оптимуму решение.
... << RSDN@Home 1.1.4 beta 3 rev. 232>>
| 18.11.2004 53 комментария |
A> Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей
A> профессиональной деятельности оказались мифами.
imho это уэе где то было. нет?
Yury Kopyl aka hrg | Гордость мешает доходам!
hrg>imho это уэе где то было. нет?
Было конечно, у меня в голове.
AVK>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
AVK>>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Поэтому и написано "как правило". В м оей практике чаще всего это все же усложнение.
AVK>Поэтому и написано "как правило". В м оей практике чаще всего это все же усложнение.
А я как раз больше рефакторинг использую, чтобы причесать код. Без глубоких архитектунных мыслей.
Наличие средств автоматизации рефакторинга позволяет работать в исследовательской монере. Пришла идея... попробовал реализовать не сильно задумываясь о стройности архитектуры и красоте кода... проестировал верность исходной идеи... отрефактори все так чтобы все было касиво и не противоричиво.
Таким образом рефакторинг становится средством решения ложных исследовательских задач которые невозможно (или очень трудно) сразу распланировать и реализовать как надо.
При этом код скорее упрощается. Хотя опять же каковы критерии простоты/сложности. Например, количество методов обычно увеличивается, но их размер уменьшается. Я это считаю упрощением, так как это позволяет более просто воспринимать код.
Хотя конечно иногда понимашь, что ошибся и нужно что-то сделать иначе. Вот тут рефакториг действительно за частую усложняет код.
V>Здравствуйте, AndrewVK, Вы писали:
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Тут ведь как... Архитектуры различаются по 3 признакам:
1) Кривая и прямая, кривая соответственно кривыми руками делается.
2) Соответствующая функционалу или нет.
3) Простая и сложная. Сложная это в смысле более абстрактная, более generic, более хитрая, но проще в таком коде разобраться если прямыми руками делалось, и по объему он как правлило гораздо меньше. Но сложная архитектура может содержать больше ограничний и больше риск нарваться на грабли. В результате рефакторинга к сложной архитектуре приходить безопаснее чем изначально под нее затачиваться.
Сложная архитектура, как правило более нелинейная по отношению к функционалу: можно сложнейший кусок нового функционала привинтить за пару секунд, а можно на другом примитивнейшем кусочке функционала получить граблями по носу. Тут главное не промахнуться, все мелочи учесть при усложнении.
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Интересно, а с чем несогласен Lloyd?
V>Здравствуйте, prVovik, Вы писали:
V>>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
V>Интересно, а с чем несогласен Lloyd?
С тем, что "Рефакторинг — это оптимизация архитектуры/дизайна".
L>С тем, что "Рефакторинг — это оптимизация архитектуры/дизайна".
Хм, а что же это тогда такое?
V>Хм, а что же это тогда такое?
Это просто изменение структуры кода и ничего более.
L>Здравствуйте, prVovik, Вы писали:
V>>Хм, а что же это тогда такое?
L>Это просто изменение структуры кода и ничего более.
Изменение просто так? А зачем структуру менять просто так?
V>Изменение просто так? А зачем структуру менять просто так?
Для облегчения внесения изменений.
V>Интересно, а с чем несогласен Lloyd?
Гы-гы. Ты лучше спроси с чем он бывает согласен?
AVK>>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Согласен. Но посмотри на выделенные жирным куски утверждения.
AVK>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
_FR>Здравствуйте, AndrewVK, Вы писали:
AVK>>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
_FR>А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
После долгой практики применение рефакторинга происходит автоматически оптимальным образом. И эти "мифы" можно придумать глядя как пробуют рефакторить другие.
Как всегда, в таких материалах прежде всего заинтересованы начинающие, а кто освоил, тому уже менее интересно. Поэтому и ощущается недостача полной и всеобъемлющей информации о внедрении той или иной практики.
_>После долгой практики применение рефакторинга происходит автоматически оптимальным образом. И эти "мифы" можно придумать глядя как пробуют рефакторить другие.
Спасибо, буду практиковаться. Пока что некоторые места каждые полтора месяца переделываю.
AVK>структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
_>Как всегда, в таких материалах прежде всего заинтересованы начинающие, а кто освоил, тому уже менее интересно. Поэтому и ощущается недостача полной и всеобъемлющей информации о внедрении той или иной практики.
Мне показалось, что следующее:
AVK>Миф 4. Рефакторинг не возможен без специальных средств.
AVK>Миф 5. Специальные средства для рефакторинга не нужны.
AVK>Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
AVK>Миф 7. Рефакторинг надо проводить как можно реже.
AVK>Миф 8. Рефакторинг надо проводить как можно чаще.
скорее собьёт толку "начинающих" — тут нужен такой подход, как у Фаулера — делайте так и так и пользуйтесь этим (образно говоря), потому что понять справедливость доказательства "от противного" возможно, ИМХО, только погуляв долго по неверным дорожкам и набивши на них шишек, то есть не раз попробовав сделать не так, так надо. Ну а тем, кто "освоил", как ты сказал, "тому уже менее интересно".
AVK>>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
_FR>А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
Да вот бывает. Кое что я почерпнул даже из этого форума.
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.
Ты бы лучше статейку про рефакторин написал. Вот цэ было бы дело.
V> Здравствуйте, AndrewVK, Вы писали:
V> Ты бы лучше статейку про рефакторин написал. Вот цэ было бы дело.
http://www.ozon.ru/context/detail/id/1308678/ Ж)
Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева
VD>Ты бы лучше статейку про рефакторин написал. Вот цэ было бы дело.
Не, статью не потяну. Тем более по такой флеймовой теме.
AVK>Не, статью не потяну. Тем более по такой флеймовой теме.
Так если не флэймить, а описать спринципы, возможности и т.п. то получилось бы очень нечего.
VD>Так если не флэймить, а описать спринципы, возможности и т.п. то получилось бы очень нечего.
Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
ДГ>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
Он по русски плохо пишет.
ДГ>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
И что ж теперь — эта тема для всех закрыта?
AVK>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
AVK>И что ж теперь — эта тема для всех закрыта?
Стоит прочитать книжку. Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
ДГ>>>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
AVK>>И что ж теперь — эта тема для всех закрыта?
M>Стоит прочитать книжку.
Я ее читал.
M> Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
Если они для тебя очевидны, это не значит что они очевидны всем.
M>Стоит прочитать книжку. Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
У Рихтера пол Виндовс описано и пол дотнета. Так что же теперь ВыньАпи и дотнетный форумы не читать что ли?
Читать, может и полезно, но и только.
> Миф 2. Тщательное проектирование позволяет избавится от рефакторинга.
> Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Миф 2''. Рефакторинг всегда возможен
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Есть мнение, что рефакторинг — это и есть составляющая процесса тщательного проектирования.
V>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
V>Есть мнение, что рефакторинг — это и есть составляющая процесса тщательного проектирования.
это составляющая процесса тщательного кодирования.
ПК>Миф 2''. Рефакторинг всегда возможен
А когда рефакторинг невозможен?
ПК>>Миф 2''. Рефакторинг всегда возможен
d> А когда рефакторинг невозможен?
При наличии субъективного фактора
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
hrg>dshe -> "Re[2]: Мифы о рефакторинге"
ПК>>>Миф 2''. Рефакторинг всегда возможен
d>> А когда рефакторинг невозможен?
hrg>При наличии субъективного фактора
Меня больше интересуют объективные факторы. Сформулирую вопрос по другому:
Бывают ли ситуации когда рефакторинг противопоказан? Какие это ситуации?
> ПК> Миф 2''. Рефакторинг всегда возможен
> А когда рефакторинг невозможен?
Например, далеко не всегда можно позволить себе рефакторинг, приводящий к изменению интерфейсов опубликованных библиотек.
>> ПК> Миф 2''. Рефакторинг всегда возможен
>> А когда рефакторинг невозможен?
ПК> Например, далеко не всегда можно позволить себе рефакторинг,
ПК> приводящий к изменению интерфейсов опубликованных библиотек.
Тут 2 варианта:
1. Если используем TDD, то менять можно как угодно, если покрытие тестами
достаточное
2. Можно сделать рефаторинг библиотеки, оставив неиспользованные интерфейсы
для поддержки
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
ПК>Например, далеко не всегда можно позволить себе рефакторинг, приводящий к изменению интерфейсов опубликованных библиотек.
Тут есть свои приемы, позволяющие обеспечить совместимость. Например провести рефакторинг, а старый интерфейс реализовать в качестве обертки. Так, к примеру, МС рефакторит GDI.
AVK>Тут есть свои приемы, позволяющие обеспечить совместимость. Например провести рефакторинг, а старый интерфейс реализовать в качестве обертки. Так, к примеру, МС рефакторит GDI.
откуда сведения, что они его рефакторят?
V>откуда сведения, что они его рефакторят?
http://longhorn.msdn.microsoft.com . Отрефакторенная версия GDI называется Aero.
V>откуда сведения, что они его рефакторят?
Из МСДН. Ищи функции с окончанием Ex.
VD>Здравствуйте, vdimas, Вы писали:
V>>откуда сведения, что они его рефакторят?
VD>Из МСДН. Ищи функции с окончанием Ex.
добавление новых ф-ий не есть рефакторинг
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
ПК>Миф 2''. Рефакторинг всегда возможен
Дык распиши почему это мифы, сделаем эдакий FAQ по рефакторингу.
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
ПК>Миф 2''. Рефакторинг всегда возможен
Ну, если их немного подкорректировать, то они даже перестанут буть мифмми.
Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
Миф 2''. Рефакторинг может быть частью процесса производства ПО.
VD>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
VD>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
Э, поясни, пожалуйста. Я вот например считаю рефакторинг неотъемлимой частью процесса производства ПО
VD>>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
VD>>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
_>Э, поясни, пожалуйста. Я вот например считаю рефакторинг неотъемлимой частью процесса производства ПО
А ты не квоть так сильно и пояснять не потребуется. Процетирую сам себя
>Ну, если их немного подкорректировать, то они даже перестанут буть мифмми.
VD>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
как соотносится прототип и рефакторинг?
или у тебя система из прототипа вырастает?
XP форевер?
VD>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
может или должен?
V>как соотносится прототип и рефакторинг?
V>или у тебя система из прототипа вырастает?
Ага. Более того. Я чем дальше теб больше делаю прототипы не приложения, а его частей. Надо решить некую проблемы... Обдумываю ее насколько это возможно в голове... Решаю ее как попало
На каждом из этапов то и дело возникает рефактиринг. Это конечно не ХР, но тоже себе подходец.
V>XP форевер?
Не, ХР слишком не экстримальный вид программирования. Мой скорее можно назвать ВП (взрывное программирование). Занимаюсь своими делами (не программированием)... приходит в голову мысль... и понеслась... за сутки недельная норма... А потом опять неделю другими делами. За-то за сутки могу перефигачить программу так что мама не узнает.
Надо бы заптентовать.
VD>>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
V>может или должен?
Дык это зависит от мировозрения и пригодности тех или иных подходов в данньой ситуации. Я сторонник не изобретать панацей. Иногда ту или иную задачу проще решить снизу-вверх и тогда скорее должно. А иногда наоборот.
Когда задачи скорее исследовательские, то скорее должно. А когда решается задача которую заранее понятно как решать, то чем его меньше, тем меньше лишнего времени. Да и вообще рефакторинг при этом уже указывает на просчеты.