Ответ
Да, Middle-разработчик должен понимать и применять базовые принципы проектирования.
Ожидаемый уровень знаний включает:
- Принципы: SOLID, DRY, KISS.
- Паттерны проектирования: Умение применять Factory, Strategy, Observer, Adapter в реальных задачах.
- Архитектурные решения: Способность обосновать выбор между монолитом и микросервисами для конкретного случая.
- Качество кода: Опыт рефакторинга, работа с зависимостями.
Пример проверки понимания инверсии зависимостей (Dependency Injection):
// Плохо: Жесткая привязка к конкретной реализации
class PaymentService {
private PayPalGateway gateway = new PayPalGateway();
}
// Хорошо: Зависимость от абстракции, внедряется извне
class PaymentService {
private final PaymentGateway gateway; // Интерфейс
public PaymentService(PaymentGateway gateway) {
this.gateway = gateway;
}
}Не стоит углубляться в сложные Enterprise-шаблоны — это уровень Senior+.
Ответ 18+ 🔞
А, ну вот, опять про эти ваши принципы проектирования! Слушай, а то, блядь, некоторые думают, что Middle-разработчик — это тот, кто просто хуячит код, как в анекдоте про "работает — не трогай". Ан нет, ёпта! Тут уже мозги включать надо, а не просто втупую строчить.
Так вот, от тебя ждут, чтобы ты не просто знал, а понимал, как этим пользоваться, а не как мантры повторять:
- Принципы эти ваши: SOLID, DRY, KISS. Не просто аббревиатуры вызубрить, а чувствовать, когда твой код начинает вонять и нарушает их. Это как, блядь, чуйка должна быть!
- Паттерны проектирования: Factory, Strategy, Observer, Adapter. Не для того, чтобы в резюме красивенько перечислить, а чтобы в реальной задаче, когда тебе подсовывают очередную хуйню, ты мог сказать: "А давайте-ка тут Strategy применим, и будет нам счастье, а не этот пиздец".
- Архитектурные решения: Монолит или микросервисы? Вот это, блядь, вопрос! Middle уже должен не просто пальцем ткнуть, а аргументировать, почему для этого конкретного случая один пиздец, а другой — просто пипец. "Потому что модно" — это не аргумент, это диагноз.
- Качество кода: Рефакторинг, зависимости... Это не когда "и так сойдёт", а когда смотришь на свой код трёхмесячной давности и охуеваешь: "Бля, и кто это писал? А, это я... Ну всё, надо переделывать".
Вот, смотри, простой пример, чтобы не быть голословным. Проверка на вшивость — понимаешь ли ты инверсию зависимостей или нет:
// Плохо, как у дебила: Жёстко прибил гвоздями к стене. Захотел поменять платёжку — всё, пиздец, переписывай сервис.
class PaymentService {
private PayPalGateway gateway = new PayPalGateway(); // Конкретика, блядь! Намертво!
}
// Хорошо, как у умного чувака: Работаешь с абстракцией. Что подсунут — с тем и работаешь. Гибко, ёба!
class PaymentService {
private final PaymentGateway gateway; // Интерфейс, абстракция, мать его!
public PaymentService(PaymentGateway gateway) { // Подсунули снаружи — вот и молодец.
this.gateway = gateway;
}
}И главное, не надо тут выёбываться и лезть в какие-нибудь Enterprise-шаблоны с тремя буквами. Это уже уровень Senior+, там свои тараканы. Middle должен уверенно ходить по базе, а не парить в космосе, блядь, с непонятными паттернами на десять километров. Сначала научись эту простоту грамотно применять, а там видно будет!