Здравствуйте, igor-booch, Вы писали:
IB>Рефакторинг требует дополнительных трудозатрат.
Излишняя гибкость архитектуры тоже. Поэтому надо не пытаться прыгнуть выше головы, пытаясь сделать архитектуру, готовую к любым изменениям требований, а писать код так, чтобы его было как можно легче рефакторить.
IB>Зная варианты развития системы
Варианты развития системы в 99.99% случаев знать невозможно.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, igor-booch, Вы писали:
I>>Надо полагать, тебе известен способ как добиться этого без переписывания и без рефакторинга ? Поделись пулькой что ли ?
IB>Добро и зло относительно, как все остальное в мире.
Видишь, как всё просто. А рефакторинг это не добро и не зло, это просто инструмент для безопасного изменения структуры кода.
I>Видишь, как всё просто. А рефакторинг это не добро и не зло, это просто инструмент для безопасного изменения структуры кода.
Так инструментальность тоже относительна. Относительно абстрактного человека топор несомненно инструмент. Он может топором и дом построить и разрушить что-нибудь.
Но сам топор не будет в виноват в разрушениях. И построенный дом не будет заслугой топора (разве что может быть заслугой мастера, который сделал хороший топор)
А вот относительно дерева, которое человек срубит топором, топор будет злом (вместе с человеком, который им орудует)
Если топор в руках у злого человека, то относительно других людей топор, тоже можно считать злом (как и злой человек), а не просто инструментом.
Если топор в руках у мастера, который строит дом, то топор и мастер будут добром, относительно людей, которые будут жить в доме.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
I>>Видишь, как всё просто. А рефакторинг это не добро и не зло, это просто инструмент для безопасного изменения структуры кода.
IB>Так инструментальность тоже относительна.
Проще инструмент рассматривать как инструмент. Тогда можно говорить о том, правильно ли он выбран или нет. А если рассматривать относительно чего чем же он является, то к результату можно и не подобраться.
I>Проще инструмент рассматривать как инструмент. Тогда можно говорить о том, правильно ли он выбран или нет. А если рассматривать относительно чего чем же он является, то к результату можно и не подобраться.
То что рефакторинг может быть добром, я показал в этом сообщении
. Рефракторинг позволяет скомпенсировать частичную ложность сведений о требованиях к системе. Но рефакториг может быть и злом. Для говнокодера он может служить оправданием убежденности "сделаю сейчас как получится, а потом порефачу (если манагер даст время)". Для говноаналитика рефакторинг может служить оправданием "а зачем мне сейчас тут анализировать, все равно прогеры порефачат потом если что".
То есть относительно абстрактного программиста и аналитика рефакторинг несомненно инструмент. Но чем больше мы конкретизируемся до конкретных аналитиков и программистов, до конкретных проектов, до конкретных ситуаций на проекте, тем больше рефакторинг превращается в добро или зло.
Если сказать тоже самое культурным языком: рефакторинг не стимулирует к улучшению качества кодирования и аналитики. А без стимулов прогрер может расслабиться и стать говнокодером, (аналитик говноаналитиком). Если в команде рефакторинг будет доминирующей техникой, то система дестабилизируется,выйдет из динамического равновесия (декомпенсация). Рефакторинг может стать доминирующей техникой, если в команде доминируют говнокодеры и говноаналитики. Получается замкнутый круг. Поэтому для стабилизации системы необходимы другие стимулы для улучшения качества кодирования и аналитики. Полностью разорвать замкнутый круг могут только абсолютно истинные (неизменные) знания о требованиях системе. Что невозможно. Поэтому только стабилизация (взимокомпенсация), которой должен заниматься манагер.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали: I>>Проще инструмент рассматривать как инструмент. Тогда можно говорить о том, правильно ли он выбран или нет. А если рассматривать относительно чего чем же он является, то к результату можно и не подобраться. IB>То что рефакторинг может быть добром, я показал в этом сообщении
. Рефракторинг позволяет скомпенсировать частичную ложность сведений о требованиях к системе.
ИМХО, рефакторинг имеет весьма косвенное отношение к требованиям.
В целом, относительно требований, есть две крайности: 1)Собираем всю-всю информацию и только затем начинаем писать код, 2)Сразу начинаем писать код, и по ходу разбираемся что к чему. А истина как всегда где-то посредине
Ну а рефакторинг это не зло и не добро и не средство борьбы с некорректными требованиями, это инструмент, при правильном применении позволяющий экономить время программистов. И в целом его имеет смысл применять только если: затраты_на_разработку + затраты_на_рефакторин + затраты_на_поддержку < затраты_на_разработку + затраты_на_поддержку. Эти три переменные сильно-сильно зависят от проекта и от программиста(например я считаю что лучше разделять код на небольшие кусочки, каждый из которых писать по принципу "написал — забыл", а в случае необходимости заменять кусочек целиком, т.е. я стараюсь писать "одноразовый" код). IB>Но рефакториг может быть и злом. Для говнокодера он может служить оправданием убежденности "сделаю сейчас кое-как, а потом порефачу (если манагер даст время)". Для говноаналитика рефакторинг может служить оправданием "а зачем мне сейчас тут анализировать, все равно прогеры порефачат потом если что".
Это определённо кадровые проблемы IB>То есть относительно абстрактного программиста и аналитика рефакторинг несомненно инструмент. Но чем больше мы конкретизируемся до конкретных аналитиков и программистов, до конкретных проектов, до конкретных ситуаций на проекте, тем больше рефакторинг превращается в добро или зло.
ИМХО, вы путаете сам инструмент и последствия его использования... IB>Если сказать тоже самое культурным языком: рефакторинг не стимулирует к улучшению качества кодирования и аналитики.
...а так же причину и следствие.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
IB>Потом появляются мелкие различия в логике работа с физическими и юридическими лицами.
Так ними работают по разному. Фокус должен быть направлен на реюзабельность функционала общего для всех, а не на сами понятия физиков и юриков.
Не стоит обвинять практику повторного использования, когда ошибка заложена ещё на этапе проектирования.
Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы.
То что выделено, IMHO, рефакторинг.
CAB>Это определённо кадровые проблемы
Я пытаюсь рассмотреть всю систему в целом, то есть рефакторинг не просто сам по себе, а в контексте менеджмента.
CAB>А истина как всегда где-то посредине
Согласен, каскадная модель это длинные по времени итерации, итеративная короткие. Разница в количестве времени, которая переходит в качество. На практике итерации могут быть средними по времени и соответственно может использоваться смесь из каскадных и итеративных техник.
CAB>...а так же причину и следствие.
При рассмотрении системы в целом с точки зрения равновесия, разделение на причину и следствие затруднительно. Представите весы на двух чашах, которых гири с одинаковым весом. И поразмышляйте здесь над причинами и следствиями. Уйдете в бесконечную рекурсию. Почему правая чаша не поднимается вверх? Потому что гиря на левой чаше давит вниз. А если она давит вниз почему правая чаша вверх не поднимается? ... Постройте физическую модель уравновешивания таких весов. Они у Вас будут бесконечно колебаться около положения равновесия, колебания буду бесконечно затухать. В реальности эти колебания не важны. Важно равновесие.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
IB>Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. IB>То что выделено, IMHO, рефакторинг.
Не, это не рефакторинг, я не нашёл подходящего термина, но ближе всего это к реинженерингу. CAB>>...а так же причину и следствие. IB>При рассмотрении системы в целом с точки зрения равновесия, разделение на причину и следствие затруднительно.
Очевидно равновесие это стояние, которое может быть следствие или причиной.
PS: Когда вы сделали какой-то вывод(навроде "Рефракторинг позволяет скомпенсировать частичную ложность сведений о требованиях к системе."), _не_спешите_ делать следующий(навроде "Рефакторинг может стать доминирующей техникой, если в команде доминируют говнокодеры и говноаналитики."), проверьте свой вывод. Алсо на Cousera есть релевантный курс(первая часть), очень рекомендую.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
IB>>Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. IB>>То что выделено, IMHO, рефакторинг. CAB>Не, это не рефакторинг, я не нашёл подходящего термина, но ближе всего это к реинженерингу.
Реинжиниринг программного обеспечения — процесс создания новой функциональности или устранения ошибок, путём революционного изменения, но используя уже имеющееся в эксплуатации программное обеспечение.
Чем длиннее итерации по времени, тем более революционные изменения надо вносить. При коротких итерациях изменения IMHO эволюционные. Рефакторинг ближе к эволюционным изменениям. А короткие итерации ближе к итерационному подходу.
CAB>PS: Когда вы сделали какой-то вывод(навроде "Рефракторинг позволяет скомпенсировать частичную ложность сведений о требованиях к системе."), _не_спешите_ делать следующий(навроде "Рефакторинг может стать доминирующей техникой, если в команде доминируют говнокодеры и говноаналитики."), проверьте свой вывод.
Говноаналитики увеличивают % ложных сведений о требованиях к системе, тем самым увеличивают потребности в рефакторинге. Говнокодеры пишут плохой код, который нужно рефачить.
CAB>>>...а так же причину и следствие. IB>>При рассмотрении системы в целом с точки зрения равновесия, разделение на причину и следствие затруднительно. CAB>Очевидно равновесие это стояние, которое может быть следствие или причиной.
Правильно. Равновесие это следствие всех процессов происходящих в системе в совокупности.
CAB>Алсо на Cousera есть релевантный курс(первая часть), очень рекомендую.
спасибо
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Рефракторинг позволяет скомпенсировать частичную ложность сведений о требованиях к системе.
Ты неправильно понимаешь значение термина рефакторинг. Рефакторинг не изменяет функциональные свойства кода, поэтому не в состоянии компенсировать никакие изменения требований. Изменение требований компенсирует нормальная эволюция кода, а рефакторинг лишь позволяет сделать эти изменения как можно более дешевыми и безболезненными.
IB>Для говнокодера он может служить оправданием убежденности "сделаю сейчас как получится, а потом порефачу (если манагер даст время)".
Э нет. Говнокодер это когда "сделаю как нибудь, а потом может само рассосется". А если человек о рефакторинге думает, то это далеко не говнокодер.
IB> Для говноаналитика рефакторинг может служить оправданием "а зачем мне сейчас тут анализировать, все равно прогеры порефачат потом если что".
Аналитику вообще наличие/отсутствие рефакторинга абсолютно параллельно.
IB>Если сказать тоже самое культурным языком: рефакторинг не стимулирует к улучшению качества кодирования
Он не то чтобы стимулирует, он напрямую направлен на улучшение качества кодирования.
IB>А без стимулов прогрер может расслабиться и стать говнокодером
Странное у тебя понимание работы программиста, очень странное.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>Ты неправильно понимаешь значение термина рефакторинг. Рефакторинг не изменяет функциональные свойства кода,
Согласен, рефакторинг не изменяет функциональные свойства кода.
Расскажу поподробнее как я понимаю рефакторинг,
Аналитик описал требования A к системе,
Программисты по этим требованиям построили архитектуру приложения, написали код
Далее аналитик изменил требования к системе и добавил новые, получились требования A'B
Он в принципе мог сразу дать программистам требования A'B, но в силу разных причин не смог, поэтому требования A рассматриваю как ложные
Архитектура программы не рассчитана на те изменения, которые произошли в требованиях A, а также на добавление требований B Не рассчитана, значит, что реализации требований A'B, для архитектуры построенной по требованиям A, выливается в клепание заплаток.
Заплатки — это код который имеет признаки плохого кода
Чтобы избежать заплаток, нужно поменять архитектуру приложения. Это изменение архитектуры и есть рефракторинг.
Тогда требования A'B можно будет реализовать без заплаток.
То есть после рефакторинга мы получаем систему, архитектура которой построена с учетом требований A'B.
После этого требования A'B можно реализовать без заплаток.
Если бы рефакторинг не скомпенсировал ложность требований к системе, в коде были бы заплатки.
Но по мере расширения системы, изменять её архитектуру становится все сложнее и сложнее, компенсаторных возможностей рефакторинга может не хватить, возникает декомпенсация (см. http://rsdn.ru/forum/philosophy/5196717.1
IB>>Для говнокодера он может служить оправданием убежденности "сделаю сейчас как получится, а потом порефачу (если манагер даст время)". AVK>Э нет. Говнокодер это когда "сделаю как нибудь, а потом может само рассосется". А если человек о рефакторинге думает, то это далеко не говнокодер.
Для абсолютно честного программиста это верно. Но люди ленивые и подвержены соблазнам...
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Согласен, рефакторинг не изменяет функциональные свойства кода. IB>Расскажу поподробнее как я понимаю рефакторинг,
Зачем? Если оно отличается от общепринятого, предлагаю его сразу исключить из разговора.
IB>Если бы рефакторинг не скомпенсировал ложность требований к системе, в коде были бы заплатки.
Вывод неверный. Если бы рефакторинга не было, изменение было бы дороже. А уж к чему там в конечном итоге пришли бы — к изменению архитектуры или к заплаткам, это вопрос отдельный.
AVK>>Э нет. Говнокодер это когда "сделаю как нибудь, а потом может само рассосется". А если человек о рефакторинге думает, то это далеко не говнокодер. IB>Для абсолютно честного программиста это верно. Но люди ленивые и подвержены соблазнам...
Я на практике подобного ни разу не наблюдал. А ты?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
IB>>Если бы рефакторинг не скомпенсировал ложность требований к системе, в коде были бы заплатки. AVK>Вывод неверный. Если бы рефакторинга не было, изменение было бы дороже.
А вот это не факт, дешевле может оказаться заплатка (например, дублирование кода — тема топика).
Цель разработки создание системы отвечающей требованиям наименьшими трудозатратами.
Дешевле может оказаться немного продублировать код, чем перелопачивать всю систему.
Дешевле даже в долгосрочной перспективе.
Хотя бывает дешевле в краткосрочной перспективе, но дороже в долгосрочной.
Это уже руководитель должен решать что дороже или дешевле и в какой перспективе.
В любом случае — главное минимизация трудозатрат и максимизация результата.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>А вот это не факт
Факт. Иначе это неправильный рефакторинг, негодный.
IB>, дешевле может оказаться заплатка (например, дублирование кода — тема топика).
При чем тут вообще заплатка? Рефакторинг удешевляет внесение изменений в функционал. Окупится ли сумма рефакторинг+изменение, тут да, возможны варианты, а вот изменение кода после рефакторинга обязано быть гарантированно дешевле, чем без него.
IB>Цель разработки создание системы отвечающей требованиям наименьшими трудозатратами. IB>Дешевле может оказаться немного продублировать код, чем перелопачивать всю систему.
Не все системы делаются в режиме "сделал и забыл" по никогда не изменяющейся спецификации. Большинство все таки довольно долго развивается, и тут уже надо учитывать долговременные последствия заплаток. Опять же, наличие заплаток никак не отменяет рефакторинга.
IB>Это уже руководитель должен решать что дороже или дешевле и в какой перспективе.
Эт смотря какой руководитель. У руководителя проекта в целом может просто не хватать нужной компетенции, к примеру.
IB>В любом случае — главное минимизация трудозатрат и максимизация результата.
Верно. И с этой точки зрения подход с постоянным рефакторингом себя оправдывает. И тем больше оправдывает, чем дольше живет код и чем выше требования к качеству продуктов.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>Рефакторинг удешевляет внесение изменений в функционал. Окупится ли сумма рефакторинг+изменение, тут да, возможны варианты, а вот изменение кода после рефакторинга обязано быть гарантированно дешевле, чем без него.
Согласен со всем,
сделаю не большой уточнение.
Вопрос еще в том сколько будет этих изменений кода предполагается в будущем. Если мало, то рефакторинг может не окупиться, если много, то конечно окупиться. Предположим сначала в программе был реализован только один вариант какого-либо алгоритма (поведения). Далее появилось требование, по которому требуется еще один вариант алгоритма (поведения). Тут можно сделать рефакторинг — использовать паттерн "Стратегия". Тогда если появятся еще 10 вариантов алгоритма их их добавление будет достигаться меньшими трудозатратами, чем если бы мы не применили паттерн "Стратегия". А если по здравому смыслу предполагается только 2 варианта алгоритма (поведения) и никак не больше? Тогда может быть дешевле не тратить силы на паттерн Стратегия, а поставить "заплатку" (if какой-нибудь в одной релизации алгоритма).
Рефакторинг — это капитальные затраты, которые уменьшают эксплуатационные затраты. Эксплуатационные затраты в данном примере это возможность добавления новых вариантов алгоритма (поведений).
Баланс между капитальными и эксплуатационными затратами это экономический и даже может политический вопрос. И с этой точки зрения рефакторинг не является абсолютным благом и абсолютной выгодой. Он может выгоден или не выгоден в зависимость от ситуации на проекте.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
IB>>Вопрос еще в том сколько будет этих изменений кода предполагается в будущем. AVK>Это практически всегда предсказать невозможно.
В начале проекта согласен очень трудно предсказывать.
С приближением к концу проекта,
когда реализована большая часть требований заказчика,
предсказывать становится легче.
Но если в начале проекта закладываться на все возможные изменения требований и новые требования, можно не успеть выполнить сами требования.
Вот такой парадокс. Руководство проектом это искусство.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
AVK>>Рефакторинг удешевляет внесение изменений в функционал. Окупится ли сумма рефакторинг+изменение, тут да, возможны варианты, а вот изменение кода после рефакторинга обязано быть гарантированно дешевле, чем без него. IB>Вопрос еще в том сколько будет этих изменений кода предполагается в будущем. Если мало, то рефакторинг может не окупиться, если много, то конечно окупиться.
Рефакторинг готовит код к уже известным изменениям. Т.е. вот они новые требования, и чтобы их реализовать нужно подготовить систему, т.е. провести рефакторинг.
Будущие изменения требований учитывает процесс проектирования и дизайна. Если вы собираетесь менять (рефакторить) систему под будущие неизвестные требования, то я не знаю чем у вас там менеджер и тимлид занят.
IB> Предположим сначала в программе был реализован только один вариант какого-либо алгоритма (поведения). Далее появилось требование, по которому требуется еще один вариант алгоритма (поведения). Тут можно сделать рефакторинг — использовать паттерн "Стратегия". Тогда если появятся еще 10 вариантов алгоритма их их добавление будет достигаться меньшими трудозатратами, чем если бы мы не применили паттерн "Стратегия". А если по здравому смыслу предполагается только 2 варианта алгоритма (поведения) и никак не больше? Тогда может быть дешевле не тратить силы на паттерн Стратегия, а поставить "заплатку" (if какой-нибудь в одной релизации алгоритма).
If-рещение, это как раз прагматичное рещение, за которое я агитировал здесь
Поделись пулькой что ли ?
