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

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

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

Кто прав?

EDIT: если очень интересно, то вот как этот "гений" требовал, чтобы я кодил cloud.mail.ru
  • Вопрос задан
  • 5890 просмотров
Пригласить эксперта
Ответы на вопрос 15
miraage
@miraage
Старый прогер
Мужик дегенерат, однозначно.

// EDIT

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

Я бы на Вашем месте уволился, незадумываясь.
Ответ написан
Комментировать
Adamos
@Adamos
Баланс.
Если проект реально высоконагруженный, но простой, как табуретка - то человек прав, чем меньше в коде будет абстракций, тем меньше оверхеда.
Но если проект не только высоконагруженный, но и сложный - вы мозг сломаете, делая его функционально. Функции хороши там, где нужны простые решения. Если вы можете разобрать всю архитектуру на простые решения - вам не нужно ООП. Если не можете - то без него проект захлебнется в собственной сложности.
Ответ написан
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
Мужик не молодец в том плане что совсем функциональный подход это не круто ниразу, но вместе с тем как ни странно прав, в том что сложное ооп (по крайней мере в тех хайлоад проектах что я видел) - не применялось ниразу.
Ответ написан
Комментировать
allard
@allard
Серийный программист
Когда-то видел хорошее сравнение по вопросу ооп против процедурного программирования.
Было что-то на подобие:
Зачем в наше время мыть посуду руками, если у вас рядом стоит посудомоечная машина. Если тебе нужно помыть одну тарелку, то можно это сделать и руками, а если после банкета у тебя гора посуды, то зачем мучаться...
Так и с процедурным программированием, если вам нужно добавить какую-то мелочь в проект, с которым вы не знакомы, то почему бы и не написать одну функцию и не вставить её вызов куда нужно, это будет нормальным вариантом. Но если вы хотите разработать гигантский проект для работы с большими объемами разных данных, то тут без ооп никак.

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

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

Я бы сказал так, не нужно возвращаться в лихие двухтысячные, нужно стремиться вперед. Php развивается и развивается в сторону опп, так зачем отставать от прогресса?!
Ответ написан
@bromzh
Drugs-driven development
Только ситхи возводят всё в абсолют. ООП для каких-то случаев хорошо применим, а для каких-то нет. Тоже самое справедливо для любой другой парадигмы. А выбирать технологии только исходя из общей моды очень тупо.
Ответ написан
Комментировать
@malroc
Ну вот когда выйдет ОДИН хотя бы сколько-нибудь популярный фреймворк, построенный на функциональном программировании вместо ООП, тогда будет предмет для разговора.
Пока ничего похожего не видно даже на горизонте, здесь вообще говорить не о чем. Он велосипед что ли свой собирается делать? Ну можно посочувствовать тогда. И ему, и вам заодно. Ищите новую работу.
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
Обычная демонстрация эффекта Даннинга - Крюгера.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
Если проект будет писать 1-2 человека за срок до месяца, то можно и функциональное программирование.
ООП был придуман для того, чтобы сложный и большой проект, можно было грамотно и удобно разбить на части, которые работают максимально независимо друг от друга, и которые разрабатываются и поддерживается людьми, которые друг с другом почти не контактируют.
ООП подход - как раз и обеспечивает архитектуру того, что уменьшается вероятность факапа от несогласованности действий.

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

Все.
Что же касается скорости работы - подходы тут вообще не причем, подходы влияют на скорость и удобство разработки и поддержки, а работа продукта непосредственно в продакшене зависит от криворукости.
Ответ написан
Комментировать
Acuna
@Acuna
Заполнил свой профиль
Выше уже все очень подробно на пальцах Вам объяснили почему все это чистой воды бред. Лично я не буду говорить Вам, что нужно увольняться, я скажу только то, что переписывать крупный проект полностью - это крайне сложно и просто унизительно. Хотя-бы потому, что нет ничего хуже осознания того, что Вы тратите все свое время на бессмысленные вещи, то есть пересоздание того, что уже хорошо функционирует и так. Руки у вас опустятся уже на втором месяце такой "работы", помяните меня на слове. Просто Вам подкинул мысль для размышления, подумайте над ней на досуге.
Ответ написан
Комментировать
heksen
@heksen
С ООП быстрее.
Ответ написан
MetaDone
@MetaDone
Хорошо сформулированный вопрос - 50% решения
Всему свое место
habrahabr.ru/company/vkontakte/blog/214877 - не знаю как там сейчас дела с ооп
Но переписывать заново если сайт успешно справляется с тем, что есть - неразумно, а ваш начальник судя по всему не особо в теме
Ответ написан
@Cnfc19932
Full-stack web developer
Вполне возможно, что мужик и прав.Все слишком специфично.Очень огорчает иной раз видеть статьи типо "используем функциональный python", как-будто это что-то необычное, многие разработчики уже настолько запудрили себе мозги абстракциями, что не видят простых решений.
Ответ написан
Комментировать
unclechu
@unclechu
Вообще можно провести эволюционную цеполчку:
  1. Процедурное программирование
  2. ООП
  3. Функциональное программирование

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

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

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

К тому же ФЯП не отменяет фреймворков.
Ответ написан
Комментировать
@jaxel
Поржал с кода. Тут и процедурным то программированием даже не пахнет. Зачем ему вообще PHP, тоже самое можно написать на голом HTML и оно вообще будет летать:)

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы