Да никакой разницы.

За исключением специфичных методов, большинсвто из них прменимо везде: extract/inline method, rename variable, encapsulate - хоть в процедурном, хоть в функциональном программировнии имеет место быть.

В контексте ооп все эти вещи чаще рассмотриваются лишь потому что ооп в принципе популянее.

Хочется найти литературу по рефакторингу НЕ ООП кода, это реально?

А ты пробовал? Ну вот тот самый банальный пример литературы по рефакторингу тебе не подходит? А почему?

Нет, разница есть.

Я находил мануалы на тему «как отрефакторить не_ООП_программу в ООП», но не наоборот, более того, не смог найти статьи по рефакторингу, в которых не было бы сказано про ООП, и про «нарушения ООПодхода» как про проблему.

То есть понятно, что я могу выкинуть из рефакторинга ООП-нарушения и ООП-методы решения проблем, но что останется в «сухом остатке»?

Разницы нету. Надо начать с того, что ООП - лишь условность.

Основные задачи: устранение code smells и приведение кода в тот вид, который надо для дальнейшей разработки (добавления новых фич, упрощение тестирования, и т.п.).

Нет, разница есть.

Ее нет.

Я находил мануалы на тему «как отрефакторить не_ООП_программу в ООП»

Ты находил методички для индусских ПТУ. Ничего, братишка, вот я тебе ссылку принес: https://en.wikipedia.org/wiki/Code_refactoring

Хочется найти литературу по рефакторингу НЕ ООП кода, это реально?

Нет. Ну если только сказки на уровне google-блогов. Рефакторинг кода — это рефакторинг кода. Не важно какая методология была использована при его написании. Ваш КО.

Дык, рефакторинг это ООП баззворд, что же ты хотел. А так все мы внезапно говорим прозой, т.е. рефакторинг используется повсеместно. Книжки тут особо не нужны, достаточно здравого смысла и опыта. ОО-макулатура от консультантов тоже всего лишь компиляция трюизмов и тараканов в голове этих фаулеров. Ну и еще одна пачка баззвордов в нагрузку для раздувания ЧСВ.

НЕ НАДО писать НЕ-ООП код. Никогда. Ни при каких обстоятельствах. 21й век на дворе, в конце концов!

Святая толстота!

Спасибо за ответ :)

рефакторинг это ООП баззворд

Leo Brodie «Thinking Forth», глава 6 «Factoring».

А ты пробовал?

Да.

Ну вот тот самый банальный пример литературы по рефакторингу тебе не подходит?

Если выкинуть ООП-баззворды, — то подходит...

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

Почему это произошло не вместе с популяризацией ООП, а параллельно с популяризацией паттернов?

Что произошло в коре и древесине головного мозга людей из computer science, что резко понадобился рефакторинг?

Интересно, почитаю :)

Что произошло в коре и древесине головного мозга людей из computer science

А какое отношение ОО-сброд имеет к людям из CS?

Что произошло в коре и древесине головного мозга людей из computer science, что резко понадобился рефакторинг?

Т.е. если следовать логике ваших слов, то до этого он не был нужен?
Вы вглядитесь в график что дали выше. М.б. в 80-тые были реальные специалисты, которым не нужно было лезть в гугл чтобы узнать что такое рефакторинг и как это работает? А ближе к нулевым и выше, из-за бурной показательной деятельности молодняка интернет просто завалило всякой информацией о хрен знает чем, для хрен знает чего.
Я вот думаю что старые специалисты в IT (только я о специалистах, а не о эникейщиках), которым сейчас от 40 и выше просто понимают что они делают. А мы, молодняк, думаем что понимаем, и вот потому что мы думаем, в нашу голову и закрадываются сомнения насчет верности решения задачи, отчего мы лезем в эти наши интернеты.

Тогда софт был проще и мельче из-за ограниченности ресурсов. Ну и да, программирование еще не стало такой массовой индустрией. Хотя намеки во что все выльется уже были: смолток и зародыш крестов уже смущали умы.

Off-topic

Тогда софт был проще и мельче из-за ограниченности ресурсов.

Но вы же не станет отрицать, что тогда (черт, как это страшно звучит, когда деревья были большими, ну все это) специалисты понимали что они делают. Независимо от сложности задачи. Вы же знаете что сложная задача разбивается на более простые. Это основа основ, и из нее следует вывод о том, что сложных задач не бывает, строго говоря.

смолток и зародыш крестов уже смущали умы

смолток и зародыш крестов уже смущали неокрепшие умы.
Fixed. Не думаю что это относилось к реальным специалистам. Реальные специалисты делали свою работу, пили пиво и ржали над новыми тенденциями в своих узких кругах.

Ну и да, программирование еще не стало такой массовой индустрией.

Дак может быть все дело как раз в этом? Машинные коды не были доступны среднему классу, который путал интегралы с ночными кошмарами. А с увеличением доступности в сферу полез и средний класс. Я вот лично жалею о том, что плохо учил математику в свое время. Сейчас бы может быть разрабатывал что-нибудь действительно нужное для мира, вместо того чтобы изображать никому не нужную бурную деятельность на ЛОР'е или на работе.

индустрией
индустриальный
индус-триальная революция

Бинго!

Корпорациям потребовались квалифицированные кадры, нужно было массово готовить ынтырпрайс-макак!

Соответственно стали насаждать в массы паттерны и рефакторинг :)

Спасибо, антоша, отличная работа!

Машинные коды не были доступны среднему классу, который путал интегралы с ночными кошмарами.

Не стоит путать средний класс и обывателей, это разные категории.

Да и на машинных кодах писали в 40x годах, в 50x уже были ассемблеры и много чего еще...

Я вам сейчас открою страшную тайну. Я когда учился, в свое время, в моей группе практически все думали что трансляторы — ВНЕЗАПНО, это и есть машинные коды. А ниже транслятора только кровь кишки и мтранзисторы, и вообще это для Васи-электрика, программисту такое «нинужнэ». Специальность «Автоматизированные системы управления». И все это на полном серьезе. Причем большинство из них нельзя было назвать глупыми. И вот в какую группу нужно их отнести? Средний класс? Обыватели? Вся соль в том, что потом эти люди каким-то образом устраиваются на работу по специальности. По специальности, Карл!. И ведь работают. И многие ведь удачно. (ну я не буду сейчас эрзентить тут и верить в то что все это по знакомству :))

off-topic

А ниже транслятора только кровь кишки и мтранзисторы, и вообще это для Васи-электрика, программисту такое «нинужнэ».
Автоматизированные системы управления

Какая специальность, такие и специалисты. 95% потом идут работать во всякие инженеры АСУТП или КИПиА, и да, рисовать схемы с диодами и (не дай б-г) транзисторами они не могут, максимум реле, причём без знания теории автоматов (sic!).

Если знают хоть один язык МЭК-61131-3, считай, что повезло...

«Литература по рефакторингу» это как «Инструкция по применению ложки».

Off-topic

Да это все понятно. Не понятно только к какой группе относятся эти 95%. И не они ли потом в интернете так резко увеличивают график запросов по всяким oo/refacroting/etc когда идут устраиваться работать программистами, вспомнив что им преподавали какой-то там Delphi/Pascal/etc.

«Литература по рефакторингу» это как «Инструкция по применению ложки».

Ну это вы конечно загнули.
Инструкции по 400-500 страниц
достаточно сложно сравнивать с
инструкцией по применению ложки
Причем это самые популярные. Сотни их. А вот «Литература по рефакторингу не ОПП кода» действительно звучит странно :)

Нет, на реальном АСУ в промышленности нужны знания SCADA/МЭКовских языков, и т.д., и т.п., рефакторинг там как раз «нинужен».

преподавали какой-то там Delphi/Pascal/etc.

Есть у меня один знакомый медик, работающий программистом в крупной международной компании. Java он освоил на курсах переподготовки кадров, на работе на хорошем счету.

В этом треде дали только книжку по forth, в которой рефакторинг есть, а ООП нет.

Спасибо, антош!

Инструкции по 400-500 страниц

Все еще остаются инструкцией по применению ложки. Если человек не может дать количественную оценку результату рефакторинга - человек идет бухать/дрочить/думать о вечном, но к рефакторингу не допускается. Если человек может оценить результат количественно, в двух словах объяснить, что он должен для этого сделать - флаг в зубы, барабан на шею.

Литература по рефакторингу не ОПП кода

А что не так?

Интересно сравнить ДО и ПОСЛЕ массового помешательства на ООП.

Если человек не может дать количественную оценку результату рефакторинга - человек идет бухать/дрочить/думать о вечном, но к рефакторингу не допускается. Если человек может оценить результат количественно, в двух словах объяснить, что он должен для этого сделать - флаг в зубы, барабан на шею.

Сурово, как у нас в детском саду. А можно привести пример «количественной оценки результата рефакторинга»?

Нет, на реальном АСУ в промышленности нужны знания SCADA/МЭКовских языков, и т.д., и т.п., рефакторинг там как раз «нинужен».

А я так сказал? :)

Есть у меня один знакомый медик, работающий программистом в крупной международной компании. Java он освоил на курсах переподготовки кадров, на работе на хорошем счету.

Ну вот как раз ваш знакомый медик, если у него попросить набросать алгоритм нечеткого поиска на основе расстояний Дамерау-Левенштейна — скорее всего, встанет в ступор. Ибо на «курсах переподготовки кадров», я думаю, учат максимум как прикрутить библиотеку, или как распарсить csv-файл (опять же с помощью уже готовой библиотеки, ибо Java). Зато если он учился (учился, а не балду пинал) на медицинском, то в своей области он сможет поразить вас знаниями. Но только учение практически всегда подразумевает под собой самообучение. Большинство знаний в наше время человек может (и должен) находить сам.

А что не так?

Все не так. Поделитесь такой литературой, если она найдется, конечно же (только учтите, о уровне google-блогов я уже писал, меня это не интересует).

алгоритм нечеткого поиска на основе расстояний Дамерау-Левенштейна — скорее всего, встанет в ступор.

/me встал в ступор...

И не они ли потом в интернете так резко увеличивают график запросов по всяким oo/refacroting/etc когда идут устраиваться работать программистами, вспомнив что им преподавали какой-то там Delphi/Pascal/etc.

Нет, на реальном АСУ в промышленности нужны знания SCADA/МЭКовских языков, и т.д., и т.п., рефакторинг там как раз «нинужен».

А я так сказал? :)

Не будет человек, который реально занимается АСУ искать рефакторинг, и да на графиках не запросы в google, там частоты встречаемости баззвордов профессиональных терминой в печатных изданиях.

А можно привести пример «количественной оценки результата рефакторинга»?

Сферический конь в вакууме начинает помещаться в куб меньшего объема.

1. Скорость выполнения - для каждой задачи можно измерить.

2. Ресурсоемкость - для каждой задачи можно измерить.

3. Объем кодовой базы/обслуживаемость - можно измерить, хоть в тех же строчках (при соблюдении код-стайла).

4. Сокращение времени реализации будущих задач.

Если процентное соотношение между «до и после» не дано - значит человек не имеет понятия, что он собирается сделать. «Ну будет лучшее» - не катит, скорее всего будет просранный дедлайн.

Если человек не может объяснить шаги, которые он сделает для достижения обозначенной цели - он понятия не имеет, как он собирается это сделать. И велик риск, что к календарному концу рефакторинга будут две ветки софтины: 1-я - когда это говно «как-то» работало. 2-я окончательно расп#дорашенный клон 1й ветки.

Все не так.

Все так.

Поделитесь такой литературой

За пивом сгоняй.

ООП — оно не в средствах. ООП — оно в головах.

встанет в ступор.

Если он не тупее меня (а это тоже достижение) - не встанет.

https://ru.wikipedia.org/wiki/Расстояние_Левенштейна

1. Скорость выполнения - для каждой задачи можно измерить.
2. Ресурсоемкость - для каждой задачи можно измерить.

Это относится к оптимизации, и это трудно оценить априори.

3. Объем кодовой базы/обслуживаемость - можно измерить, хоть в тех же строчках (при соблюдении код-стайла).

Объем можно измерить, обслуживаемость... а что это?

4. Сокращение времени реализации будущих задач.

С оценкой сроков выполнения задач в творческих профессиях беда везде...

Особенно, когда касается

будущих задач

в проектной деятельности (когда результат уникален).

Не будет человек, который реально занимается АСУ искать рефакторинг

Дак они ж программистами идут устраиваться. Вот поинт. Причем я сам там учился. Работал программистом. Сейчас проектировщик, но по факту все равно кодить приходится. И все же считаю что работаю по специальности. Потому как она вообщем-то обширна. Техник автоматизированных систем управления. Я могу программу для управления станками с ЧПУ на предприятии назвать автоматизированной системой управления или же нет? А программу автоматических расчетов маршрута доставляемых грузов? Ибо если нет, то меня жестоко обманули :)

и да на графиках не запросы в google, там частоты встречаемости баззвордов профессиональных терминой в печатных изданиях.

Ого. Что-то я туплю. А я вот до последнего верил что это Google-Trends :)

А можно привести пример «количественной оценки результата рефакторинга»?

Сферический конь в вакууме начинает помещаться в куб меньшего объема.

Ясно, спасибо. Ну точно, как у нас в детском саду.

Это относится к оптимизации, и это трудно оценить априори.

В том то и дело, что если трудно - пляски с бубном лучше отложить.

обслуживаемость

Простота внесения изменений. Время ввода в проект новых людей. Читабельность наконец. Измерить тоже можно. Например, если два-три человека, реализуя разные задачи, написали весьма схожую функцию (наприме) КонвертацияБульдогаВНосорога. То имеет смысл вынести ее отдельно и переиспользовать везде. Можно сравнить сколько мест надо исправить в случае изменений? Можно.

С оценкой сроков выполнения задач в творческих профессиях беда везде...

Беда, но даже «беда» может подразумевать «неприятность» или «ЖОПА». Так что тут если ничего не делать или делать ради делания а-ля «ну штоп как у взрослых пасанов, рефакторенг-шмефакторенг» - всегда будет хуже чем могло быть.

Ого. Что-о я туплю. А я вот до последнего верил что это Google-Trends :)

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

Я могу программу для управления станками с ЧПУ на предприятии назвать автоматизированной системой управления или же нет?

А программу автоматических расчетов маршрута доставляемых грузов? Да, чет я туплю, посчитал, что к АСУ относится только АСУТП, а управление бизнес-процессами не относится...

Ибо если нет, то меня жестоко обманули :)

Обманули. Автоматизированные системы управления != Автоматизации Производственных Процессов.

Угу а что же тогда это такое? Объясните мне, пожалуйста.

Беда, но даже «беда» может подразумевать «неприятность» или «ЖОПА».

В основном второй вариант, достаточно посмотреть хотябы на проект F-35.

Его ведь не студенты из шараги делают, то есть, у Лохидов скорее всего высший уровень зрелости по CMMI, но это не помешало устроить трэш и угар.

Ну вот вы нашли определение в интернете. Теперь осталось самое банальное. Набросать алгоритм. Только не забудьте просчитать временную сложность/потребление памяти/вот это все, на примере нескольких входных данных. Представление в виде матрицы вполне подойдет. После этого сразу же оптимизируйте алгоритм. Ну я думаю вам не стоит напоминать что его можно оптимизировать до бесконечности. Заодно расскажите потом нам, сколько строк матрицы нужно хранить для оптимальной производительности. И для чего Дамерау при расчете расстояния учитывал еще и стоимость транспозиции.
Глядишь через некоторое время откроете для себя, что большинство ошибок в тексте, который набирает среднестатистический образованный человек — это и есть банальные транспозиции. Об этом, кстати, можно целую книгу написать.

, у Лохидов скорее всего высший уровень зрелости по CMMI, но это не помешало устроить трэш и угар.

Эт как посмотреть, а мог и не взлететь :D Вообще госзаказы в США - тот еще «трэш и угар».

Объясните мне, пожалуйста.

Эээ я не поэт, так что буду сказать как могу:

Автоматизированная система управления - выполняет процесс. АПП - всего лишь учавствует в выполнении процесса. Вот если программа по рассчету маршрута доставки грузов, вместо рассчета начнет диктовать:«Эй двуногий, а ну бл#дь быстро взял линейку, транспортир и посчитал маршрут» - это уже переводит ее в разряд АСУ.

Не, не взлетает только башня у Арматы, Ан-124 у рос. ВДВ, а в СШАшечке даже Бредли в итоге запустили.

Например, если два-три человека, реализуя разные задачи, написали весьма схожую функцию (наприме) КонвертацияБульдогаВНосорога. То имеет смысл вынести ее отдельно и переиспользовать везде.

О, рефакторинг! Без ООП!

О, рефакторинг! Без ООП!

А почему нет? Паттерны проектирования в том или ином виде реализуются везде и на чем угодно. Просто адепты ООП постарались их устаканить до вида «жми тут - получишь банан». В чистом виде они нигде не применяются, а там где применяются - царство жопоболи и вечных авралов.