Skip to content

Latest commit

 

History

History
236 lines (179 loc) · 32.7 KB

development.md

File metadata and controls

236 lines (179 loc) · 32.7 KB
Raw

Оглавление

Принципы, паттерны, практики и подходы разработки ПО

SOLID.

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

  • S - Принцип единственной ответственности (The Single Responsibility Principle). Каждый класс должен иметь одну и только одну причину для изменений.
  • O - Принцип открытости/закрытости (The Open Closed Principle). Сущности должны быть открыты для расширения, но закрыты для модификации.
  • L - Принцип подстановки Барбары Лисков (The Liskov Substitution Principle). Объекты должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Наследующий класс должен дополнять, а не изменять базовый.
  • I - Принцип разделения интерфейса (The Interface Segregation Principle). Много специальных интерфейсов лучше, чем один универсальный.
  • D - Принцип инверсии зависимостей (The Dependency Inversion Principle). Зависеть нужно от абстракций, а не от реализаций.

Первоисточником, сформулировавшим данные принципы стал дядюшка "Свет наш чистый код" Боб Мартин, а акроним придумал один из его читателей. Хотите погрузиться глубже? Тогда читайте часть 3 его книги "Чистая архитектура". Книжка годная, читается легко, не пожалеете. Однако пропускайте всё через свой опыт и оценивайте критически, мало ли что :)

Сама по себе тема богатая и холиворная, ибо многие начинают трактовать эти принципы по-своему. На этой почве может случиться недопонимание с собеседующим, будьте аккуратны и конструктивны. Достаточно поискать статьи на Хабре по SOLID или каким-нибудь принципам в отдельности и заглянуть в комментарии. Кому-то SOLID вообще не по душе.

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

к содержанию

Паттерны. Какие знаете? Каких видов бывают? Расскажите парочку (желательно разных видов)? Какие применяли на практике или встречались где-то? Чем декоратор отличается от прокси, а абстрактная фабрика от обычной?

Обычно советуют и в вакансиях пишут про книжку GoF. Но, на мой взгляд, сейчас есть вариант даже лучше - refactoring.guru. Там и сравнение, и на родной мове (русский, украинский, английский, китайский), и примеры на вашем любимом ЯП, прекрасные иллюстрации и диаграммы. Там также можно купить книжку по паттернам. Автору большой-большой респект.

к содержанию

Что такое coupling и cohesion? Что из них (или оба) должно быть сильным (высоким) и/или слабым (низким)?

Coupling (Зацепление) - степень зависимости между программными компонентами. Должна быть низкой.

Cohesion (Связность) - степень сфокусированности методов класса. Должна быть высокой.

Подробнее почитать и посмотреть картинки можно тут на английском или тут на русском.

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

Также coupling и cohesion часто упоминаются или ведут к обсуждению GRASP. Об этом можно почитать на Хабре: раз и два.

к содержанию

Что такое куб масштабирования?

Куб масштабирования (scale cube, из книги The Art of Scalability) является наглядным изображением трёх ортогональных способов увеличения производительности приложения: sharding, mirrorring и microservices.

  • Sharding (data partioning) - разбиение и размещение однотипных данных по разным узлам.
  • Mirroring (horizontal duplication) - дублирование или клонирование данных для уменьшения времени отклика.
  • Microservices - архитекутрный подход, при котором функциональность системы разбивается на отдельные сервисы по бизнес-задачам.

Наглядно: Куб масштабирования

Почитать подробнее:

к содержанию

Расскажите о CAP-теореме. Как MongoDB (например) удовлетворяет CAP-теореме?

Теорема CAP - эвристическая теорема, утверждающая, что любая распределённая система может удовлетворять не более двум из трёх свойств:

  • Consistency (согласованность) - во всех вычислительных узлах в один момент времени данные не противоречат друг другу - каждое чтение вернёт самую последнюю запись. Подразумевает под собой линеаризуемость - если произошла какая-либо операция, то её результат доступен сразу после того, как был получен ответ о её выполнении.
  • Availability (доступность) - любой запрос получает успешный ответ без гарантии, что ответы со всех узлов системы совпадают.
  • Partition tolerance (устойчивость к разделению) - система продолжает функционировать, несмотря на потерю (или задержку) произвольного числа сообщений между узлами из-за сетевых проблем (асинхронная сеть).

MongoDB, по мнению большинства (например), это - CP, но вот есть статья... Держим в уме, что теорема эвристическая и носит упрощательный характер. Также вызывает много споров.

Про большинство БД можно найти ответы в статьях по дополнительным ссылкам ниже.

Подробности:

к содержанию

Чем композиция отличается от агрегации?

Композиция (composition) - отношение "является частью" (HAS-A Relationship), при котором целое явно контролирует время жизни своей составной части.

Агрегация (aggregation) - отношение "является частью" (HAS-A Relationship), при котором целое хоть и содержит свою составную часть, время их жизни не связано.

Подробнее:

к содержанию

Какие бывают тестовые объекты (заглушки)? Чем стаб отличается от мока?

Тестовый объект (Test Double) - объекты, которые необходимы в тестах для подмены внешних зависимостей тестируемого кода Типы тестовых объектов:

  • Dummy - объекты, которые передаются в методы, но не используются. Например: заполнение списка параметров, часто это просто null
  • Fake - заглушка, являющаяся рабочей имплементацией, но с урезанной функциональностью и неприменима в production-окружении. Например: in-memory БД (fake database)
  • Stub - заглушка с жестко заданными ответами на вызовы со стороны тестируемого объекта (system under test - SUT) во время теста
  • Spy - это разновидность Stub, которая записывает информацию о произошедшем с ней, какие вызовы её методов были выполнены и сколько раз, как изменилось состояние и т.п.
  • Mock - заглушка с ожиданиями определённого набора вызовов, которые будут на ней выполнены в ходе теста

Из данного набора заглушек только Mock используется для верификации поведения, остальные - для верификации состояния тестируемого объекта .

Подробнее:

к содержанию

Дайте определение полиморфизму

В общем виде определение полиморфизма приводит Бенджамин Пирс в своей книге Типы в языках программирования:

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

Полиморфизм бывает следующих видов:

  1. Универсальный полиморфизм. Он подразделяется на:
    • Параметрический полиморфизм - описывает вычисления в общем виде, абстрагируясь от конкретных типов, которые будут использованы. Параметрически полиморфные функции также называются обобщенными (Generic).
    • Полиморфизм включений (inclusive) - описывает вычисления не только для конкретного типа, но для и всех его возможных подтипов. Отражает принцип подстановки Барбары Лисков.
  2. Специальный полиморфизм (или ad-hoc) - диспетчеризация (перенаправление) к одной или нескольким функциям для конкретного типа аргумента. Из него выделяют подтипы:
    • Перегрузка (overloading) позволяет объявлять функции с одним и тем же именем, но с разными типами аргументов и их количеством (арностью).
    • Неявное приведение типов - преобразование одного типа в другой по определённым правилам, описанным в стандарте языка, и выполняемое компилятором.

Безотносительно к Java полиморфизм хорошо разобран в статье Полиморфизм простыми словами. В других источниках:

к содержанию

Что такое REST? Какое API является RESTful? Чем REST отличается от SOAP?

REST – это архитектурный стиль, который можно применить для реализации взаимодействия web-сервисов. Вот несколько признаков REST, которые хотят услышать большинство интервьюеров:

  • Концентрация на ресурсах
  • Ресурс имеет уникальный URI
  • Формат передачи - обычно JSON, но можно XML
  • Транспортный протокол - HTTP. Строго говоря - это необязательно, но по факту и в большинстве случаев так. Следующие пункты тоже.
  • Использование различных методов HTTP в соответствии с их семантикой и предназначением. GET: получить информацию о ресурсе; POST: создать новый ресурс; PUT: обновить существующий ресурс; DELETE: удалить ресурс. Иногда спорят об обновлении - PUT vs PATCH vs POST.
  • Использование кодов ответа HTTP в соответствии с их семантикой и предназначением. Хорошая картинка по определению HTTP-кода ответа.
  • HATEOAS обычно не используют и не спрашивают, но это тоже относится к REST, о чём можно упомянуть

Чаще всего, на моей практике, спрашивают какой HTTP-метод для чего должен использоваться или как назвать URI, чтобы API было RESTful. Однако никакой спецификации или стандарта под это нет. И вообще, строго говоря, изначально REST - это архитектурный стиль, непривязанный ни к каким протоколам. Тема раскрыта в этой статье или в этой на Хабре - комментарии сочные.

Вот принципы REST-архитектуры по Филдингу:

  • Модель клиент-сервер (Client–server)
  • Отсутствие состояния (Stateless) - у клиента и сервера нет необходимости отслеживать состояние друг друга
  • Кэширование (Cacheable) - ответы сервера должны помечаться как кэшируемы и некэшируемые
  • Единообразие интерфейса (Uniform interface) - идентификация ресурсов, манипуляция ресурсами через представление, "самодостаточные" сообщения, HATEOAS
  • Слои (Layered system) - в системе может быть больше одного слоя, но компоненты системы видит и взаимодействует только с соседним слоем. Кроме клиента и сервера может быть ещё прокси и шлюз
  • Код по требованию (необязательное ограничение) (Code on demand (optional)) - отправка сервером исполняемого кода клиенту

SOAP - стандартизованный протокол обмена данными. Основные характеристики SOAP:

  • Формат сообщений - XML (SOAP-XML - Envelope, Header, Body, Fault)
  • SOAP-сервис должен иметь описание на языке WSDL(тоже XML)
  • SOAP поддерживает множество протоколов - (TCP, UDP, HTTP, SMTP, FTP и т.д.)
  • При использовании HTTP, поддерживаются методы GET и POST

Тема горячая, интересная всем web-разработчикам, поэтому на Хабре имеется уйма статей на любой вкус.

Теоритическо-практические:

Холиварно-дискусионные:

И на всякий случай:

А кроме Хабра:

к содержанию