Как реализовать это архитектурно правильно?
Anonymous Poll
18%
Добавить логику логирования и отправки события прямо в PaymentService::process()
27%
Создать LoggingPaymentGateway-декоратор поверх gateway
31%
Бросить PaymentProcessed из сервиса, listeners сделают остальное
29%
Декоратор для логирования + очередь из контроллера
Какую функцию нужно использовать, чтобы зарегистрировать собственный обработчик ошибок?
Anonymous Poll
5%
register_shutdown_function()
5%
error_log()
18%
register_handler_function()
4%
trigger_error()
72%
set_error_handler()
Какое значение по умолчанию принимает директива memory_limit в PHP?
Anonymous Poll
24%
64M
66%
128M
7%
256M
5%
512M
Какая аномалия возникает, когда транзакция выполняет один и тот же запрос дважды, и во второй раз получает дополнительные строки, которые были добавлены другой транзакцией?
Anonymous Poll
27%
Dirty Read
16%
Dirty Write
18%
Phantom Write
41%
Phantom Read
Что действительно ускоряет автозагрузку на проде?
Anonymous Poll
37%
composer install --no-dev
2%
composer diagnose
24%
opcache.revalidate_freq=0
47%
composer dump-autoload -o
DDD — границы агрегатов. За соблюдение кредитного лимита клиента при создании заказа кто отвечает?
Anonymous Poll
29%
Агрегатор Order
63%
Агрегат Customer (или доменный сервис вокруг него)
3%
Инфраструктурный валидатор в БД
6%
Сервис корзина
❓ Что такое Dependency Injection?
DI — паттерн, при котором зависимости класса передаются извне, а не создаются внутри.
// Плохо — жёсткая связанность:
class OrderService {
private $mailer;
public function __construct() {
$this->mailer = new SmtpMailer(); // зависимость зашита внутри
}
}
// Хорошо — DI:
class OrderService {
public function __construct(private MailerInterface $mailer) {}
}
Зачем:
✔️ Легко подменить реализацию (например, для тестов — MockMailer)
✔️ Классы не знают о конкретных реализациях (зависимость от абстракции)
✔️ Код легче тестировать, поддерживать, расширять
DI Container (Symfony, Laravel) автоматизирует создание объектов и внедрение зависимостей по всему приложению.
DI — паттерн, при котором зависимости класса передаются извне, а не создаются внутри.
// Плохо — жёсткая связанность:
class OrderService {
private $mailer;
public function __construct() {
$this->mailer = new SmtpMailer(); // зависимость зашита внутри
}
}
// Хорошо — DI:
class OrderService {
public function __construct(private MailerInterface $mailer) {}
}
Зачем:
✔️ Легко подменить реализацию (например, для тестов — MockMailer)
✔️ Классы не знают о конкретных реализациях (зависимость от абстракции)
✔️ Код легче тестировать, поддерживать, расширять
DI Container (Symfony, Laravel) автоматизирует создание объектов и внедрение зависимостей по всему приложению.
Какая из следующих функций используется для выбора одного или нескольких случайных значений из массива PHP?
Anonymous Poll
80%
array_rand()
17%
array_random()
3%
rand_array()
0%
random_array()
💬 Обратная связь
Как часто вы проходите собеседования?
🔥 — Сейчас активно ищу работу
👍🏼 — Раз в несколько месяцев
❤️ — Раз в полгода-год
😁 — Не прохожу, уже работаю/ещё учусь
Как часто вы проходите собеседования?
🔥 — Сейчас активно ищу работу
👍🏼 — Раз в несколько месяцев
❤️ — Раз в полгода-год
😁 — Не прохожу, уже работаю/ещё учусь
🔥4
❓ Чем отличается Optimistic Lock от Pessimistic Lock?
Pessimistic Lock — блокируем строку в БД на время транзакции. Никто другой не может её изменить до снятия блокировки.
SELECT * FROM orders WHERE id = 1 FOR UPDATE;
Применять когда: высокая вероятность конфликта, критичные финансовые операции, короткие транзакции.
Минус: снижает throughput, риск дедлоков при блокировке нескольких строк в разном порядке.
Optimistic Lock — блокировки нет. У записи есть поле version. При обновлении проверяем, что версия не изменилась:
UPDATE orders SET status = 'paid', version = 6
WHERE id = 1 AND version = 5;
Если affected_rows = 0 — кто-то успел раньше, делаем retry или возвращаем ошибку.
Применять когда: конфликты редки, операции долгие (нельзя держать блокировку), высокий параллелизм.
Минус: нужен retry-механизм, сложнее реализовать корректно.
Pessimistic Lock — блокируем строку в БД на время транзакции. Никто другой не может её изменить до снятия блокировки.
SELECT * FROM orders WHERE id = 1 FOR UPDATE;
Применять когда: высокая вероятность конфликта, критичные финансовые операции, короткие транзакции.
Минус: снижает throughput, риск дедлоков при блокировке нескольких строк в разном порядке.
Optimistic Lock — блокировки нет. У записи есть поле version. При обновлении проверяем, что версия не изменилась:
UPDATE orders SET status = 'paid', version = 6
WHERE id = 1 AND version = 5;
Если affected_rows = 0 — кто-то успел раньше, делаем retry или возвращаем ошибку.
Применять когда: конфликты редки, операции долгие (нельзя держать блокировку), высокий параллелизм.
Минус: нужен retry-механизм, сложнее реализовать корректно.
👍3
Случайно сделал коммит с ошибкой. Как быстро исправить не создавая новый?
Anonymous Poll
20%
git revert
18%
git revert HEAD
43%
git commit -- amend
23%
git commit -- revert
Что означает буква "D" в принципах SOLID?
Anonymous Poll
3%
Dependency Decoupling — разделение зависимостей на разные слои архитектуры
88%
Dependency Inversion — высоко- и низкоуровневые модули зависят от абстракций
3%
Dependency Determination — определение зависимостей для классов и методов
6%
Dependency Demarcation — разграничение зон ответственности для зависимостей
Какой признак характерен для архитектуры CQRS?
Anonymous Poll
5%
Разделение клиентской и серверной частей
91%
Разделение команд (изменений) и запросов (чтения)
2%
Использование одного сервиса для чтения и записи
3%
Отказ от реактивщины
Используется Doctrine transport. Какая семантика доставки сообщений?
Anonymous Poll
18%
At-most-once
20%
Exactly-once
62%
At-least-once с возможностью ретраев и “failed”-queue
2%
Гарантия завист от версии PHP
💬 Обратная связь
Текущий уровень сложности задачек?
🔥 — Слишком просто, хочу сложнее
👍🏼 — В самый раз
❤️ — Иногда сложновато
😁 — Часто не понимаю
Текущий уровень сложности задачек?
🔥 — Слишком просто, хочу сложнее
👍🏼 — В самый раз
❤️ — Иногда сложновато
😁 — Часто не понимаю
🔥4👍2
❓ Что такое событийно-ориентированная архитектура?
Event-driven architecture — это когда компоненты общаются через события, не зная друг о друге напрямую.
// Событие:
class UserRegistered {
public function __construct(public readonly User $user) {}
}
// Listener:
class SendWelcomeEmail {
public function handle(UserRegistered $event): void {
$this->mailer->send($event->user->email, 'Welcome!');
}
}
// Диспетчер:
$dispatcher->dispatch(new UserRegistered($user));
Зачем
✔️ Слабая связанность (UserService не знает о SendWelcomeEmail)
✔️ Легко добавить новый listener без изменения существующего кода (Open/Closed)
✔️ Можно делать асинхронные listeners (через очередь)
В Laravel: Event / Listener, EventServiceProvider.
В Symfony: EventDispatcher, декларация через атрибуты.
Подводный камень: сложно трейсить цепочку — одно событие вызывает другое.
Event-driven architecture — это когда компоненты общаются через события, не зная друг о друге напрямую.
// Событие:
class UserRegistered {
public function __construct(public readonly User $user) {}
}
// Listener:
class SendWelcomeEmail {
public function handle(UserRegistered $event): void {
$this->mailer->send($event->user->email, 'Welcome!');
}
}
// Диспетчер:
$dispatcher->dispatch(new UserRegistered($user));
Зачем
✔️ Слабая связанность (UserService не знает о SendWelcomeEmail)
✔️ Легко добавить новый listener без изменения существующего кода (Open/Closed)
✔️ Можно делать асинхронные listeners (через очередь)
В Laravel: Event / Listener, EventServiceProvider.
В Symfony: EventDispatcher, декларация через атрибуты.
Подводный камень: сложно трейсить цепочку — одно событие вызывает другое.