Vitsliputsli

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

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

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

Можно.

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

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

Как и написано в ошибке: An iterator cannot be used with foreach by reference - итератор не может использоваться в foreach через ссылку.
mysqli_query возвращает итерируемый объект, т.е. объект, который имеет метод для получения итератора, который знает как итерировать объект. При итерации foreach обращается к соответствующему методу итератора, который возвращает нужное значение. Т.к. это просто значение, а не свойство объекта, обратиться по ссылке к нему не получится.

Почему если fread() стоит раньше шем fwrite(), то консоль вообще ничего не показывает. А если fread поставить ниже fwite() то консоль выводит $msg.

Вы запускаете сервер и он ждет подключения. Запускаете клиент он подключается к серверу. Затем сервер начинает слушать сокет $msg=fread($connect,1024). Если клиент после подключения сделает fwrite($socket_client,$ENQ), то отправит на сервер строку $ENQ, сервер примет ее, выведет на экран и закроет соединение. Если вместо fwrite напишите $msg= fread($socket_client, 1024), то клиент будет слушать сокет. В итоге, сервер и клиент оба слушают, оба ждут передачи, а так как никто из них ничего не шлет, то будут это делать до бесконечности.

Вы описываете 2 стандартных подхода:
1) падаем в ошибку при любой непонятной ситуации;
2) при непонятной ситуации пробуем продолжить работу, если это возможно.
1 подход применяется в тех местах которые работают критически важными бизнесово данными. 2 подход для маловажных вещей, которые не способны исказить вещи из предыдущего предложения.
Т.е. в большинстве случаев нужно падать в ошибку, и только если знаете, что ошибка не несет никакого серьезного аффекта (к примеру выводить текст на экран жирным шрифтом или нет), то можно продолжать работу.

Если необходимо удалить строки с номера в check до конца файла, то:
sed -n "1,$((check-1))p"

Если нужно обязательно через ip link show и awk:

ip link show | awk '/185.230.140.160/{print p $0; p=""; next} {p=$0 ORS}'

через ip link show и grep:
ip link show | grep -B1 185.230.140.160

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

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

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

Фронтэнд... Если какая ошибка то у него работа останавливается и он пишет просто в трелло "не работает метод такой то..."

После этого мокирует данный метод и работает дальше.

Вы хотите странного, если коммиты делались, почему это не отображать?
Но если очень хочется, при подобных действиях коммиты не удаляются, в дереве они не отображаются, т.к. ни к чему не привязаны. Чтобы удалить коммиты используйте git reflog expire или git reflog delete.

Достаточно распространённая практика, как правило, так страхуются, чтобы можно было уволить легко. Или как вариант устраивают по ГПХ. Если это лучший вариант, то пробовать. Но они вам ничего не должны, соответственно могут задерживать зп, платить 1 раз в месяц, в худшем случае кинуть. По закону, отсутствие договора это проблема работадателя, но то, что работали, нужно будет доказывать вам, если, конечно, захотите с этим связываться.

Как достичь результата Array ( [key] => 1 [key2] => 3 ) при исходных данных?

Никак, на этапе создания массива $arrays = [ "key"=> 1, "key"=>2, "key2"=> 3 ], элемент с ключом key получил значение 1, а затем значение было переписано на 2, соответственно 1 значение безвозвратно потеряно.
Опишите задачу которую решаете, а не только как решаете.

Как понять достоин ли ты более лучшей зар.платы или ещё не дорос и не надо высовываться даже?

Сходить на собеседование, иных вариантов просто нет. Пока вы сидите и мечтаете, новая хорошо оплачиваемая работа сама к вам не придет.
Работать с api, писать свой api - это must have для разработчика, но насколько качественно вы это делаете? Насколько хорошо вы знаете указанный стек? (вопрос риторический, собеседования помогут на него ответить). Symfony и Laravel это неплохо. Clickhouse - очень интересно, вы его знаете, понимаете? Сами формировали работу с ним? Или просто используете, и для вас это непрозрачно?
Английский - это проблема многих русскоязычных, в большинстве случаев умения читать техническую документацию достаточно, во всяком случае на первых парах.
С удаленкой сложнее, после карантина работодатели стали более лояльны в этом плане, появилось больше вакансий, но сейчас опять смотрят с подозрением, т.к. производительность все же ниже для большинства.
Вопросы на собеседованиях помогут вам ориентироваться в том что нужно сейчас, зачастую бывают вопросы которые считают дико важными, а чтобы изучить их вам понадобится 1-6 часов. Пробуйте.