Малосвязный саморекламный бред, а не мнение, имхо.
Все библиотеки и фреймворки — это reuse. Он и сам это, похоже, понимает, и чтоб не выглядеть совсем уж идиотом (хотя лучше для этого было бы просто не писать этот чудо-пост) он начинает разделять, где use, а где reuse, и делает это крайне неубедительно: это, мол, generic, а это — не generic, хотя это деление крайне зыбкое и очень сильно зависит от задачи. Потому что стоит спуститься на уровень ниже — и то, что было generic, быть таковым перестает и становится domain-specific. Он проводит дополнительную черту по domain-specific — извините, если у меня система с десятками компонентов, я какую-то domain-specific логику, которая у меня сейчас реюзается в виде библиотеки, должен просто скопипастить во все эти компоненты? Реюзать, по его мнению, нельзя — это же domain-specific!
Автор по большей части спорит сам с собой: сначала выдвигает спорное утверждение, что единственная настоящая цель повторного использования это скорость написания программ, затем пытается доказать, что это неверно, потому, что появляется много зависимостей и мы потеряем больше времени на отладке.
Потом занимается софистикой придумывая "правильные" определения "use" и "reuse" и делает из этого какие-то выводы.
На практике, любое повторное использование кода — это и польза и риск, которые должны быть оценены и принято соответствующее решение. Способ повторного использования (наследование, копирование, ссылка на существующий компонент...) тоже должен быть выбран осознано.
А если базироваться на абсолютистских позициях ("There’s this belief that if we just reused more code, everything would be better.", "We all want to get done faster. Way back when, someone told us reuse was the way to do that."), то можно и в выводах зайти достаточно далеко, например, решить что все вокруг дураки, а истина — вот она.
Взгляды на некоторые вещи у автора весьма неординарны
Например
If you wrote the code all in one place, there are no dependencies. By reusing code, you’ve created a dependency.
весьма спорное заявление.
И если подобные взгляды обсуждать под пиво, то это может быть очень даже интересно.
Но вот работать в команде, где такими взглядами руководствуются, я бы если честно не хотел
Здравствуйте, robin_of_the_wood, Вы писали:
___>Взгляды на некоторые вещи у автора весьма неординарны ___>Например ___>
___>If you wrote the code all in one place, there are no dependencies. By reusing code, you’ve created a dependency.
___>весьма спорное заявление. ___>И если подобные взгляды обсуждать под пиво, то это может быть очень даже интересно. ___>Но вот работать в команде, где такими взглядами руководствуются, я бы если честно не хотел
При определённых обстоятельствах это утверждение абсолютно верно во всех отношениях. Только вот обстоятельства эти не так просто определить.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>При определённых обстоятельствах это утверждение абсолютно верно во всех отношениях. Только вот обстоятельства эти не так просто определить.
Так то оно так, но вот на практике часто получается, что понапишут эдакого
all in one place
кода, а потом доказывают, что это и есть единственно верный путь, ссылаясь на подобные статьи.
Подобную ситуацию я кстати наблюдал с упоминанием знаменитейшей(и несомненно верной) фразы про зло ранней оптимизации.
Сама фраза однозначно верна, но вот чаще всего мне ее приходилось слышать от людей, которые просто не понимали разницу между передачей коллекций по ссылке и по значению(при полном отсутствии необходимости создания копии)
Здравствуйте, Ikemefula, Вы писали:
I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/
I>В свете последних дебатов по ООП, очень интересное мнение.
Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу максимальное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно.
Мое личное мнение: дизайн — это приколачивание гвоздями в одном месте для по повышения гибкости в другом.
Удачный дизайн — это когда приколотили гвоздями то, что менятся не будет и обеспечили гибкость там, где изменения вероятны.
Конкретно по реюзю: если реюзали какой-то кусок кода в нескольких местах, мы тем самым приколотли: "во всех этих местах используется тот же самый кусок функциональности". Что может быть не верным при развитие продукта (очередной CR потребует, чтобы этот кусок функционала был различным в этих нескольких местах). Т.е. тот факт, что этот кусок функционала повторяется в нескольких местах не является достаточным условием, чтобы его выделять в отдельный метод/класс/...
Здравствуйте, denisko, Вы писали: D>Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу максимальное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно. For the great justice! Отмечу — если одна и та же бабайка "приходит" к многим программистам то это уже вполне объективная бабайка.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>For the great justice! Отмечу — если одна и та же бабайка "приходит" к многим программистам то это уже вполне объективная бабайка.
Большинство бабаек объективно в том смысле, что приходили к многим программистам. Но есть тривиальный момент, бабайко-устойчивость стоит денег и надо понимать когда бабайка может прийти с достаточной вероятностью, а когда код умрет раньше (со временем вероятность прихода любой бабайки возрастает), что делает как бабайко-устойчивость, так и бабайко-неустойчивость относительным злом или добром. К автору недавно пришла вторая бабайка под названием "Я тут думаю, время идет, я нифига не успею,аааааа", на почве встречи двух бабаек случился когнитивный диссонанс, который вылился в статью.
Здравствуйте, robin_of_the_wood, Вы писали:
___>Подобную ситуацию я кстати наблюдал с упоминанием знаменитейшей(и несомненно верной) фразы про зло ранней оптимизации. ___>Сама фраза однозначно верна, но вот чаще всего мне ее приходилось слышать от людей, которые просто не понимали разницу между передачей коллекций по ссылке и по значению(при полном отсутствии необходимости создания копии)
Подтверждаю. Непомерно много людей фразу "не нужно оптимизировать слишком рано" почему-то понимают как "не нужно думать о производительности вообще и код нужно писать как попало"
Повторное использование кода может быть злом.
Приведу утрированный случай.
Предположим требуется реализовать некоторую логику для работы с физическими и юридическим лицами.
Предположим сначала логика для работы с физическими и юридическим лицами одинаковая.
А давайте не будем дублировать код этой логики!
Потом появляются мелкие различия в логике работа с физическими и юридическими лицами.
А архитектура приложения завязана на то, что логика работы с физическими и юридическими лицами одинаковая.
Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Потом появляются мелкие различия в логике работа с физическими и юридическими лицами. IB>А архитектура приложения завязана на то, что логика работы с физическими и юридическими лицами одинаковая. IB>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.
Правильная мораль — код надо своевременно подвергать рефакторингу.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
IB>>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом. AVK>Правильная мораль — код надо своевременно подвергать рефакторингу.
Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат. Поэтому необходимость рефакторинга, тоже можно рассматривать как зло.
Рефакторинг в данном случае это устранение последствий незнания того, что в будущем может потребоваться от системы. Зная варианты развития системы разработчик применят определенные шаблоны проектирования (design pattens). Если эти знания оказались ложными и требования к системы поменяли таким образом, каким разработчик изначально не предполагал, то требуется рефакторинг.
И еще вопрос Вы имели ввиду мораль того утрированного сценария, который я описал или мораль каких-то других сценариев?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>>>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом. AVK>>Правильная мораль — код надо своевременно подвергать рефакторингу.
IB>Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат.
Написание кода это тоже дополнительные трудозатраты. А мы должны стремиться к минимизации трудозатрат.
IB>>Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат. I>Написание кода это тоже дополнительные трудозатраты. А мы должны стремиться к минимизации трудозатрат.
Все верно,
Чем меньше кода, тем проще архитектура, тем лучше, проще поддерживать.
Программист должен бороться за простоту, а не за сложность.
Код должен настолько простым, чтобы выполнять возложенные на него задачи, не проще и не сложнее.
Если допустить, что код выполняет возложенные задачи, то есть проще не получится,
то остается минимизация количества кода.
Здесь под задачами понимаются текущие задачи и варианты развития.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
I>Надо полагать, тебе известен способ как добиться этого без переписывания и без рефакторинга ? Поделись пулькой что ли ?
Теоретически такой способ есть. Если разработчики четко знают до начала разработки все требования к системе, все возможные варианты её развития и эти знания впоследствии не оказываются ложными (то есть являются абсолютно истинными), то в принципе можно обойтись без переписывания и без рефакторинга (при условии, что разработчики сверхпрофессионалы). Но как Вы наверное понимаете это утопия. В реальности знания есть, но они частично могут оказаться ложными. Чтобы скомпенсировать это "частично", нужен рефакторинг. Наверняка действует закон сохранения: либо разработчики потратят больше усилий на выявление и фиксацию требований к системе, любо те же усилия потратят потом на рефакторинг.
Но к сожалению есть определенный предел точности знаний требований к системе. Дальше этого предела, сколько усилий не прилагай, эффекта не будет. То есть рефакторинг можно рассматривать как компенсаторный механизм этого несовершенства нашего мира. Единственное что является является абсолютным благом (добром) это истинные знания о требованиях к системе и профессионализм разработчиков. Но могу интуитивно предположить, что и они на каком-то более высоком уровне могут оказаться компенсаторным механизмом. Добро и зло относительно, как все остальное в мире.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, 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-рещение, это как раз прагматичное рещение, за которое я агитировал здесь
AVK>>>Рефакторинг удешевляет внесение изменений в функционал. Окупится ли сумма рефакторинг+изменение, тут да, возможны варианты, а вот изменение кода после рефакторинга обязано быть гарантированно дешевле, чем без него. IB>>Вопрос еще в том сколько будет этих изменений кода предполагается в будущем. Если мало, то рефакторинг может не окупиться, если много, то конечно окупиться. A>Рефакторинг готовит код к уже известным изменениям. Т.е. вот они новые требования, и чтобы их реализовать нужно подготовить систему, т.е. провести рефакторинг. A>Будущие изменения требований учитывает процесс проектирования и дизайна. Если вы собираетесь менять (рефакторить) систему под будущие неизвестные требования, то я не знаю чем у вас там менеджер и тимлид занят.
Здесь вопрос в том что считать известными изменениями. Новый вариант алгоритма (поведения)
это известное (предполагаемое) изменение требований или нет? С одной стороны известное, мы подготовились (порефачили) к этому изменению, реализовав паттерн "Стратегия". C другой стороны неизвестное, потому, что это все-таки это новый вариант алгоритма (поведения). А паттерн "Стратегия" это элемент дизайна системы.
IB>> Предположим сначала в программе был реализован только один вариант какого-либо алгоритма (поведения). Далее появилось требование, по которому требуется еще один вариант алгоритма (поведения). Тут можно сделать рефакторинг — использовать паттерн "Стратегия". Тогда если появятся еще 10 вариантов алгоритма их их добавление будет достигаться меньшими трудозатратами, чем если бы мы не применили паттерн "Стратегия". А если по здравому смыслу предполагается только 2 варианта алгоритма (поведения) и никак не больше? Тогда может быть дешевле не тратить силы на паттерн Стратегия, а поставить "заплатку" (if какой-нибудь в одной релизации алгоритма). A>If-рещение, это как раз прагматичное рещение, за которое я агитировал здесь
. Когда окажется что if-решения недостаточно, тогда и нужно будет рефакторить в Cтратегию. Но не раньше.
Согласен на 100%.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
A>>Рефакторинг готовит код к уже известным изменениям. Т.е. вот они новые требования, и чтобы их реализовать нужно подготовить систему, т.е. провести рефакторинг. A>>Будущие изменения требований учитывает процесс проектирования и дизайна. Если вы собираетесь менять (рефакторить) систему под будущие неизвестные требования, то я не знаю чем у вас там менеджер и тимлид занят. IB>Здесь вопрос в том что считать известными изменениями. Новый вариант алгоритма (поведения)
это известное (предполагаемое) изменение требований или нет?
Тут все просто: все что сейчас известно, считают известным, а что неизвестно, считают неизвестным (возможно предполагаемым).
IB> С одной стороны известное, мы подготовились (порефачили) к этому изменению, реализовав паттерн "Стратегия".
То что мы подготовилсь к изменению не делает его известным. Ождаемым и вероятным, это да. IB> C другой стороны неизвестное, потому, что это все-таки это новый вариант алгоритма (поведения).
Так вот. Если во время выполнения таска мы подготовилсь к будущим вероятным изменениям, это нормально.
Но если мы таск закончили, а потом готовим систему к будущим изменениям (рефакторим), то что-то тут не то.
Т.е. рефакторинг целесообразен только как часть задачи, каких-то изменений. Рефакторинг сам по себе в большинстве случаев смысла не имеет.
СУВ, Aikin
ЗЫ С другой стороны, если мы сейчас не заняты, а заказчик готовит спеку с новыми изменениями о которых нам в общем известно, то почему бы не подготовить систему к этим изменениям.
A>Тут все просто: все что сейчас известно, считают известным, а что неизвестно, считают неизвестным (возможно предполагаемым).
Понял Ваше разделение слов известно и предполагаемо. В этом смысле рефакторинг (когда реализуются паттерны) облегчает предполагаемые изменения.
A>Так вот. Если во время выполнения таска мы подготовилсь к будущим вероятным изменениям, это нормально. A>Но если мы таск закончили, а потом готовим систему к будущим изменениям (рефакторим), то что-то тут не то. A>Т.е. рефакторинг целесообразен только как часть задачи, каких-то изменений. Рефакторинг сам по себе в большинстве случаев смысла не имеет. A>ЗЫ С другой стороны, если мы сейчас не заняты, а заказчик готовит спеку с новыми изменениями о которых нам в общем известно, то почему бы не подготовить систему к этим изменениям.
. Причем средство одновременно и постактивноее и проактивно. Если разработчики вместо паттерна Стратегия наделали много сложных вложенных if, то здесь переход (рефакторинг) на паттерн Стратегия избавит от существующей сложности if, и предупредит её в будущем (если появятся новые варианты алгоритма). Если у нас только один вариант алгоритма и мы уже применяем паттерн Стратегия, то это не рефакторинг, а просто применение паттерна Стратегия.
Обычно заказчик не поймет, если Рефакторинг в плане будет записан как отдельная задача. Поэтому рефарторинг приурочивают к очередному новому варианту алгоритма.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
.
Блин, да код может быть идеальным со всех точек зрения, вот только он был идеальным при старых требованиях.
Требования изменились и код перестал быть идеальным.
Можно сразу же в старом коде добавлять новый функционал, а можно сначала провести рефакторинг и подготовить систему к изменениям.
Т.е. никакого отношения к запахам рефакторинг может не иметь.
A>Можно сразу же в старом коде добавлять новый функционал, а можно сначала провести рефакторинг и подготовить систему к изменениям. A>Т.е. никакого отношения к запахам рефакторинг может не иметь.
Вот если Вы сразу же в старом коде добавите новый функционал (без подготовки (рефакторинга)), то появятся запахи.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Aikin, Вы писали:
A>Т.е. никакого отношения к запахам рефакторинг может не иметь.
Это не совсем так. Если открыть определение рефакторинга в википедии (в английской), то там можно увидеть как минимум две цели — адаптацию под возможность реализации новых требований и улучшение читаемости кода. Вот второе как раз и есть борьба с запахом кода в чистом виде, без привязки к каким либо конкретным изменениям.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
A>>Т.е. никакого отношения к запахам рефакторинг может не иметь.
AVK>Это не совсем так. Если открыть определение рефакторинга в википедии (в английской), то там можно увидеть как минимум две цели — адаптацию под возможность реализации новых требований и улучшение читаемости кода. Вот второе как раз и есть борьба с запахом кода в чистом виде, без привязки к каким либо конкретным изменениям.
Возможно предложение составлено коряво, но имелось ввиду вот что: бывают рефакторинги, цель которых не улучшение качества кода. Т.е. первая цель из википедии или что-то еще.
Я вообще, ес. честно, не понимаю что мы тут спорим. Под рефакторинг подходит практически все, лишь бы оно не меняло функционал. Все остальное это трактовки и личныое видение каждого. ИМХО, после этого спора каждый останется ровно с тем с чем начал спорить
A>ИМХО, после этого спора каждый останется ровно с тем с чем начал спорить
А зачем тогда вообще люди спорят?
Я думаю для того чтобы почистить от хлама свое мнение и взять самое лучшее из чужого мнения.
Спор это естественный отбор мнений, как в природе.
А естественный отбор в природе сопряжен с борьбой за существование, жертвами и т. д.
С одной стороны разрушение, с другой созидание.
А что победит в итоге созидание или разрушение зависит от мудрости и порядочности спорящих.
Единство противоположностей.
Есть те кто спорит чтобы обрести власть и авторитет.
Это вполне согласуется с естественным отбором.
Та обезьяна, которая имеет власть, доминантная обезьяна, распределяет еду и никогда себя не обидит.
Только для спор ради авторитета говорит о глубинных страхах, например остаться без еды.
Хотя возможно логин на РСДН можно указать в резюме и это даст какие-либо преимущества. Не знаю.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Если нам не помогут, то мы тоже никого не пощадим.
не плыви против течения 
плыви туда, куда тебе нужно 
