Crash

В IT каждый второй шизофреник, за своего сойдешь.

Также я не знаю математику. Особенно дискретную

математика и программирование - разные вещи, абсолютно.

У меня большая проблема: я не умею решать задачи

неумение решать задачи ВСЕГДА является следствием двух факторов:
- незнанием инструмента
- незнанием теории

прежде, чем решать задачи на ЯП необходимо изучить возможности языка, устно, прочитав "теорию" (учебник) и понять, какие инструменты язык предоставляет.

Если я сделаю, условно, 10 таких одинаковых проектов, будет ли от этого толк больше, чем от 10 аналогичных проектов на Ларавел?

Не будет.

Сейчас тенденция такая: работодателю НЕ НУЖНЫ теоретики, нужны практики на том, что востребовано. Точка. Я тебе это говорю как человек, писавший свой фреймворк в свободное время (по желанию от нефигделать) на протяжении нескольких лет. Это абсолютно пустая трата времени, никто это не оценит, а в некоторых случаях даже будут косо смотреть - век программистов прошёл, сейчас век знающих "либы". Лучше потратить это время на освоение того же Laravel.

который просто будет писаться заново каждый раз с какими-нибудь косметическими (и не очень) изменениями

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

Приведу реальный пример.
У меня был фреймворк в составе проекта.
1. Принял решение вынести фреймворк в отдельную composer-зависимость, написал систему модульности, при которой отдельное приложение - просто набор модулей, а фреймворк устанавливался через композер.
1.1. В итоге получилось два репозитория: существовавший ранее проект (назовем его "А") и фрейморк.
2. Принял решение сделать т.н. skeleton (назовем его "B") для будущих задач, т.е. некую болванку для будущих проектов.
3. Возникла основная проблема - актуализация клиентского кода между проектами "А" и "В" в процессе изменения интерфейсов фреймворка. Любое изменение/дополнение/улучшение в программном коде фреймворка тянуло за собой переписывание клиентского кода в проектах "А" и "В". Не потому, что всё ломалось, а потому, что это предотвращало технический долг и влияло на банальную красоту/чистоту кода.
3.1. Возникла проблема актуализации ресурсов (css, js) и базовых модулей между проектами "А" и "В". Приложение "В" (skeleton) должно было стать эталоном. В skeleton есть некий базовый набор CSS/JS, правил верстки и готовых модулей. Всё это постоянно совершенствовалось. Эти дополнения хотелось вносить в уже действующий проект "А", но делать это приходилось с кровью и потом, т.к. это была тупая ручная работа из разряда copy-paste, т.к. skeleton ("B") по своей сути - это готовый проект, как "А". И тут это всё нельзя было никак автоматизировать.

В итоге от скелетона, который планировался как "болванка" для будущих проектов, пришлось отказаться.

Поэтому твоя идея на базе своего решения клепать 10 сайтов - нежизнеспособна. У тебя банально не хватит времени на разработку фреймворка и актуализацию клиентского кода проектов.

Как вы себя мотивируете в данной ситуации?

Отвечу как автор того самого обширного ответа.

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

Есть ли сейчас смысл в оттачивании чистого PHP

Язык всегда первичен. Да.

Далее. Вот эта фраза

если мне +- хватает понимания, как работает та же Ларавел?

Ты серьезно думаешь, что у тебя "хватает понимания", как работает фреймворк? Больше не повторяй вслух эти слова. Никогда. Особенно на собеседовании. Иначе собеседующие тебя похоронят за плинтусом.

Может, при возможности стоит обратить внимание на другой язык(Го, шарп, нода)?

Сегодня разговаривал с HR-ом, дословно: php-шников и фронтов много. Больше остальных. Спрос на другие языки - go и питон - там низкая конкуренция. Не могу ей не поверить, т.к. php существует более 20 лет и за это время в отрасль вкатилась куча людей. Откровенно говоря, очень скоро значительный % пхп-макак пойдет в такси, включая меня. Конкуренция, судя по собеседованиям - адовая. Спрашивают сам язык и ещё 250 сопутствующих технологий.

не рискую пока идти на собеседования потому что хочу закрыть чеклист: несколько проектов в портфолио на чистом PHP, laravel; подучить JS с Аяксом; Добить тестирование, а также чуть разобраться с докером, линуксом и теоретической частью этих ваших интернетов.

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

Битрикс супер, пиши на Битриксе.

Привет,
Тут тема такая, основная фишка в том, что нет чёткого определения, что такое архитектор. У кого-то в компании аналогичная должность может называться и руководитель проекта, у кого-то тимлид, у кого-то архитектор. И соль в том, что любой вышестоящий начальник вкладывает в эту должность абсолютно разный набор функциональных обязанностей.
Что могу посоветовать, надеюсь, это станет ответом на вопрос. Есть проект на гитхабе роадмап тимлида. Там есть прикольные картинки и, собственно, что вам нужно сделать:
Первое, принять, что теперь за всё отвечаете вы лично. То есть, вроде как отдел кадров подбирает персонал, но всё равно именно вы набираете под себя команду и вы лично за неё несёте ответственность. Если вам задают вопрос по продукту - типа, что это за кнопка добавилась - ответ "я не знаю, это без меня добавили" неприемлем. Если вылетел баг на проде - то обосрались лично вы.
Второе, после принятия ответственности, необходимо пройтись по всему дереву-снежинке и отметить, в каких областях у вас хорошо, а в каких провал. И из первого пункта тут вытекают разного рода решения, например планёрки (или скрам) для того, чтобы именно вы были в курсе, кто чем занимается. Код ревью и внедрение ci/cd, чтобы не вылезали баги на проде и так далее. Вот тут уже, если вы не разбираетесь в какой-то узкой области, можно взять какой-то курс. То есть, нет такого общего "курсы для архитекторов" - там вам воды в уши нальют, есть роадмап, по которому вам надо идти. И есть узкоспециализированные курсы под каждую область, где у вас провал, вот так.
Третье, необходим баланс, вам нельзя замкнуть все процессы на себя. Есть правило автобуса (что будет с проектом, если вы не выйдете на работу?). Это очень полезное правило - процессы должны быть выстроены таким образом, чтобы вы могли спокойно уйти в отпуск и вам никто не звонил. Это тоже очень важная составляющая организации работы. Вообще авралов не должно быть, только штатные ситуации. Если вы решите поменять работу, чтобы не пришлось в последний день собирать документацию с айпишниками, логинами/паролями участвующих в вашем проекте виртуальных машин, так как должна вестись своевременная документация по ресурсам и используемому ПО. Вроде как про это никто заранее не говорил, но это ваша обязанность и вы отвечаете за такие вещи лично (повторюсь ещё раз о важности делегирования и отсутствия переработок)

Я программист Java (Enterprise) недавно получил новую должность архитектора.

Это как сказать > сделали фитнес инструктором, вопрос: подскажите как накачаться.

Какой ответ ждут от разработчика?

примерно такой:

Ваше благородие! Виноват! Исправлюсь! Не велите казнить! Обязуюсь не спать трое суток, а решать задачу!

А знаешь почему? Потому, что 95% из вас - терпилы по жизни.
Я вообще не понимаю, как в мире IT, в разработке, можно говорить о каких-то сроках. Тривиальная ошибка может стать ступором на неделю - легко!
Это землекоп или укладчик кирпича может объективно говорить о сроках, там +/- процессы длятся одинаково. В IT - нет.

Не работайте там, где сроки горят. Полно мест, где нет никаких горящих сроков, где вас не заставляют лезть вон из кожи. Читай: ebanoe-it.ru/2020/12/28/right-way/

На этот говнокод невозможно смотреть, у меня кровь из глаз пошла.

Давай ты для начала
1. Почитаешь об автозагрузке классов
2. Перестанешь писать require в методах и почитаешь про внедрение зависимостей.
3. Перестанешь использовать собаку @ там, где это не требуется. А именно в условии if (@$_REQUEST['select']) , для этого есть функции isset и empty.
4. Внятно сформулируешь свой вопрос без кучи этого околорабочего кода и напишешь небольшой класс, описав проблемы с геттерами и сеттерами.

www.williamspublishing.com/Books/978-5-8459-1586-3.html


https://refactoring.guru/ru/store

1. Теорию оценить гораздо проще, чем практику
2. Предполагается, что хороший специалист должен хорошо знать теорию.

объяснить чем отличается udp от tcp не смог

Выглядит очень странно, на самом деле. Вроде же не сложно:
TCP имеет подтверждение о доставке, а UDP нет, ну а дальше всякие нюансы идут.

Автор, posters тебе правильно сказал - нет никакого смысла делать библиотеки-фреймворки. Этого гамна в гитхабе валом, это все рождается и умирает вместе с программистами. 1 из 100 000 делает какой-то востребованный инструмент, которым пользуются другие разработчики. тут играет роль масса факторов: профессионализм, удача, нужное время и место.

Если тебе заняться нечем, то как тебе выше сказали - над пилить некое коробочное решение для бизнеса (и никак иначе). Вероятность того, что оно у тебя выстрелит и у тебя его будут покупать стремится к нулю, но это намного лучше, чем писать очередной фреймворк.