Vitsliputsli

Используйте raw-формат в Body

Да, нужно именно теоретическое понимание. Чтобы когда на ревью джуну скажут, что он нарушил Single Responsibility, он не просил объяснений о чем вообще идет речь и тем более на стал доказывать, что его решение лучше. Нормально, если джун несколько "плавает" в понимании этих принципов (четкое понимание придет с опытом), ненормально, если считает, что с него требуют что-то лишнее.

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

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

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

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

был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку.

Не создает, конфликтующие ветки сами по себе, а конфликт решайте в ветке dev. При создании веток релизов из dev, этого было бы достаточно. Но, в вашем случае: сливаете первую ветку в master - тут все ок, а вот вторая будет опять конфликтовать, но уже с master, это решается мержем обновленного master в эту ветку. И да, вполне возможны расхождения dev и master, если 2 мержа были выполнены по-разному, поэтому мержите master в dev после таких манипуляций.

У вас нет проверки на пустой массив, поэтому возвращает 0. Не хватает проверки на float, на null уже нет смысла проверять, а проверять на массив не нужно при каждой итерации.
Т.е. что-то вроде этого должно быть:

function sum($arr)
{
    if (!is_array($arr) || count($arr)===0) {
        return false;
    }
    $sum = 0;
    foreach ($arr as $value) {
        if (!is_int($value) && !is_float($value)) {
            return false;
        }
        $sum += $value;
    }
    return $sum;
}

На втором сервере неделя начинается с воскресенья, а не с понедельника. Вероятно там очень старая версия php, в современных версиях неделя всегда начинается с понедельника. Либо обновляйтесь, либо смотрите как переопределить первый день недели.

Зависит от "повседневных" задач. Если не столкнетесь с адептами логики в базе, то написание хранимых процедур не понадобится. Обработка на стороне приложения как правило дешевле, но фильтрация данных и агрегация чаще всего осуществляется на стороне СУБД. Кроме основных операторов SQL нужно понимание транзакций (в том числе их уровней), варианты хранения данных (таблицы связей, EAV и прочее), нормализация, связи (внешние ключи используются почти всегда), индексы (не только какие бывают, но и как организовано сбалансированное дерево b-tree, как влияет селективность на выборку), план запроса, оптимизатор и сбор статистики, какие бывают локи и из-за чего, и для каких изменений нужно снимать нагрузку. Ну и сопутствующие вещи - миграции, фикстуры, драйверы СУБД, подготовленные запросы, sql-инъекции и т.п. Для начала достаточно иметь общее теоретическое понимание этих вещей, реально будете их изучать на практике, в зависимости от проектов и их нагрузки с разной степенью глубины.

То что вы хотите не нужно делать через http, либо используйте web-socket, либо полностью перетащите этот функционал на фронт. Http предназначен для получения данных, а не отправки команд-сигналов с сервера. Манипуляции с ajax или переполнением буфера - также будут извращением.

Укажите в команде composer update только тот пакет, который требуется обновить.

слышал, что можно просто удалить .lock файл и сделать по новой composer install. Отличается ли данное поведение от того, что произойдет при composer update?

Не отличается, не обнаружив .lock файл composer выполнит update вместо install.

и по сути это все действия которые я должен сделать на продакшене в данном случае?

Да, но не делайте этого под нагрузкой, сперва собирайте, а потом перенаправляйте нагрузку на новый код. Используйте blue/green, контейнеры, как написал Иван Шумов, или просто симлинки на одной и той же машине.

Какие еще классы разных API? REST API - это механизм взаимодействия, это внутренняя реализация, которая почему-то вытащена на верхний уровень, до уровня контроллеров. У вас должны быть бизнесовые сущности, и к объектам этих сущностей применяйте Принципы. А уже на более низком уровне для передачи данных бизнесовых сущностей используйте объект класса RestAPI, в котором, разумеется, не должно быть никаких завязок на специфику выше стоящих бизнесовых сущностей.
Ваш метод send выглядит странно, зачем он вообще нужен? Динамические методы это очень неудобно, IDE по ним вам ничего не подскажет и придется разгадывать этот ребус самому, а ничего более этот метод не делает.

если value существует, берем значение из value, иначе приравниваем 0.

$value = $value ?? 0
как уже предложили, но к
value = value || 0
это отношения не имеет. || - это оператор дизъюнкции, но в php он возвращает тип bool в отличии от js.

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

Поинтересовался книгой Clean code, но примеры там на java. Так вот, вопрос заключается в том, что можно ли эту книгу читать не только джавистам?

Язык значения не имеет, но конкретно по этой книжке, сперва прочитайте эту рецензию.

Можно ли подключиться один раз к базе mysql и дальше делать с этой базой любые запросы?

Можно.

Если "документы .php" - это файлы используемые одним процессом php, то только так и надо. Если нужно чтобы разные процессы использовали одно подключение к БД, то это вопрос не к php, а к тому кто будет поддерживать это соединение и шарить на процессы php. Есть persistent connection на стороне СУБД, но его лучше не использовать, т.к. не всегда оно корректно работает. Есть всякие ProxySQL которые могут это организовать, это и есть оптимальный вариант.

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