Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
Миф 1. Рефакторинг не нужен или нужен очень редко.
Любой код имеет определенный цикл жизни, который в итоге завершается тем, что из-за запутанности кода его проще оказывается полность переписать. Единственным известным мне способом продлить жизненный цикл существующего кода является его рефакторинг.
Миф 2. Тщательное проектирование позволяет избавится от рефакторинга.
Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
Миф 3. Рефакторинг это упрощение кода.
На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Миф 4. Рефакторинг не возможен без специальных средств.
Это неверно, поскольку исходный код большинства современных языков уже является удобным представлением для ручного просмотра и модификации. Рефакторинг же не предполагает каких то особенных операций с кодом, не встречающихся в обычном программировании. А для языков со статической типизацией компилятор к тому же оказывает существенную помощь в отслеживании ошибок при рефакторинге.
Миф 5. Специальные средства для рефакторинга не нужны.
Это тоже неверно, поскольку рефакторинг вносит небольшое количество информации (функционал сразу после рефакторинга остается прежним). Следовательно большая часть работы вполне поддается автоматизации, поэтому специальные средства могут значительно ускорить процедуру.
Миф 6. Навороченные средства рефакторинга намного лучше средств, обеспечивающих базовый функционал.
На самом деле современные средства автоматизации хорошо работают только в простейших случаях — переименовании сущностей, смены сигнатуры, вынесении кода в отдельный метод. Для сложных процедур рефакторинга значительно больше возможных вариаций, и обеспечить хорошее покрытие потребностей небольшим количеством автоматизированных процедур крайне сложно.
Миф 7. Рефакторинг надо проводить как можно реже.
Чем раньше производить процедуру рефакторинга, тем меньшее количество кода придется править, так что затягивать до последнего нестоит.
Миф 8. Рефакторинг надо проводить как можно чаще.
Это тоже крайность, далекая от оптимума. Рефактироить имеет смысл только относительно стабильный код. Попытки рефакторить нестабильный код скорее всего просто бессмысленны из-за неопределенности, не позволяющей сразу спроектировать близкое к оптимуму решение.
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.
Здравствуйте, AndrewVK, Вы писали:
AVK>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга.
Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
AndrewVK,
> Миф 2. Тщательное проектирование позволяет избавится от рефакторинга. > Не существует идеальных архитекторов. Всегда будут ошибки проектирования. Следовательно — рефакторинг в ходе разработки это нормальный процесс, от которого не избавится. Но это еще не все — помимо ошибок проектирования всегда будет ситуация, когда структура кода не оптимальна из-за того что на момент проектирования существует некоторая неопределенность, от которой можно избавиться, только начав разработку.
В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Миф 2''. Рефакторинг всегда возможен
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Например, далеко не всегда можно позволить себе рефакторинг, приводящий к изменению интерфейсов опубликованных библиотек.
Тут есть свои приемы, позволяющие обеспечить совместимость. Например провести рефакторинг, а старый интерфейс реализовать в качестве обертки. Так, к примеру, МС рефакторит GDI.
Здравствуйте, prVovik, Вы писали:
AVK>>На самом деле рефакторинг, как правило, не упрощает, а усложняет код. Результатом рефакторинга становится большая масштабируемость кода и упрощение его поддержки ценой усложнения структуры и, часто, увеличением объема кода и количества сущностей сразу после рефакторинга. V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Поэтому и написано "как правило". В м оей практике чаще всего это все же усложнение.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, AndrewVK, Вы писали: AVK>>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
_FR>А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
После долгой практики применение рефакторинга происходит автоматически оптимальным образом. И эти "мифы" можно придумать глядя как пробуют рефакторить другие.
Как всегда, в таких материалах прежде всего заинтересованы начинающие, а кто освоил, тому уже менее интересно. Поэтому и ощущается недостача полной и всеобъемлющей информации о внедрении той или иной практики.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>В последнее время я, пожалуй, чаще встречаюсь с другими мифами: ПК>>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
V>Есть мнение, что рефакторинг — это и есть составляющая процесса тщательного проектирования.
это составляющая процесса тщательного кодирования.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
ПК>Миф 2''. Рефакторинг всегда возможен
Ну, если их немного подкорректировать, то они даже перестанут буть мифмми.
Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
Миф 2''. Рефакторинг может быть частью процесса производства ПО.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mikа, Вы писали:
ДГ>>>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
AVK>>И что ж теперь — эта тема для всех закрыта?
M>Стоит прочитать книжку.
Я ее читал.
M> Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
Если они для тебя очевидны, это не значит что они очевидны всем.
AndrewVK -> "Мифы о рефакторинге"
A> Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей A> профессиональной деятельности оказались мифами.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
V>Не согласен. Рефакторинг — это оптимизация архитектуры/дизайна. В результате такой оптимизации архитектура может как усложниться, так и упроститься. По-этому я бы не говорил, что рефакторинг — это усложнение, или упрощение. Бывает и так и эдак...
Тут ведь как... Архитектуры различаются по 3 признакам:
1) Кривая и прямая, кривая соответственно кривыми руками делается.
2) Соответствующая функционалу или нет.
3) Простая и сложная. Сложная это в смысле более абстрактная, более generic, более хитрая, но проще в таком коде разобраться если прямыми руками делалось, и по объему он как правлило гораздо меньше. Но сложная архитектура может содержать больше ограничний и больше риск нарваться на грабли. В результате рефакторинга к сложной архитектуре приходить безопаснее чем изначально под нее затачиваться.
Сложная архитектура, как правило более нелинейная по отношению к функционалу: можно сложнейший кусок нового функционала привинтить за пару секунд, а можно на другом примитивнейшем кусочке функционала получить граблями по носу. Тут главное не промахнуться, все мелочи учесть при усложнении.
Здравствуйте, AndrewVK, Вы писали: AVK>Хочу рассказать про несколько мнений о рефакторинге, кои в ходе моей профессиональной деятельности оказались мифами.
А кто эти мифы сочиняет? Я вот ни разу ни про один такой миф не слышал — наоборот, на каждом шагу твердят о положительных последствиях его проведения... Кому в конце-концов рефакторинг может помешать?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами: ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
Есть мнение, что рефакторинг — это и есть составляющая процесса тщательного проектирования.
Здравствуйте, hrg, Вы писали:
hrg>dshe -> "Re[2]: Мифы о рефакторинге"
ПК>>>Миф 2''. Рефакторинг всегда возможен
d>> А когда рефакторинг невозможен?
hrg>При наличии субъективного фактора
Меня больше интересуют объективные факторы. Сформулирую вопрос по другому:
Бывают ли ситуации когда рефакторинг противопоказан? Какие это ситуации?
Павел Кузнецов -> "Re[3]: Мифы о рефакторинге"
>> ПК> Миф 2''. Рефакторинг всегда возможен
>> А когда рефакторинг невозможен?
ПК> Например, далеко не всегда можно позволить себе рефакторинг, ПК> приводящий к изменению интерфейсов опубликованных библиотек.
Тут 2 варианта:
1. Если используем TDD, то менять можно как угодно, если покрытие тестами
достаточное
2. Можно сделать рефаторинг библиотеки, оставив неиспользованные интерфейсы
для поддержки
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В последнее время я, пожалуй, чаще встречаюсь с другими мифами:
ПК>Миф 2'. Рефакторинг может заменить собой тщательное проектирование
ПК>Миф 2''. Рефакторинг всегда возможен
Дык распиши почему это мифы, сделаем эдакий FAQ по рефакторингу.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, prVovik, Вы писали:
V>>Хм, а что же это тогда такое?
L>Это просто изменение структуры кода и ничего более.
Изменение просто так? А зачем структуру менять просто так?
Здравствуйте, AndrewVK, Вы писали:
AVK>Тут есть свои приемы, позволяющие обеспечить совместимость. Например провести рефакторинг, а старый интерфейс реализовать в качестве обертки. Так, к примеру, МС рефакторит GDI.
Здравствуйте, Lloyd, Вы писали:
L>Для облегчения внесения изменений.
А станет ли после этого архитектура более оптимальной, то есть улучшится ли она или ухудшится?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Дык с этим, кажись, Фаулер давно уже справился, на пять с плюсом.
AVK>И что ж теперь — эта тема для всех закрыта?
Стоит прочитать книжку. Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
Здравствуйте, VladD2, Вы писали:
VD>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
VD>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
Э, поясни, пожалуйста. Я вот например считаю рефакторинг неотъемлимой частью процесса производства ПО
Здравствуйте, VladD2, Вы писали:
VD>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
как соотносится прототип и рефакторинг?
или у тебя система из прототипа вырастает?
XP форевер?
VD>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
может или должен?
Здравствуйте, vdimas, Вы писали:
V>добавление новых ф-ий не есть рефакторинг
Так ты внуть загляни (под отладчиком). 90% старых функций являются оберткой над Ex. Ну, а в следующей версии виндовс они почти все станут обертками, так как рисовать будут в сменяемый контекст.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, serg_mo, Вы писали:
VD>>Миф 2'. Рефакторинг может являться частью процесса проектирования, а проектирование может быть совмещено с иследованиями и созданием прототипа.
VD>>Миф 2''. Рефакторинг может быть частью процесса производства ПО.
_>Э, поясни, пожалуйста. Я вот например считаю рефакторинг неотъемлимой частью процесса производства ПО
А ты не квоть так сильно и пояснять не потребуется. Процетирую сам себя
>Ну, если их немного подкорректировать, то они даже перестанут буть мифмми.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>как соотносится прототип и рефакторинг? V>или у тебя система из прототипа вырастает?
Ага. Более того. Я чем дальше теб больше делаю прототипы не приложения, а его частей. Надо решить некую проблемы... Обдумываю ее насколько это возможно в голове... Решаю ее как попало... Смотрю на результат... Переписываю по человечески... Смотрую еще раз... Переписываю еще лучше... В конце причесываю.
На каждом из этапов то и дело возникает рефактиринг. Это конечно не ХР, но тоже себе подходец.
V>XP форевер?
Не, ХР слишком не экстримальный вид программирования. Мой скорее можно назвать ВП (взрывное программирование). Занимаюсь своими делами (не программированием)... приходит в голову мысль... и понеслась... за сутки недельная норма... А потом опять неделю другими делами. За-то за сутки могу перефигачить программу так что мама не узнает.
Надо бы заптентовать.
VD>>Миф 2''. Рефакторинг может быть частью процесса производства ПО. V>может или должен?
Дык это зависит от мировозрения и пригодности тех или иных подходов в данньой ситуации. Я сторонник не изобретать панацей. Иногда ту или иную задачу проще решить снизу-вверх и тогда скорее должно. А иногда наоборот.
Когда задачи скорее исследовательские, то скорее должно. А когда решается задача которую заранее понятно как решать, то чем его меньше, тем меньше лишнего времени. Да и вообще рефакторинг при этом уже указывает на просчеты.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
M>> Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
AVK>Если они для тебя очевидны, это не значит что они очевидны всем.
Ты меня не понял. Я не говорю о очевидности или не очевидности. Если ты хочешь пересказать книгу своими словами, то это бессмысленно (надеюсь не нужно это объяснять). Если просто обмусолить тему, но в конце не подвести итог (а на форумах это или статья или ФАКУ, жетательно, отличающаяся контентом от вышепривиденной книги, иначе это будет плагиат и привидет к первому пути), то это трата времени, так как все доводы уйдут в туну.
Здравствуйте, mikа, Вы писали:
M>Стоит прочитать книжку. Многие моменты в ней уже были разобраны, так что не стоит открывать новых Америк или изобретать велосипеды. Тогда и воду отделили в этом топике, и не нужно было писать по пять раз столь очевидные вещи.
У Рихтера пол Виндовс описано и пол дотнета. Так что же теперь ВыньАпи и дотнетный форумы не читать что ли?
Читать, может и полезно, но и только.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mikа, Вы писали:
M>Ты меня не понял. Я не говорю о очевидности или не очевидности. Если ты хочешь пересказать книгу своими словами, то это бессмысленно (надеюсь не нужно это объяснять).
А разве я такое предлагал?
M> Если просто обмусолить тему, но в конце не подвести итог (а на форумах это или статья или ФАКУ, жетательно, отличающаяся контентом от вышепривиденной книги, иначе это будет плагиат и привидет к первому пути), то это трата времени, так как все доводы уйдут в туну.
Ну и? Вывод какой? Любая попытка написать о рефакторинге заведомо не имеет смысла, так что ли?
Если нам не помогут, то мы тоже никого не пощадим.
