ООП в высоконагруженных проектах считается устаревшим?

Question

[kernel0]

Здравствуйте! Устроившись на новую работу, сразу начал конфликтовать с начальником. Его позиция такова, что YII и прочие современные php фрэймворки, паттерны проектирования, ООП в целом - это все устаревшие технологии. Проект необходимо переписать заново по типу функционального программирования.
Далее привожу его цитату:
"Перечитал гору информации о разных подходах к архитектуре стартапа, поэтому сейчас для меня картина ясна. Писать на ООП, это как писать на .NET и прочих устаревших платоформах. Можно, конечно, но зачем? Их время давно прошло."

Моя позиция, что мужик дегенерат.

Кто прав?

EDIT: если очень интересно, то вот как этот "гений" требовал, чтобы я кодил cloud.mail.ru

Comments

[evnuh]

Аргументация "устаревшее - значит не надо" выявляет в человеке мудака на 100%

[Ilya Bobkov]

глянул код, смеялся долго. шеф явно деградирует.

[Александр Макаров]

Это троллинг? :)

Answer 1

[Mikhail Osher]

Мужик дегенерат, однозначно.

// EDIT

Посмотрел прикрепленные исходники. Закапал святую воду в глаза.
Выкиньте это всё, покажите ему, например, PHP: The Right Way.

Я бы на Вашем месте уволился, незадумываясь.

Answer 2

[Adamos]

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

Comments

[malroc]

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

[АртемЪ]

malroc: Не любой.

[Игорь Воротнёв]

Пожалуй, самый точный ответ. Без холивара, по сути.

Answer 3

[Андрей]

Когда-то видел хорошее сравнение по вопросу ооп против процедурного программирования.
Было что-то на подобие:
Зачем в наше время мыть посуду руками, если у вас рядом стоит посудомоечная машина. Если тебе нужно помыть одну тарелку, то можно это сделать и руками, а если после банкета у тебя гора посуды, то зачем мучаться...
Так и с процедурным программированием, если вам нужно добавить какую-то мелочь в проект, с которым вы не знакомы, то почему бы и не написать одну функцию и не вставить её вызов куда нужно, это будет нормальным вариантом. Но если вы хотите разработать гигантский проект для работы с большими объемами разных данных, то тут без ооп никак.

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

Да, процедурный подход выигрывает в производительности на пару процентов у ооп, ну может на пяток процентов в некоторых проектах. Просто, тяжело сравнить производительность, т.к. ни один серьездный проект не разрабатывается на стандартном php в процедурном стиле (вы представьте yii или laravel на функциях). Ну, не считая отдельных специфичных движков, типа kphp.
Лишаться кучи преимуществ ооп, ради пары процентов процессорного времени, вообще нет смысла.
Тем более в наше время куча облачных сервисов, любой проект можно смаштабировать...

Я бы сказал так, не нужно возвращаться в лихие двухтысячные, нужно стремиться вперед. Php развивается и развивается в сторону опп, так зачем отставать от прогресса?!

Comments

[malroc]

Речь о функциональном программировании, а не процедурном.

[Андрей]

malroc: Я функцониальное и имел ввиду. Просто функцониальное это частный случай процедурного. Хотя если брать в общем, то это понятия разного маштаба, вы правы.

[АртемЪ]

Андрей: Ну насчет производительности - не на пяток процентов.
Там разброс очень широкий где-то действительно на 2-3%, а где то на 200-4000%

[АртемЪ]

Лишаться кучи преимуществ ооп, ради пары процентов процессорного времени, вообще нет смысла.

Ну не скажите.
А если у вас задача написать проект который будет работать на миниатюрной железке, и должен работать год от батарейки весом 5грамм?
Вы тоже будете лепить ООП или будете просчитывать каждое действие для экономии нагрузки процессора?

ООП хорош когда важно время разработки и пофиг а вычислительные ресурсы легко купить.
Но это очень ограниченный круг проектов.

[Андрей]

АртемЪ: пример с батарейкой не актуален для php, тут нужно что-то более низкоуровневое, типо Си или ассемблера.
По поводу разброса производительности, найдите хоть один тест с разбросом больше 30% (это я с запасом взял).
Я думаю, что не открою тайны, но даже самые простые и обычные конструкции языка на низком уровне построены на объектных моделях. Даже создание пустого массива типа array(); или []; почти не отличается от new ArrayObject();, на нижнем слое php все это создает объекты с кучей сеттеров и геттеров.
Так что, отличие в производительности связано большей частью с тем что в ооп, мы создаем избыточность для удобства и ускорения работы, что влечет за собой занимание большей памяти и процессорного времени.
А простое создание класса с одним методом для возврата значения и простое создание функции для возврата значения будут отличаться..., думаю процентов на 10 по времени выполнения.
Можете ради интереса сами сделать пару тестов и сделать пару тясяч прогонов.

[АртемЪ]

Андрей: Ну если говорить про php то конечно. Какой там будет разброс.

[unclechu]

Андрей: функциональное и процедурное — это скорее антонимы, а не одно частный случай другого.

Answer 4

[Дмитрий Энтелис]

Мужик не молодец в том плане что совсем функциональный подход это не круто ниразу, но вместе с тем как ни странно прав, в том что сложное ооп (по крайней мере в тех хайлоад проектах что я видел) - не применялось ниразу.

Answer 5

[bromzh]

Только ситхи возводят всё в абсолют. ООП для каких-то случаев хорошо применим, а для каких-то нет. Тоже самое справедливо для любой другой парадигмы. А выбирать технологии только исходя из общей моды очень тупо.

Answer 6

[malroc]

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

Comments

[kernel0]

Да уже ищу. Какому-то другому бедолаге достанется (

[sim3x]

Аргумент "миллионы мух не могут ошибаться", как-то странно выглядит

[malroc]

sim3x: даже более чем странно с учётом того что я не очень понимаю где вы его увидели.

[sim3x]

malroc:
>популярный

[malroc]

sim3x: А также:
> ОДИН
> сколько-нибудь
Вы специально читаете через слово?

[sim3x]

malroc:

Erlang/OTP

[malroc]

sim3x: Так это нишевый инструмент под решение специфических задач, целиком на нём проект не построишь.

[sim3x]

malroc:
> ОДИН
> сколько-нибудь

[malroc]

sim3x: и? По контексту должно быть наверное понятно, что речь о полноценных веб-фреймворках, а не узкоспециализированных инструментах.
Какое вообще отношение OTP имеет к теме разговора? Вы можете им заменить "YII и прочие современные php фрэймворки" (на всякий случай цитирую оригинальный пост, а то у вас видимо какие-то сложности с чтением)?

[sim3x]

malroc:
n2o
ChicagoBoss

[malroc]

sim3x: отлично, я даже знаю что такое n2o.
А как думаете как я о нём узнал? Увидел на нём крутой проект? Прочитал где-то восторженный отзыв? Нет, я интереса ради решил поискать, есть ли сейчас полноценные веб-фреймворки на Erlang. Именно потому что ни об одном из них никогда не слышал. Это при том что за новостями индустрии я слежу и все популярные фреймворки на всех основных основных языках знаю как минимум по названиям.
Можете навскидку назвать серьёзный проект, который построен на любом из них?

[Алексей Васильевич]

malroc: erlyvideo.ru - построен на ЧикагоБоссе

Answer 7

[index0h]

Обычная демонстрация эффекта Даннинга - Крюгера.

Answer 8

[Saboteur]

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

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

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

Answer 9

[Антон Тихомиров]

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

Answer 10

[Ilya Bobkov]

С ООП быстрее.

Comments

[kernel0]

Как раз главным его доводом было то, что по статистике при переходе на ООП скорость разработки проекта падает на 50-70%. Где он взял такую статистику понятия не имею. На просьбу предоставить пруфы тоже адекватной реакции не последовало((

[Ilya Bobkov]

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

[Ilya Bobkov]

А выше потому, что существует наследование и деление на объекты (классы), что интуитивно понятнее.

[Adamos]

Важный вопрос, что именно разрабатывается. На сайте из трех принципиально разных страничек любой PHP-фреймворк замедлит скорость разработки на порядок...

[Ilya Bobkov]

Adamos: зависит от масштаба проекта, согласен

[Adamos]

Денис Акимкин: Из трех разных страничек? Могу предложить из одной: автоматический парсер на VPS, складывающий результаты в архив на диск. Его тоже на фреймворке писать?

[Adamos]

Денис Акимкин: если бы нужно было выполнить три оператора, один из которых - обращение к готовой библиотеке на PHP, и времени хватало с лихвой? И парсинг нужен только на неделю, а потом все можно выбросить?
Случаи бывают разные...

Answer 11

[MetaDone]

Всему свое место
habrahabr.ru/company/vkontakte/blog/214877 - не знаю как там сейчас дела с ооп
Но переписывать заново если сайт успешно справляется с тем, что есть - неразумно, а ваш начальник судя по всему не особо в теме

Comments

[kernel0]

самое смешное, что сейчас они все-таки возвращаются к ооп

Answer 12

[Stanislav Gorovoy]

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

Answer 13

[unclechu]

Вообще можно провести эволюционную цеполчку:

1. Процедурное программирование
   
2. ООП
   
3. Функциональное программирование
   

Процедурный подход — наихудший из списка в плане поддержки кода в долгосрочной перспективе, сложность растёт экспоненциально, в большом проекте — это ад.
ООП — Лучше чем процедурный.
Функциональщина — лучше чем ООП, и тем более чем процедурный.

Это если топорно и представлять мир как чёрное или белое.

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

К тому же ФЯП не отменяет фреймворков.

Answer 14

[jaxel]

Поржал с кода. Тут и процедурным то программированием даже не пахнет. Зачем ему вообще PHP, тоже самое можно написать на голом HTML и оно вообще будет летать:)

PS: Думаю стоит кинуть начальнику ссылку на это обсуждение.

Answer 15

[Кирилл Левунин]

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