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

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

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

Кто прав?

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

// EDIT

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

Я бы на Вашем месте уволился, незадумываясь.
Ответ написан
Adamos
@Adamos
Баланс.
Если проект реально высоконагруженный, но простой, как табуретка - то человек прав, чем меньше в коде будет абстракций, тем меньше оверхеда.
Но если проект не только высоконагруженный, но и сложный - вы мозг сломаете, делая его функционально. Функции хороши там, где нужны простые решения. Если вы можете разобрать всю архитектуру на простые решения - вам не нужно ООП. Если не можете - то без него проект захлебнется в собственной сложности.
Ответ написан
OnYourLips
@OnYourLips
Дегенерат.
Увольняйтесь (на испытательном сроке это просто, отрабатывать не надо), не надо ему ничего доказывать.
И ссылку на этот вопрос ему тоже дайте.

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

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

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

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

Я встречал начальников которые поясняют нанятому специалисту как ему лучше делать свою работу в которой наемник узкоспециализированный мастер
Ощущая себя при этом гениальными архитекторами
Меняя при этом наемных рабов регулярно

Не питая таких людей они не будут расти за твой счет

Также предлагаю в ответ поговорить о методах управления компанией и прочих делах начальника

ФП это по сути Лисп
А Пролог круче Лиспа
Но все это делается на Си
Ответ написан
@bromzh
Drugs-driven development
Только ситхи возводят всё в абсолют. ООП для каких-то случаев хорошо применим, а для каких-то нет. Тоже самое справедливо для любой другой парадигмы. А выбирать технологии только исходя из общей моды очень тупо.
Ответ написан
@malroc
Ну вот когда выйдет ОДИН хотя бы сколько-нибудь популярный фреймворк, построенный на функциональном программировании вместо ООП, тогда будет предмет для разговора.
Пока ничего похожего не видно даже на горизонте, здесь вообще говорить не о чем. Он велосипед что ли свой собирается делать? Ну можно посочувствовать тогда. И ему, и вам заодно. Ищите новую работу.
Ответ написан
saboteur_kiev
@saboteur_kiev
build engineer
Если проект будет писать 1-2 человека за срок до месяца, то можно и функциональное программирование.
ООП был придуман для того, чтобы сложный и большой проект, можно было грамотно и удобно разбить на части, которые работают максимально независимо друг от друга, и которые разрабатываются и поддерживается людьми, которые друг с другом почти не контактируют.
ООП подход - как раз и обеспечивает архитектуру того, что уменьшается вероятность факапа от несогласованности действий.

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

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

P.S. "я использую только функцианалиный подход" или "я использую только ООП и ооп-фреймворки" - это две крайности, каждой из которых есть своё применение. Если человек хочет обойтись без ООП пусть пишет на Си, там такого добра нет :)
Ответ написан
unclechu
@unclechu
Вообще можно провести эволюционную цеполчку:
  1. Процедурное программирование
  2. ООП
  3. Функциональное программирование

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

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

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

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

PS: Думаю стоит кинуть начальнику ссылку на это обсуждение.
Ответ написан
EDIT: если очень интересно, то вот как этот "гений" требовал, чтобы я кодил cloud.mail.ru


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

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

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