Иван Корюков

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

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

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

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

Поэтому переход на typescript позволит только более точно воспроизводить классическое ООП. Ну и проверку типов добавит. Это само по себе полезно, но для ООП никакого значения не имеет.

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

Заметьте, про js я почти ничего не сказал. Потому что дело не в нём. Дело только в понимании ООП. У языков программирования, конечно, есть различные возможности и ограничения что которые позволяют использовать ту или иную парадигму. Но ООП на js можно было делать и до es6, просто потому что в js можно инкапсулировать код в объект.

И ещё, когда мы начинаем делить код на объекты, необходим механизм разделения кода на файлы и собирания его обратно. Т.е. нужна модульность. Лучше всего, конечно, использовать webpack, но вроде как в js есть и другие системы. Не сборки, а именно подключения модулей.

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

Т.е. ваши сервисы не должны запускаться по крону, а должны постоянно работать.

Вообще некоторые сборщики js кода, такие как webpack и rollup умеют делать tree shaking, т.е. по цепочке импортов и вызовов понимают какой код используется, а какой можно в итоговый бандл не собирать.

Вот вам в эту сторону копать надо.

ssh + htop
а вообще мониторинг серверов это очень обширная тема

Нужно.

В автодополнении есть две крайности.
Вариант один - просто разбиваем текст на слова, добавляем в список ключевые слова текущего языка и как-нибудь подсказываем то что начал набирать программист.
Вариант два - выполняем честный анализ кода, прям как это делает компилятор/интерпретатор, и в зависимости от контекста в котором набирается слово подсказываем только возможные варинты. Ну например, если мы набираем определение класса, то после названия может быть либо extends либо implements. Если набрали extends то дальше однозначно будет название класса, причём не финального.

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

Я для себя определил универсальный подход для отладки в любом сетевом окружении.
В простейшем случае, когда разработчик один, а сервер за NAT, надо на сервер прокинуть порт через ssh.
ssh user@host -R 9000 localhost:9000
При этом в php.ini xdebug надо настроить чтобы он коннектился на localhost:9000.

Когда разработчиков много, я использую модифицированный dbgp прокси.
https://github.com/MadridianFox/php-xdebug-proxy
Если он стоит на том же сервере что и php, настройки xdebug те же. Прокси слушает 9000 порт. Каждый разработчик выбирает себе уникальный порт и прокидывает его по ssh на сервер. Так же надо обратно прокинуть 9001 порт чтобы зарегистрировать свой idekey в прокси.

ssh user@host -R 9002 localhost:9002 -L 9001 localhost:9001

И самое главное - при регистрации своего idekey через шторм в поле idekey надо написать myidekey:9002
В этом же окне порт прокси - 9001, хост прокси - localhost.

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

В браузере, не важно, используете вы расширение или прописываете XDEBUG_SESSION_START, надо указать myidekey без порта!

В случае с докером вы можете либо добавить ssh сервер в контейнер с самим php, либо поднять дополнительный ssh контейнер. При единоличной разработке этого достаточно. Просто в зависимости от размещения ssh прописываете разные хосты в xdebug. Прокидывает туда порт.

Если разработчиков больше одного - выделяете контейнер с ssh + dbgp прокси и каждый разработчик прокидывает туда свой порт.

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

Потому что браузер игнорирует неизвестный ему тип инпута и считает его равным text

Попробуйте сначала конвертировать строку в utf-8, а потом использовать её как ключ.

Как вариант - сменить кодировку конфига на cp1251 или koi8r, ну и ключи перед записью тоже конвертировать в соответствующую кодировку.