http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

В свете последних дебатов по ООП, очень интересное мнение.

Скажем так — существующая парадигма повторного использования точно зло, а новая ещё должна родиться и устаканиться.

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

I>В свете последних дебатов по ООП, очень интересное мнение.

Малосвязный саморекламный бред, а не мнение, имхо.
Все библиотеки и фреймворки — это reuse. Он и сам это, похоже, понимает, и чтоб не выглядеть совсем уж идиотом (хотя лучше для этого было бы просто не писать этот чудо-пост) он начинает разделять, где use, а где reuse, и делает это крайне неубедительно: это, мол, generic, а это — не generic, хотя это деление крайне зыбкое и очень сильно зависит от задачи. Потому что стоит спуститься на уровень ниже — и то, что было generic, быть таковым перестает и становится domain-specific. Он проводит дополнительную черту по domain-specific — извините, если у меня система с десятками компонентов, я какую-то domain-specific логику, которая у меня сейчас реюзается в виде библиотеки, должен просто скопипастить во все эти компоненты? Реюзать, по его мнению, нельзя — это же domain-specific!

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/
I>В свете последних дебатов по ООП, очень интересное мнение.

Так себе статья.

Автор по большей части спорит сам с собой: сначала выдвигает спорное утверждение, что единственная настоящая цель повторного использования это скорость написания программ, затем пытается доказать, что это неверно, потому, что появляется много зависимостей и мы потеряем больше времени на отладке.
Потом занимается софистикой придумывая "правильные" определения "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."), то можно и в выводах зайти достаточно далеко, например, решить что все вокруг дураки, а истина — вот она.

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

I>В свете последних дебатов по ООП, очень интересное мнение.

Взгляды на некоторые вещи у автора весьма неординарны
Например

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.

___>весьма спорное заявление.
___>И если подобные взгляды обсуждать под пиво, то это может быть очень даже интересно.
___>Но вот работать в команде, где такими взглядами руководствуются, я бы если честно не хотел

При определённых обстоятельствах это утверждение абсолютно верно во всех отношениях. Только вот обстоятельства эти не так просто определить.

Здравствуйте, IT, Вы писали:

IT>При определённых обстоятельствах это утверждение абсолютно верно во всех отношениях. Только вот обстоятельства эти не так просто определить.

Так то оно так, но вот на практике часто получается, что понапишут эдакого

all in one place

кода, а потом доказывают, что это и есть единственно верный путь, ссылаясь на подобные статьи.

Подобную ситуацию я кстати наблюдал с упоминанием знаменитейшей(и несомненно верной) фразы про зло ранней оптимизации.
Сама фраза однозначно верна, но вот чаще всего мне ее приходилось слышать от людей, которые просто не понимали разницу между передачей коллекций по ссылке и по значению(при полном отсутствии необходимости создания копии)

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

I>В свете последних дебатов по ООП, очень интересное мнение.
Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу максимальное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно.

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

I>В свете последних дебатов по ООП, очень интересное мнение.

Мое личное мнение: дизайн — это приколачивание гвоздями в одном месте для по повышения гибкости в другом.
Удачный дизайн — это когда приколотили гвоздями то, что менятся не будет и обеспечили гибкость там, где изменения вероятны.

Конкретно по реюзю: если реюзали какой-то кусок кода в нескольких местах, мы тем самым приколотли: "во всех этих местах используется тот же самый кусок функциональности". Что может быть не верным при развитие продукта (очередной CR потребует, чтобы этот кусок функционала был различным в этих нескольких местах). Т.е. тот факт, что этот кусок функционала повторяется в нескольких местах не является достаточным условием, чтобы его выделять в отдельный метод/класс/...

Здравствуйте, Ikemefula, Вы писали:

I>http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

I>В свете последних дебатов по ООП, очень интересное мнение.

А общий вывод — не плыви по течению не плыви против течения плыви туда, куда тебе нужно

Здравствуйте, denisko, Вы писали:
D>Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу максимальное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно.
For the great justice! Отмечу — если одна и та же бабайка "приходит" к многим программистам то это уже вполне объективная бабайка.

Здравствуйте, C.A.B, Вы писали:

CAB>For the great justice! Отмечу — если одна и та же бабайка "приходит" к многим программистам то это уже вполне объективная бабайка.
Большинство бабаек объективно в том смысле, что приходили к многим программистам. Но есть тривиальный момент, бабайко-устойчивость стоит денег и надо понимать когда бабайка может прийти с достаточной вероятностью, а когда код умрет раньше (со временем вероятность прихода любой бабайки возрастает), что делает как бабайко-устойчивость, так и бабайко-неустойчивость относительным злом или добром. К автору недавно пришла вторая бабайка под названием "Я тут думаю, время идет, я нифига не успею,аааааа", на почве встречи двух бабаек случился когнитивный диссонанс, который вылился в статью.

Здравствуйте, robin_of_the_wood, Вы писали:

___>Подобную ситуацию я кстати наблюдал с упоминанием знаменитейшей(и несомненно верной) фразы про зло ранней оптимизации.
___>Сама фраза однозначно верна, но вот чаще всего мне ее приходилось слышать от людей, которые просто не понимали разницу между передачей коллекций по ссылке и по значению(при полном отсутствии необходимости создания копии)
Подтверждаю. Непомерно много людей фразу "не нужно оптимизировать слишком рано" почему-то понимают как "не нужно думать о производительности вообще и код нужно писать как попало"

Повторное использование кода может быть злом.
Приведу утрированный случай.
Предположим требуется реализовать некоторую логику для работы с физическими и юридическим лицами.
Предположим сначала логика для работы с физическими и юридическим лицами одинаковая.
А давайте не будем дублировать код этой логики!
Потом появляются мелкие различия в логике работа с физическими и юридическими лицами.
А архитектура приложения завязана на то, что логика работы с физическими и юридическими лицами одинаковая.
Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.

Здравствуйте, igor-booch, Вы писали:

IB>Потом появляются мелкие различия в логике работа с физическими и юридическими лицами.
IB>А архитектура приложения завязана на то, что логика работы с физическими и юридическими лицами одинаковая.
IB>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.

Правильная мораль — код надо своевременно подвергать рефакторингу.

IB>>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.
AVK>Правильная мораль — код надо своевременно подвергать рефакторингу.

Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат. Поэтому необходимость рефакторинга, тоже можно рассматривать как зло.
Рефакторинг в данном случае это устранение последствий незнания того, что в будущем может потребоваться от системы. Зная варианты развития системы разработчик применят определенные шаблоны проектирования (design pattens). Если эти знания оказались ложными и требования к системы поменяли таким образом, каким разработчик изначально не предполагал, то требуется рефакторинг.
И еще вопрос Вы имели ввиду мораль того утрированного сценария, который я описал или мораль каких-то других сценариев?

Здравствуйте, igor-booch, Вы писали:

IB>>>Мораль: для создания хорошей архитектуры необходимо знать не только, что нужно сейчас, но и то что может понадобится потом.
AVK>>Правильная мораль — код надо своевременно подвергать рефакторингу.

IB>Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат.

Написание кода это тоже дополнительные трудозатраты. А мы должны стремиться к минимизации трудозатрат.

IB>>Рефакторинг требует дополнительных трудозатрат. А мы должны стремиться к минимизации трудозатрат.
I>Написание кода это тоже дополнительные трудозатраты. А мы должны стремиться к минимизации трудозатрат.

Все верно,
Чем меньше кода, тем проще архитектура, тем лучше, проще поддерживать.
Программист должен бороться за простоту, а не за сложность.
Код должен настолько простым, чтобы выполнять возложенные на него задачи, не проще и не сложнее.
Если допустить, что код выполняет возложенные задачи, то есть проще не получится,
то остается минимизация количества кода.
Здесь под задачами понимаются текущие задачи и варианты развития.

Здравствуйте, igor-booch, Вы писали:

IB>Код должен настолько простым, чтобы выполнять возложенные на него задачи, не проще и не сложнее.

Надо полагать, тебе известен способ как добиться этого без переписывания и без рефакторинга ? Поделись пулькой что ли ?

I>Надо полагать, тебе известен способ как добиться этого без переписывания и без рефакторинга ? Поделись пулькой что ли ?

Теоретически такой способ есть. Если разработчики четко знают до начала разработки все требования к системе, все возможные варианты её развития и эти знания впоследствии не оказываются ложными (то есть являются абсолютно истинными), то в принципе можно обойтись без переписывания и без рефакторинга (при условии, что разработчики сверхпрофессионалы). Но как Вы наверное понимаете это утопия. В реальности знания есть, но они частично могут оказаться ложными. Чтобы скомпенсировать это "частично", нужен рефакторинг. Наверняка действует закон сохранения: либо разработчики потратят больше усилий на выявление и фиксацию требований к системе, любо те же усилия потратят потом на рефакторинг.
Но к сожалению есть определенный предел точности знаний требований к системе. Дальше этого предела, сколько усилий не прилагай, эффекта не будет. То есть рефакторинг можно рассматривать как компенсаторный механизм этого несовершенства нашего мира. Единственное что является является абсолютным благом (добром) это истинные знания о требованиях к системе и профессионализм разработчиков. Но могу интуитивно предположить, что и они на каком-то более высоком уровне могут оказаться компенсаторным механизмом. Добро и зло относительно, как все остальное в мире.