Adamos

Б-же, до чего же у вас много свободного времени.

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

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

Альтернатива - литр пива за 1,5 часа до сна или две плюшки [ЗАБЛОКИРОВАНО РКН] за час до сна.

И кста, "больше времени на изучение" никогда не равно "будет эффективнее".

ansible

Самый простой способ это добавить mount /var/www /home/gavrila/ftp/sites в автостарт системы. Но это небезопасно и подходит только для поиграться.
Насколько я помню, для администрирования сайта делают отдельного пользователя для каждого сайта и этому пользователю выставляют папку с сайтом как home каталог. тогда при логине по FTP система автоматически перейдет в папку с сайтом. vsFTPd умеет брать конфиги пользователей не из системы, значит можно не засорять систему лишними пользователями. Почитай про добавление пользователей в vsFTPd. Основной посыл это заставить ftp сервер chroot`нуть тебя в папку с сайтом при логине.

TDD Кента Бека - помогает понять, откуда взялась популярная архитектура фреймворков тестирования (ссылка) - читала, мне частично помогла.
xUnit test patterns - не читала, но все советуют - тоже объясняет принципы написания тестов без четкой привязки к технологии (ссылка).
По разнице в подходах тестирования - существует пирамида тестирования, но на практике мне не всегда понятно, где границы - приемочные и UI тесты ориентированы на use cases - т.е. на путь - в какой последовательности юзер проходит фичу и какой результат ожидает на каждом шаге (заходит на страницу, заполняет данные, ждет ответа; программа-клиент получает токен, шлет запрос, ждет респонс), а модульные тесты ориентированы на проверку кода как изолированных элементов - т.е. тестирование происходит отдельно от общего процесса, в котором этот код используется, чтобы можно было локализовать проблему с максимальной точностью.
PHPUnit я изучала только по документации, просто прошлась по всем примерам, считаю приемлемым вариантом изучения. Лучше сначала хорошо понять PHPUnit, а потом учить Codeception. Учиться, как мокать и стабать, можно уже на конкретных задачах, по мере надобности.

Разработка и контроль версий

Читаем про git flow, восхищаемся и интегрируем.
Читаем PSR-ы, восхищаемся и интегрируем. Не помешает: Попросили проверить код, на что смотреть нужно?
Читаем про vagrant. На базе вот этого вот строим dev окружение. Можете поиграть с https://puphpet.com/. До docker все же стоит дорасти.
Постигаем Phpstorm, и радуемся жизни.
Можете посмотреть так же: https://github.com/index0h/php-conventions

Тестирование

Читаем про phpunit, восхищаемся и интегрируем.

Документирование

Рекомендую взять за правило: документирование алгоритмов нужно только в крайнем случае, когда используются некие хаки. Говнокод лучше переписать на что-то очевидное, чем объяснять, какая муха вас укусила и где.
Что касается docblock-ов для помощи ide - это отличная идея.

Деплой

Самый простой и надежный способ: root у вашего nginx/apache указывать как ссылку на каталог текущей прод версии. При релизе - заливать код с помощью rsync в новый каталог, а далее менять ссылку на новый релиз.
Например у вас каталог с версиями кода:
production -> v1.0.2 - текущая версия
v1.0.1 - старый релиз
v1.0.2 - текущая версия
v1.0.3 - новый релиз
Когда подготовка завершена - вы только меняете симлинк production на v1.0.3. Если что не так - можно быстро откатиться на предыдущую версию.

Вопрос сам по себе глупый. Jquery - это и есть js. По сути, это набор функций, упрощающий разработку и сокращающий код. То что будет быстрее зависит от твоего ур-я. jq писали не глупые люди, сможешь ли ты написать лучше? Не думаю. Другое дело, что функции в jq более универсальны, для этого приходится жертвовать скоростью, но разница в скорости выполнения скрипта будет в пару десятков миллисекунд, а вот что касается скорости загрузки, ты можешь сократить код с jquery на 20-30% минимум.

https://kassa.yandex.ru/developers/using-api/testing
ну а настройки хранить в .env файле, который в гитигноре

Кот Том отжирает около 20-60 мегов памяти. Мускул - примерно также. (но конечно же есть варианты). Вместо tomcat можно взять Jetty - ест гораздо меньше - мега 2 в минимуме. В принципе, если не делать мемориликов и утечек памяти, то любой хостинг начального уровня на 1 CPU и 512Mb - за глаза, даже с кешированием, гусарами и куртизанками.
А все остальное: производительность, rps и все остальное - зависит только от вашего приложения, кеширования, архитектуры, работы с базой и данными. Как пример linux.org.ru , сайт с гигантской аудиторией. Вот что они о себе пишут - https://www.linux.org.ru/about (см. Софт и Сервер).

tar + cron, классика всех классик.

Можно rcync + cron.

Манов полон Гугл.

как писать поддерживаемый код?

Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
https://twitter.com/mjackson/status/1171524189850701825

Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.

Что гуглить, что учить?

Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

Может литературу какую почитать посоветуете?

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

Можно ли себя называть миддлом, если твой код говно?

Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

И ответ на главный вопрос.

Как перестать говнокодить и принимать неверные архитектурные решения?

Это невозможно. Все проекты, которые чуток сложнее CRUD-ов, рано или поздно обрастают говнокодом. Никто не пишет идеальный код. Код должен работать и решать проблемы бизнеса.

Вам необходим utf-8 с BOM
UPD:
Как это сделать:
.to_csv('file.csv',encoding='utf-8-sig')

JSON такого объема в принципе идея плохая. Встроенная функция json_decode умрёт, придётся писать какой-то парсер.
Потому что эти 15 гигабайт должны будут целиком загрузиться в оперативную память, потом перестраиваться в объект. Итоговое потребление оперативной памяти пророчествую, не меньше 30 гигабайт и то считаю себя наивным.
Ключевая проблема - файл нельзя читать порциями по заранее известному разделителю, получая валидные фрагменты JSON.
Возможно добрые люди уже сделали из этого файла пачку JSON - просто дописывая построчно отдельные объекты, но тут лучше показать фрагмент файла, чтобы предлагать методы оптимизации.

Посмотрите такой вариант для командной строки, запускайте на сервере который не жалко, возможно придётся потом его ронять в перезагрузку - https://stedolan.github.io/jq/

Более цивильный вариант - CSV, читать построчно, копить пакет запросов в БД, пачкой в несколько десятков запросов лить в базу.

UPD: гениальный вариант - а если залить это счастье напрямую в MongoDB, а потом по отдельным записям кромсать - получится?

Решение:

class Database {
  private $mysqli;

  public function __construct(){
    $dsn = "mysql:host=localhost;dbname=banan165_database";
    $this->mysqli = new PDO($dsn, "root", "");
  }
  public function query($sql){
   return $this->mysqli->query($sql);
  }
}

$db = new Database();
$db->query("INSERT INTO categories(name) VALUES('PDO')");

Но если правильно - так не делается.