Как эффективно выучить технологии для backend'a?

sergeyiljin,

Программист не обязан настраивать Docker окружение и всё с этим связанное.

А код свой он запускать как будет?
Настраивать окружение нужно уметь. Бегать показывать новому разработчику как docker exec сделать - смешно же. Это учится за пол часа чтения документации. Хотя в целом тут больше речь про знание конкретно linux.

Глубоко лезть конечно джуну не нужно, но так в списке выше половина терминов в которых "Сеньор" то разбирается один из десяти, по очень оптимистичным прикидкам.

работа с Docker - это часть работы devops инженера.

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

Как эффективно выучить технологии для backend'a?

sergeyiljin,

Docker

Docker это Docker. Контейнеры и всё такое.
Devops это набор практик по взаимодействию команд разаботчиков и администраторов.
Docker в списке автора есть, devops нету и не нужно.

dmitriyuvin , присмотрите список того что нужно знать в похожем вопросе - Знания Junior php разработчика?

Как эффективно выучить технологии для backend'a?

sergeyiljin,

тогда как в списке есть и devops и front - end

devops в списке автора нет.

В чем отличие между статической/динамической типизацией и явной/неявной?

Тип может быть явно не указан но выводится компилятором из кода:
val number = 1;

Если вывести из кода не будет возможности (json["foo"]) - нужно будет явно его указывать

Что есть что в ссылке при MVC патерне?

для понимания MVC тыц

MVC это то что 50 лет назад придумали для десктопных приложений, и кстати, View там вполне себе зависит от модели :)

Где учить Node.js MVC?

1. MVC никоим боком не относится к структуре папок.
2. MVC создан для десктопных приложений.
3. Навигироваться по проекту где одна директория-свалка для всех моделей/контроллеров неудобно.
P.s. структура проекта - https://gist.github.com/fesor/76d39b19b18f7103a7c0...

Как правильно оптимизируется код в контроллерах Laravel?

antimind,

Модель - это описание структуры данных с геттерами, сеттерами и конструктором

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

Как правильно оптимизируется код в контроллерах Laravel?

antimind,
Я знаю про эту статью, и её автор просто не умеет готовить Рич модель и декомпозировать систему, и не пытался этого делать/научиться)
А аргументы про SOLID - чушь. SOLID не идеал и не самоцель.
Лучше уж смотреть на все виды Coupling/Cohesion в совокупности, они значительно более информативны, и SOLID тоже инструмент для улучшения вышеупомянутых принципов.

P.s.

https://m.habr.com/ru/post/346016/ вот например, почему это не антипаттерн.

И в целом, один лишь факт что какой-то неизвестный Вася написал на Хабре что "X" не антипаттерн ни о чем не говорит и не должно говорить.

Как правильно оптимизируется код в контроллерах Laravel?

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

Слой сервисов существует для application-specific business-rules, а критичная для бизнеса логика и работа с состоянием моделей должна быть в сущностях.
А помещение всей логики в сервисы называется "Анемичная Модель" и является антипаттерном(как и AR, но его можно выпилить или использовать как DAO/row data gateway).

Как вы читаете незнакомый код?

Хороший код должен легко читаться и выражать что он делает. Зависимость от глобального состояния - плохо. Изменения состояния лучше изолировать.

Что лучше EF Core или SQL запросы?

Лев Фёдоров, польза тяжелых ORM, таких как Entity Framework в основном на запись, они дают точку завершения бизнес транзакции которая закоммитит изменения в базу(Unit Of Work можно загуглить), отсутствие геттеров/аксессоров для полей сущности, т.е. нет риска нарушить инкапсуляцию и достать из сущности данные в своём коде, контроль за тем чтобы одна и та же сущность не выгрузилась из базы дважды в цикле обработки одного запроса.

А для чтения, для построения отчётов и т.п. что не изменяет данные можно использовать обычный SQL и мапить результаты на структуры/DTO, и не использовать ваши сущности с бизнес логикой. Это быстро, удобно, чётко определяет где выобрка данных и не затрагивает там сущности.

То есть оно работает быстрее чем EF Core?

Рассуждают о том что быстрее тогда, когда с этим возникают проблемы, и в 99% случаев в начале разработки приложения таких проблем нет, а в большинстве проектов в принципе не возникает.

Какую литературу посоветуете по тестированию?

Лучше сначала хорошо понять PHPUnit, а потом учить Codeception.

Codeception можно вообще не учить :)
Не нужен он особо. phpspec как удобную штуку для tdd можно.

Для юнитов Codeception не нужен т.к. является оберткой над phpunit, аргумент за модули не действует т.к. ничего критичного(чего нет/нелья сделать на phpunit) там нет, а phpunit так же хорошо расширяется.

Для функциональных то же самое - phpunit.

Для приёмочных - лучше какой-нибудь puppeteer и т.п. чем невнятную обертку над Selenium`ом

Нужен движок для создания закрытой таблицы?

Роман Лазарев, Могу посоветовать глянуть на PostgREST, firebase, horizon, Prisma etc. как замену бэкенда.
Если бэкенд это обёртка над строками в базе там может php не нужен вовсе.

Что здесь лучше использовать? Простое наследование, интерфейсы, или вообще абстрактный класс?

Да можно и просто массив DTO объявлений )

Как устроиться на работу программистом, если живешь в регионе?

Меньше людей слушайте :)
Особенно в вещах которые можно безболезнено попробовать.

Repository является DAO прослойкой?

Репозиторий - коллекция сущностей(Entity) без итератора.
Часто репозиторием называют просто гейтвей перед хранилищем.

"DAO прослойка" - нет такого термина. Есть DAO(Data Access Object).
Более грамотным подходом считается помещение бизнес логики в классы сущностей.

При менее грамотном проектировании часто бизнес логика растекается по сервисам, а сущности становятся анемичными(Anemic model), которые и является теми самыми DAO(поля + геттеры + сеттеры)

Как лучше сформировать класс Record?

Frozen Coder,

ну и будут поля пустые, кроме id

Сущность Категории не существует без, условно, поля "Название", и других обязательных для заполнения данных. Это первое.
Второе - qualityisspeed.blogspot.com/2014/09/beyond-solid-d...

p.s. Начните лучше юнит-тесты писать - очень быстро придёт познание, чем плохо лепить зависимости без причины.

Как лучше сформировать класс Record?

Frozen Coder, В данном случае хватит лишь того факта что идентификаторы сущностей стабильнее чем сами сущности.
У класса User может поменсяться конструктор, название, интерфейс, он может быть вынесен в отдельный микросервис, он может превратиться в несколько классо UserCredentials + UserPersonalInfo и т.п., но при всех этих действиях его ID не поменяется.

А потом внезапно понадобиться куда-нибудь передавать заполненый класс Record со всеми его вложенными товарищами и тогда привет рефакторинг или метод на сто-пятьсот аргументов или новый класс?

Что значит передавать Record со вложенными товарищами?
Record это модель/сущность или DTO?
Ваше "передавать со всеми вложенными товарищами" часом не нарушает закон Деметры?
Зависит ли логика, или планируется ли зависимость в бизнес логике между этими двумя классами?

Это вопросы на которые вы сами должны ответить. А под эгидой "А потом внезапно понадобиться куда-нибудь передавать заполненый класс" можно и ещё тысячу классов из системы в ваш Record запихать.

Как лучше сформировать класс Record?

Если второе, то конечно выбираете вариант 2. Какой вам толк от одного id-шника? А если вам куда-то передавать надо будет Record, то ещё и отдельно его User будете тащить?

У меня есть, условно продукт, у него есть какая-то логика, есть Категория. В продукте я храню только ссылку на категорию.
С чего вдруг мне нужно будет тащить Категорию туда где нужен продукт?

А толк от id-шки в том чтобы выразить связь, т.к. продукт должен относится к категории.

Как лучше сформировать класс Record?

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