Как ответить
Лучшие практики в разработке — это не магический список, а набор принципов, которые помогают не выстрелить себе в ногу. Для начала — SOLID. Но не ради галочки, а как инструмент: например, Open/Closed я использую, когда надо добавить новое поведение без изменения существующего кода — через стратегию или декоратор. Dependency Injection позволяет тестировать изоляцию модулей.
Второе — тестирование. Пирамида тестов работает: юнит-тесты (70% покрытия), интеграционные (20%), e2e (10%). Я предпочитаю TDD для сложных бизнес-логик — писать тест до кода, чтобы сразу понять, как API должен выглядеть без лишней абстракции. Code review обязателен: каждой строчки. В команде мы цепляем линтеры, форматтеры, статический анализ (SonarQube) — это снимает 80% споров.
Третье — архитектура. Для middle-разработчика важно понимать trade-off между монолитом и микросервисами. Я не пихаю микросервисы везде: если домен слабо связан и команда большая — да, иначе монолит с чёткими модулями проще поддерживать. На практике работаю с гексагональной архитектурой: бизнес-логика не знает про фреймворк или БД. Это даёт возможность менять инфраструктуру без переписывания кода.
Четвертое — CI/CD и автоматизация. Каждый коммит проходит сборку, тесты, линтеры. Выкатка — через gitflow с ветками feature/staging/release. Это убирает «магический деплой в пятницу вечером».
Пятое — работа с legacy. Если не писать технический долг сразу, он накапливается. Моя практика: правило «бойскаута» — оставлять код лучше, чем застал. Рефакторинг делаю маленькими шагами с тестами-сеткой. Никогда не переписываю всё с нуля — это риск похоронить проект.
В итоге, лучшие практики — это не догма, а контекст. На собеседовании я всегда спрашиваю: «Какая у вас частота релизов?» — от этого зависит, какие практики реально внедрить.