За что я ненавижу Eloquent ORM

Вы ожидали, что я пол проекта сброшу в комментарии?)) Это простой пример использования. Не вопрос, меняем $request на string $name и называем это сервисом MyModelSaver, вот вам и БЛ. Unit тесты от этого не сильно поменяются.

Хотя, я так подумал, а почему вдруг этот же метод не может быть в сервисе?)) Есть некий DTO My\Vendor\Dto\Billing\Request со свойством name. Есть сервис, управляющий созданием и сохранением MyModel. Не вижу проблем.

За что я ненавижу Eloquent ORM

Расскажите подробнее, в чем проблема с тестированием бизнес-логики?

Напишите unit тест

public function store(Request $request)
{
    // Проверка запроса...

    DB::beginTransaction();

    $myModel = new MyModel;

    $myModel->name = $request->name;

    try {
        $myModel->save();

        DB::commit();
    } catch (\Throwable $exception) {
        DB::rollBack();

        $this->logger->error($exception->getMessage(), ['exception' => $exception]);
    }
}

За что я ненавижу Eloquent ORM

А потом менеджер приходит и спрашивает, почему такие неоправданно высокие расходы по времени?

Отличный повод еще и софт-скилы прокачать))

За что я ненавижу Eloquent ORM

Тестировать модели можно, просто… Немного не просто.

Пфф, всего-то коннекшн замокать и докинуть пару десятков часов в ETA на задачу))

Это также, позволяет избавиться от лишних проблем на этапе формирования MVP, который обязательно (практика показывает, что такое случается редко, но все же) планируется переписать

Увы, это утверждение правдиво только для людей, слабо знакомых с Entity-Repository.

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

Немножко расширю

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

За это вам и платят.

Бизнес не хочет зависеть от случайностей.

А вы хотите?

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

Мысли о том, что плохое настроение ведущего разраба приведет к проблемам в:

• медицинском ПО будут причиной постановки ошибочного диагноза
• банковском ПО приведут к ошибочному обнулению счета
• складском ПО приведут к его разрушению, или остановке работы
• ПО управления АЭС приведут к катастрофам
• ПО управления транспортных системах приведут к катастрофам
  ...

меня пугают до усра*ки. Если ваше плохое настроение влияет на вашу работу — сорян, вас надо гнать ссаными тряпками.

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

Если эти хотелки не нужны — ваша работа как бы тоже.

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

Если для вас эти "лохи" являются конкурентами — вы один из них, что поделать.

Мой tslint не разрешает добавить мне лишний пробел. Мой код не билдится, если я назвал переменную не с той буквы.

Ок, что происходит в противном случае? Ваш код упадёт / или будет работать не прогнозируемо уже в рантайме. Исправлять потом сложнее и дольше. Спасибо говорить за это нужно))

Представьте кейс: вы написали сложный перфоманс сенситив модуль, а вам говорят: «Послушай, он слишком сложный. Давай ты сделаешь его попроще, не важно, что работать будет хуже». Звучит абсурдно?

Вовсе. Вы не замечали, что обычно чем выше квалификация у инженера — тем проще читать его код? Код же не пишется один раз и как бы всё. Он поддерживается, тестируется, модифицируется и в принципе читается на много больше раз, чем пишется, при этом не только вами.

Программируя, я хочу заниматься творчеством.

И в чем проблема? Творите opensource и будет вам счастье, радость, радуга.

Хочу иметь огромное число опций, когда дизайню систему.

Ага, а потом сводить вместе callback + Promise + async-await + *Sync, отличная идея. Чем больше у вас вариантов — тем больше сил нужно потратить на их объединение.

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

Если "безликий код" делает из вас машину, ну что ж это печально. В моем текущем проекте, даже с очень жесткими стандартами качества / оформления и кучей соглашений — я спокойно могу определить кто автор того, или иного куска кода, не смотря в blame.

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

Неа, задачи перейдут на более высокий уровень. Вы часто ассемблере пишете, или на машинных кодах?

Я бы разделил бизнес и ИТ, чтобы программированием могли заниматься только некоммерческие организации.

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

Чтобы требование «выпускаем что есть, иначе прибыль уйдет» было морально недопустимым.

Когда вы слышите подобное — мне так почему-то кажется, вы уже знали, что это возможно. Раскрою секрет — так происходит НЕ всюду.

Я бы всеми силами держал порог входа в программирование как можно выше.

Дык не вопрос, есть Haskell, Erlang, Scala,… На том же Erlang действительно крутых специалистов в Украине человек 50 может не набраться. В чем проблема? Не нравится Go — не пишите на нем.

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

Не понимаю автора со всей силы. Безликий код — это отлично. В моей практике, к сожалению, "творчество" чаще всего выражается в не следовании стандартам и не очевидным решениям, над которым далее приходится ломать голову, бывает по несколько дней. С комментариями в стиле "добавь к счетчику, сколько времени ты потратил на это метод".
Особенно это касается больших проектов на десятки/сотни программистов. Как показывает (моя) практика — чем строже стандарты, кодстайлы и вот это вот все — тем лучше. То, что в Go-шке сделали gofmt и утвердили стандарт оформления — это замечательно. Сообществу PHP на понимание необходимости такого стандарта потребовалось более 10 лет!

Так ли хороши джуны?

Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.

Видимо вы не сталкивались с мало-мальски серьезными проектами и демонстрируете Даннинга-Крюгера.

Так ли хороши джуны?

На счет более производительней — очень сомневаюсь, на счет дешевле — согласен.

Так ли хороши джуны?

По вашему рутинные простые операции синьоров не достойны и просто будут отброшены, без наличия джунов?

Глобальные объекты в PHP

Нет вообще никакой нормальной среды разработки.

Тут в 2018-ом есть PhpStorm, а вы из какого года пишете?

Вы не можете отстрелить себе ноги, но вы добровольно уже отрезали себе руки. Догмами, PHP right way и PSR.

Если у вас нет понимания и умения выполнять некоторые правила / стандарты — о каких руках может идти речь?))

давайте сделаем 4 пробела для отступа вместо одного символа табуляции, так будет надежней.

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

Бред это… бред…

Бред — это ваша упоротость на не желании понять, зачем нужны вот эти всякие стандарты и почему их следует придерживаться, с головой конечно же.

Когда же уже некто из ваших вождей вам скажет об этом, чтобы вы все проснулись…

… у меня вождя нет, ни одного, а что ваш думает по этому поводу?

Глобальные объекты в PHP

если бы была доступна для меня нормальная бекэнд среда для разработки

Почему для остальных людей она доступна, а для вас не доступна?))

Как вы думаете почему появляются новые? Вероятно из-за того что не устраивают имеющиеся и не устраивают по нюансам их использования.

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

• легкость чтения
• легкость поддержки и расширения
• безопасность
• переносимость
• тестируемость
• производительность
• надежность

А ваша хотелка с мнимым удобством — это просто хотелка.

Глобальные объекты в PHP

То, что вы ларку в пример ставите — это конечно круто, но для мелких проектиков.
Тут вопрос был про CodeReview, возможно вам пригодится https://toster.ru/q/276441#answer_723827

Глобальные объекты в PHP

а бекэнд фреймворка нет и нет

Symfony? Он не без какуль но все же.

найти статистические данные на скольких сайтах в Интернете реально используется jQuery

И что вы этой статистикой хотите понять? Что большая часть сайтиков на вордпресиках, джумлах да друпалах с опенкардами? Эти цифры, даже если бы вы их получили буквально ничего не значат.

jQuery это удачное решение, а по бекэнду его нет.

Собственно и что? На момент создания — эта либа упрощала жизнь. Сейчас есть куча других более лучших. В пыхо мире раньше CI был в популярен, а что сейчас? Идеи, заложенные в этом фреймворке не актуальны.

Глобальные объекты в PHP

Использовать глобальные переменные — плохо.
Давайте использовать глобальные переменные, но через кастомную функцию!

Автор, вы пытаетесь решить глобальную проблему очень кривым костылем.

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

Вы путаете свободу мышления и неумение спроектировать архитектуру под соусом "очень-очень удобно"

Странные операторы в PHP

Магия форматирования))

ООП без «О»

создавался объект mysqli и присваивался свойству sql каждого объекта. Можно только представить сколько лишних действий в пустую и какой перерасход оперативной памяти происходит.

Да, ссылки нынче дорогие(((

Наверно сравнение на «сверхмалых» числах не дает полной картины

И смысла не имеет, если на то пошло

но это тот самый оверхэд от которого можно отказаться.

Это экономия на спичках

Причина не любви к работе с объектом (при передаче другому методу), в том что у меня есть фобия что он не тот за кого себя выдает

Type hinting появился еще в 5.1

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

Как же инкапсуляция?

Я не спорю, бывают ситуации, когда статика оправдана, например методы стандартной библиотеки, и то далеко не всегда. Но память — это вообще не тот случай. То, что парни из вашей работы не смогли в lazy load — это печально.

Но, в большинстве случаев статика приводит к:

1. Бесконтрольной связности и хрупкости проекта

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

1. Экспоненциальному росту сложности тестирования

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

1. Статика с состоянием — это пичалька

Вы просто должны верить, что она как-то работает и ниоткуда она не будет вызвана не правильно, или не в той последовательности.

Зависимости наших зависимостей или несколько слов об уязвимости наших проектов

lock файл в npm — это чисто информационная штука. Он не гарантирует то, что будут установлены именно те зависимости, что в нем указаны.

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

Хотите рабочий lock файл — используйте yarn

Постраничная навигация на PHP

Лучше задавайте вопросы на toster.ru с уточнением, что нужно ревью вашего кода

Постраничная навигация на PHP

oxidmod В этом вы правы, не обратил внимания.

Постраничная навигация на PHP

Что плохо в вашем коде, при самом не пристальном взгляде

• PSR не поддерживаете
• Про SOLID (SRP особенно) не слышали: ваш навигатор — это роутер + шаблонизатор + генератор урлов + контроллер
• Используете супеглобальные переменные, про это статей написано много
• Параметры расчета захардкожены. Например, нет возможности показать по 4 страницы справа и слева от текущей, для этого нужно менять ваш код.