0x131315

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

Быстрый поиск всегда осуществляется по индексу - специально подготовленному набору данных, содержащему только ключевые для задачи поиска данные, в сжатом формате, и размеченные определенным образом для быстрого доступа к записи.
Индексы сегодня полностью обслуживают специальные поисковые движки, коих на рынке много. Велосипеды тут не нужны.
Индексов может быть много - так можно изолировать непересекающиеся наборы данных, и избежать больших "общих" индексов.
Если производительности одного сервера не хватает, применяют кластеры - поиск по индексам хорошо поддается кластеризации.
Чтобы обновлять индексы нужно периодически выполнять переиндексацию - вычитывать полный набор данных и заполнять ими индекс. Это очень тяжелый процесс, поэтому обычно его делают редко и в малонагруженное для сервиса время.
Чтобы можно было искать с учетом всяких прав и статусов сообщений, эти права и статусы сохраняются в тот же индекс как атрибуты, и участвуют в поисковом запросе. Так можно персонифицировать поиск.
Чтобы индексы работали как в реальном времени и соответствовали данным приложения, на приложение навешивают хуки: пользователь скрыл сообщение - сработал хук и переиндексировал только одно это сообщение, что практически не дает нагрузки.

Возможно стоит выделить ту часть, что работает с БД, в отдельный сервис?

Активировав 2fa, получаешь одноразовый токен для устройства и десяток одноразовых резервных токенов для входа.
При утере устройства, входишь через один из резервных токенов, анулируешь токен устройства, и перевыпускаешь новый.
Утеря устройства и утеря/исчерпание резервных токенов - потеря аккаунта.

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

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

Формирование одних только ТЗ у целого отдела аналитиков занимает полгода. Множество туров переговоров и согласований.
И вот пришел топовый разработчик, и за месяц смог не только все это прочитать, оценить, но и сделать.

Крупные проекты так или иначе используют CMS.
Это выглядит как специальный интерфейс для редактирования статей и товаров.
Через него можно редактировать старые, и добавлять новые.
Также сайт часто связан с какими-то бизнес-системами, типа CRM, 1С, и обменивается с ними информацией.
Например склады и магазины работают с 1С, соответственно цены и остатки товаров приходят на сайт из 1С.
Службы доставки работают с CRM, соответственно цены и условия доставок приходят от CRM.
А на самом сайте хранятся характеристики товаров, фотографии, видео - всё это в 1С и CRM не нужно, но нужно покупателям на сайте.
Инициировать изменение данных может множество людей через множество систем: постоянно идёт какая-то аналитика, прогнозы, стратегии, маркетинговые акции. Начальники планируют политику, и вводят свои ограничения.
Сайт всё это отображает и учитывает.
Нет какого-то одного человека, который бы лично следил за всем. На каждом уровне управления множество людей, оперирующих разными понятиями.

Тут чистая экономика.
Контроллеры ставят в основном в массовые устройства.
Это значит что каждый сэкономленный доллар - это десятки, а то и сотни миллионов прибыли на ровном месте.
Подобные суммы с лихвой покрывают время программистов, поэтому им ставят задачу уложить функционал на самый дешёвый контроллер, который ещё хоть как-то способен потянуть этот функционал.
Отсюда - высокая степень оптимизации кода при работе с контроллерами.
Нужно максимально использовать все особенности конкретного контроллера - программисты много работают с даташитом.
Язык должен позволить максимально полно использовать систему команд конкретного контроллера, и гибко управлять регистрами и памятью контроллера.
Поэтому в ходу в основном ассемблер - с ним можно писать максимально компактный код.
Но функционал зачастую достаточно большой, чтобы его целиком писать на ассемблере.
Поэтому, в целях экономии времени, пишут на Си, с использованием библиотек, а самые ответственные места реализуют с помощью ассемблерных вставок.
Благодаря этому удается реализовать почти все преимущества и ассемблера и Си: быстрая и достаточно полно контролируемая разработка, с достаточно компактным и быстрым кодом.

С симками ситуация иная - там важно было реализовать кроссплатформенный код. Поэтому используют java, не смотря на ресурсы.

В более мощных контроллерах в ходу уже не конкретный язык, а целые ОС. В основном в прошивках просто зашивают Линукс, а отдельные части по управлению контроллером реализуют на Си как драйвера.

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

Так что все зависит от здравого смысла и стоимости.
Просто так везде пихать java - немного глупо.

Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.

Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.

Систем трекинга много, всяких.
Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.

Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

Плюсы подхода: почти всегда укладываемся в бюджет, часто обходимся дешевле договоренностей, хорошие отношения с заказчиками.
Минус подобного подхода - приходится часть бюджета резервировать на риски, эта часть бюджета замораживается на два спринта, и может быть влита в 3й.
Как итог заказчику приходится закладывать бюджет чуть больше необходимого, но за счёт этого получаем намного более предсказуемое и стабильное планирование, к тому же в большинстве случаев этот небольшой переизбыток бюджета остаётся неиспользованным, и в среднем это бесплатно: то, что заморожено в текущем спринте, будет разморожено в следующем, и через спринт может быть пущено в дело.

ИМХО наиболее актуально - докер.
Банально - прост в настройке, есть уже собранные образы на любой вкус, минимальные накладные расходы (можно позволить себе меньше памяти и дешевле железо), лёгкий мониторинг и управление сервисами. Умеет изолировать сервисы, сети и ресурсы. Умеет поднимать упавшие сервисы. Умеет управлять кластерами. Есть множество удобных веб-морд для управления/мониторинга из любого места, где есть браузер.

По разбиению - рекомендую БД вынести в отдельный общий (глобальный) контейнер, т.к. это будет одна из самых тяжёлых по памяти частей. Несколько БД держать дорого, и имеет смысл, только если проекты несовместимы с общей БД, но такое редкость.
Часть проектов может работать только с mysql - тогда нужно держать два контейнера с БД: mysql и postgres
Понятно, что для каждого проекта нужен отдельный ограниченный пользователь в БД.
Такая организация не только экономит ресурсы, но и позволяет управлять всеми БД через одну веб-морду, а также позволит легко прикрутить бекапы сразу для всех проектов.

Также отдельно стоит вынести nginx, который будет принимать подключения, обеспечивать безопасность и маршрутизацию по контейнерам. Как минимум это нужно, чтобы собрать все общие настройки в одном месте, и для возможности разделять один внешний порт на множество проектов.
nginx из проектов можно заменить глобальным (nginx довольно гибкий, достаточно перенести настройки), а можно и не трогать - nginx довольно дешёвый по памяти.

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

Естественно все это нужно собирать под docker compose
И придерживаться правила: всё, что нужно проекту для работы, должно быть в одном docker compose файле (читай - каждый проект в своей папке)

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

Тут решает не возраст, а желание.
Просто с возрастом падает спрос - меньше компаний готовы будут сделать оффер.
Но 30 - это не тот порог, проблемы будут если начинать в 40-50, это будет гораздо сложнее.
Впрочем, если наработать портфолио, пройти курсы, получить сертификаты, в общем заиметь что-то, что можно будет предъявить как доказательство своих компетенций - проблем с трудоустройством не будет.
Основная сложность у компаний не возраст, а риск: потянет этот стажёр свои обязанности, или его найм - потеря денег и времени.
Понятное дело, если есть хоть что-то, кроме слов и обещаний - это уже весомый аргумент.

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

Я обычно под отдельную задачу создаю свою ветку, и пилю спокойно задачу в ней. Это позволяет не портит основную ветку незаконченными задачами.
А в коммиты сливаю отдельные фичи задачи. Это позволяет коммитам быть наглядными, позволяет быстро искать реализацию фич в истории, и позволяет безопасно и быстро откатывать фичи, если больше не нужны.

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

Ежедневные/ежемесячные коммиты - это вообще жесть.
Git - это история, каждая запись в ней должна иметь смысл.

Многие запросы на битрикс немного ускоряются, если уточнить запрос, например вместо 'IBLOCK_ID'=>10 указывать '=IBLOCK_ID'=>10

В процессе интеграции sbercredit. Аналогичные проблемы.
В документации запросы странного вида, такие не выдает ни http_build_query, ни key-value подстановка.
Плюс запросы GET, но с требованием POST-заголовка application/x-www-form-urlencoded)
Примеры POST-запросов в документации неадекватные, и завести их так и не удалось ни в каком виде.
Оказалось что API принимает только GET, и http_build_query вполне хватит.

Проблема была в документации: запросы составлялись по их документации, но... ничего не работало. И API не умеет говорить ничего, кроме system error)
Разобрал их API по кусочкам, оказалось что оно документации мало соответствует - многие необязательные поля на деле обязательны.

Сейчас следующий круг ада: API принимает запрос, отдает данные для перехода на шлюз, но... теперь шлюз отдает ошибки в web-интерфейсе)
Оказалось поле muasure было обязательным. При этом в документации в примерах запросов оно пустое, и API на пустое поле ошибок не выдает. Такие дела.

ИМХО ключевое в php, когда имеешь базу - это не сам язык, а понимание того, какую роль он выполняет, и какое место в архитектуре эта роль занимает.
Что касается php, то это в первую очередь скриптовый язык, созданный специально для связи Фронта с Беком, т.е. основная его функция - предоставление доступа к БД сервиса для html и js-кода, работающих на фронте.

На сегодняшний день php решает следующие задачи:
-доступ к БД
-вспомогательные вычисления
-шаблонизация
-связь с внешними сервисами
-предварительное кеширование

Нужно в первую очередь понять как работает Веб, что такое фронт и бек, как они взаимодействуют, что такое хит, что такое ajax, как происходит идентификация посетителя (в частности как работают сессии и куки). Это основные моменты.

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

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

Очень важно изучить php.net
Не обязательно штудировать всё, но стоит как минимум взглянуть что там вообще есть.
Этот сайт - нечто вроде документации по STDLIB языка, в ходе практики ты к нему будешь возвращаться ещё тысячи раз.
Многие задачи, которые ты планируешь решить велосипедом, уже решены за тебя, и входят в язык - нужно просто знать про то, что язык умеет из коробки, а что нет.

Очень важно поработать с фреймворками и репозиторием composer: большинство из задач, которые встанут перед тобой, уже кем-то решены, и существует либо готовая библиотека, либо как минимум публичный интерфейс, который ты можешь реализовать, чтобы не натворить архитектурных ошибок.
Посмотри на symfony, почитай стандарты PSR.
Большинство задач решается декомпозицией алгоритма, и сборкой приложения из готовых библиотек или PSR-интерфейсов. Остаётся только это всё сконфигурировать, и дописать немного кода для склейки всего этого в единое приложение.

Т.к. php - это прокладка между html и БД, обязательно нужны основы html, SQL, и практика по развертыванию, проектированию, и управлению какой-либо СУБД.
Наиболее популярная и простая СУБД - MySQL, на ней и сконцентрируйся. Намного позже, когда будет опыт, обязательно попробуй postgres - это намного более совершенная СУБД, но она сложнее MySQL, и новичкам с неё начинать не стоит.
Особо углубляться в sql не стоит, т.к. в чистом виде с ним будешь работать мало, по большей части взаимодействие с БД сведётся к установке ORM-библиотеки, например doctrine2. Вот ORM стоит изучить плотнее, они предоставят тебе простой и приятный доступ к данным в БД, и обеспечат лёгкие миграции состояния БД.

Что касается курсов - они очень ценные, особенно для новичка. Быстро вводят в строй.
Но на практике все это выливается в год-два кодинга ради кодинга, что не особо эффективно.
Обязательно нужна практика, желательно боевая.
Советую либо посетить фриланс-биржу, и начать выполнять чьи-то хотелки, либо попробовать устроится, можно на удаленку, в какое-нибудь агентство, которое клепает сайты, и начать выполнять самые простые боевые задачи.
Такая практика прокачает тебя намного быстрее, и не позволит забыть то, что выучил. Но без курсов она будет однонаправленна: в реальной работе разработчики используют лишь малую часть из того, что может php, но знать нужно все - это сделает тебя профессионалом.
Поэтому нужно комбинировать практику с курсами.

Очень сильно поможет хороший редактор кода, например phpstorm - он будет подсвечивать твои ошибки, предоставит интерактивные подсказки по коду, и позволит быстро инспектировать код большого проекта, параллельно работая с ФС сервера, БД и docker-контейнерами. Серьезно ускоряет и упрощает работу.

Выбираю СУБД. От неё сильно зависят возможности: типы данных, индексы, промежуточные таблицы.
Разбиваю куски данных на сущности - тематические наборы данных.
Раскидываю сущности по таблицам - определяю что именно за поля должны быть в каждой сущности, для чего они нужны, какие типы данных будут оптимальны.
Связываю сущности отношениями. Выясняю, действительно ли необходимы каскадные операции отношениям, или нет, где лучше сохранить устаревшие данные, где можно подчистить, а где нужно сохранять актуальные связи по id.
Оцениваю получившуюся структуру, оптимизирую её: денормализую некоторые сущности, добавляю данные в связи, где не хватает, добавляю служебные поля, индексы.
Далее гоняю несколько итераций в голове на типичные сценарии использования: где-то всплывает неоптимальность структуры, или типа поля, где-то отсутствие необходимого поля, где-то можно сохранить дополнительную информацию, которая сейчас не нужна, но в некоторых сценариях значительно ускорит выборку данных из БД.

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