Ответ на пост «Программисты свернули не туда»⁠⁠9

Отнюдь, во многих фреймворках это более чем контроллируемо, плюс более-менее общепринятые вещи (роутинг, работа с бд) в любом случае несёт в себе абстракции. Мы же не в index.php ходим в бд и рисуем хтмл, верно?

Спортивного интереса ради: свежеподнятый проект на symfony от index.php до моего метода с отдачей строки проходит только через Kernel и HttpKernel. Кошмарный оверхед, прям чувствую как бездумно мы греем воздух в датацентрах.

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

Плюс мои закомые плюсовики малость ругали его "чистый" вариант, типа местный ооп там больше тормозит. Всё хочу попробовать сделать аналог на голанге и сверить, но лапки не доходят

Ну а тут у меня на руках свежий переезд, обложенный метриками по самое нехочу и прочими красотами, показывающий разницу в 0.5-1% производительности. Более чем достойная цна за имеющиеся возможности в плане архитектуры.

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

написанного легко заменяемой php-макакой

На тех проектах, где говняют в один файл, такими вопросами даже не задаются =)

Не совсем. Если мы про пхп говорим, то там до ненужного функционала интерпретатор даже не притронется, лишь в самом старте прокешировав индекс символов. Соответственно, неиспользуемое даже в оперативку не попадёт, не говоря уж про процессорное время.

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

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

А тврщ @sanovskiy просто набросил от души.

А есть точные замеры? На нашем проекте мы ушли от прямого использование pdo к доктрине, после сборки opcache производительность на том же уровнее. При том что шансов на ошибок сильно меньше и удобства гараздо больше.

Ну а где нужно прям реалтаймовая производительность, мы гошку заводим. И в среднем это 15% кода проекта, что показатель =)

30-50 используется, а остальные тоже грузят систему?

Минимально. Если взять Laravel\Symfony и использовать только нужное, то оверхеда будет только чуть.

Я понимаю, что библиотеки содержат избыточный функционал. При этом, или ты подключаешь библиотеку даже если тебе нужна только одна из её функций/подпрограмм. И эта библиотека грузится целиком в память сервера.

А процессорное время тоже расходуется впустую? И почему это сказывается на стороне клиента/пользователя?

Если что, моё познание в IT на уровне программ 80-90-х )

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

И через жопу реализация паттернов, которые фреймворк даёт. В итоге выйдет неподдерживаемое говно или конфетка, которая станет новым фреймворком.

я обычно ищу работы где не используют фреймворков. Как правило фреймворки обязывают тебя делать код в строго ограниченных рамках, за эти рамки нельзя выходить. Кому то это очень нравится, ссылаются на архитектуру кода, высокую поддержку кода, читаемость кода. Отдельно стоят CMS например WordPress или PrestaShop

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