При поиске работы приходится просматривать много вакансий. Часто в заявках на вакансии упоминаются термины, сокращения или аббревиатуры подчас не знакомые, не встречавшиеся вам ранее. Особенно, когда у вас была практическая разработка на начальных позициях и некоторые термины, аббревиатуры вам могут быть не знакомы. К тому-же довольно часто HR добавляет в требования множество аббревиатур и технологий просто «про запас».

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

Ваше резюме или предыдущий опыт может не полностью соответствовать тем технологиям и инструментам, которые заявлены в вакансии. Это еще не повод сильно расстраиваться и не отсылать своё резюме. Имея некоторое представление и определения, вам будет легче подготовиться, иметь представление с чем придется столкнуться в ваших интервью, технических собеседованиях по вакансии и процессе работы. Имея общее представление, расширив свой кругозор будет легче пройти собеседование, общаться в команде где используются стандарты и общие термины. Часто имея 50% навыков использования заявленных технологий, вы сможете претендовать на вакансию.

Разберем некоторые термины и определения. Они, в свое время были даны в литературе часто цитируемыми, известными и уважаемыми авторами публикаций, инженерами, разработчиками.

Акроним

Принцип программирования DRY — don’t repeat yourself / не повторяйте себя

Что означает этот принцип? Имеется в виду повторение некоторых сущностей в коде.
Если вы написали один раз код, какое-то действие - то его не нужно повторять. Данный принцип позволяет сократить количество кода и сделать его более читаемым. Повторное использование может быть реализовано при помощи включением ссылок на фрагменты кода или при помощи объектно ориентированного программирования. К примеру, вы нашли в коде действие, которое повторяется и фрагмент кода дублируется. Пересмотр архитектуры и реорганизация кода поможет в этом вопросе. Принцип относится к повторному использованию кода без его переписывания заново в нескольких местах программы.

YAGNI («You aren't gonna need it») — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.

Согласно адептам принципа YAGNI, желание писать код, который не нужен прямо сейчас, но может понадобиться в будущем, приводит к следующим нежелательным последствиям:

Тратится время, которое было бы затрачено на добавление, тестирование и улучшение необходимой функциональности.

Новые функции должны быть отлажены, документированы и сопровождаться.

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

Пока новые функции действительно не нужны, трудно полностью предугадать, что они должны делать, и протестировать их. Если новые функции тщательно не протестированы, они могут неправильно работать, когда впоследствии понадобятся. Это приводит к тому, что программное обеспечение становится более сложным (подчас чрезмерно сложным).

Если вся функциональность не документирована, она может так и остаться неизвестной пользователям, но может создать различные риски для безопасности пользовательской системы. Добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту «снежного кома».

SOLID (сокр. от англ. Single responsibility, open–closed, Liskov substitution, interface segregation и dependency inversion) в программировании — мнемонический акроним, введённый Майклом Фэзерсом (Michael Feathers) для первых пяти принципов, названных Робертом Мартином в начале 2000-х, которые означали 5 основных принципов объектно-ориентированного программирования и проектирования.

SOLID — это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании. В переводе на русский: принципы единственной ответственности, открытости / закрытости, подстановки Барбары Лисков, разделения интерфейса и инверсии зависимостей)

S (single responsibility principle) - принцип единой ответственности

Что такое принцип единой ответственности?

Обычно, сам принцип единой ответственности описывается так:

«Модуль должен иметь одну и только одну причину для изменения».

Принцип единой ответственности вносит ясность в написание кода и помогает избегать дублирования. Он также помогает писать код более понятно, разделяя его на минимально необходимый набор составляющих. Если перефразировать и сказать проще, то принцип единой ответственности звучал бы так:
«Каждый модуль кода отвечает за что-то одно, необходимое для выполнения».

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

О (open-closed principle) - Принцип открытости/закрытости. Сокращенно - OC

«программные сущности … должны быть открыты для расширения, но закрыты для модификации».

То-есть используя объектно-ориентированное программирование вы можете использовать наследование для расширения набора функционала. Следование принципу OCP означает, что программное обеспечение изменяется не через изменение существующего кода, а через добавление нового кода. Новая функциональность вводится не через изменение существующего кода, а с использованием наследования реализации или с использованием абстрактных интерфейсов и полиморфизма. Согласно определению Мейера реализация интерфейса может быть унаследована и переиспользована, а интерфейс может измениться в новой реализации.

L (Liskov substitution principle) – Принцип подстановки Лисков
«функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом».

Имеет сложное математическое определение, которое можно заменить на: Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. Поведение объектов старших классов должно иметь возможность замены поведением объектов подклассов, и приложение при такой замене должно работать так, как ожидается.

I (interface segregation principle) - Принцип разделения интерфейса
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения».

D (dependency inversion principle) - Принцип инверсии зависимостей
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное».
Принцип инверсии зависимостей (dependency inversion principle / DIP) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

Применение этого принципа поощряет программиста меньше использовать "жесткие" связи.
Пример использования принципа инверсии зависимости - использование шаблона проектирования абстрактная фабрика. Абстракция не зависит от реализации, а то что строит объект не зависит от того из чего происходит построение. Например из объектов бизнес-логики.

SoC (Separation of concerns) – Разделение ответственности.
В информатике разделение ответственности представляет собой процесс разделения компьютерной программы на функциональные блоки, как можно меньше перекрывающие функции друг друга. В более общем случае, разделение ответственности — это упрощение единого процесса решения задачи путём разделения на взаимодействующие процессы по решению подзадач.

TDD - Разработка через тестирование

Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода с целью приведения к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность.

https://dic.academic.ru/dic.nsf/ruwiki/6161

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

REST

REST (от англ. Representational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Другими словами, REST — это набор ограничений, требований и принципов, как программисту организовать написание кода сетевого приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать. Автор идеи и термина Рой Филдинг 2000г.

Representational State Transfer — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.

В общем смысле, REST — это концепция, парадигма, а не протокол. Реализация данной парадигмы находит отражения в реализациях, которые её придерживаются.

REST определяет, как может осуществляться доступ к различным ресурсам на серверах.

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

Основные принципы REST:

Клиент-серверная архитектура - разделение архитектуры на независимые части : клиентская и серверная

Stateless - наменьшее сохранение состояния, или запросы вовсе без сохранения состояния

Кэширование

Единообразие интерфейса

Layered system - слоеная система или система состоящая из слоев

Code on demand - код по требованию

Назначение концепции - проектирование и реализация REST api.

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

RESTful сервис — это реализация способа получить доступ к ресурсам, которые находятся в определённой среде, построенный с соблюдением требований REST.

Некоторые фреймворки для создания RESTful сервисов.

Dropwizard - популярная платформа для настройки современных веб-приложений с Jetty, Jackson, Jersey и Metrics.
Dropwizard при поддержке Jetbrains

Elide - платформа для JSON- или GraphQL-API на основе модели данных JPA.

Jersey - JAX-RS эталонная реализация от Eclipse.
Eclipse Jersey — это среда REST, реализация JAX-RS (JSR-370) и многое другое.

Microserver - Удобная, расширяемая система плагинов микросервисов для Spring & Spring Boot. С более чем 30 подключаемыми модулями.

Поддерживает стили как микромонолита, так и чистых микросервисов.

Rapidoid - Простая, безопасная и чрезвычайно быстрая структура, состоящая из встроенного HTTP-сервера, компонентов графического интерфейса и внедрения зависимостей.

rest.li - Платформа для создания надежных, масштабируемых архитектур RESTful с использованием безопасных привязок и асинхронного неблокирующего ввода-вывода со сквозным рабочим процессом разработки, который продвигает чистые методы, унифицированный дизайн интерфейса и согласованное моделирование данных.

RESTEasy

RestExpress — тонкая оболочка на HTTP-стеке JBoss Netty, обеспечивающая масштабирование и производительность.

Restlet Framework - Новаторская платформа с мощными возможностями маршрутизации и фильтрации, а также унифицированным клиентским и серверным API.

Spark - микрофреймворк для создания веб-приложений на Kotlin и Java 8 с минимальными усилиями.

Crnk - Внедрение спецификации JSON API для создания ориентированных на ресурсы конечных точек REST с сортировкой, фильтрацией, разбиением по страницам, связыванием, графами объектов, безопасностью типов, массовыми обновлениями, интеграциями и многим другим.

springdoc-openapi - Автоматизирует создание документации API с помощью проектов Spring Boot

Swagger - Не зависящий от языка интерфейс для REST API.

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. SOAP - это стандартизированный протокол, который отправляет сообщения с использованием других протоколов, таких как HTTP и SMTP. Спецификации SOAP являются официальными веб-стандартами, которые поддерживаются и разрабатываются Консорциумом World Wide Web (W3C). Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня модели OSI: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены и реализованы отдельно. Чаще всего SOAP используется поверх HTTP.

Специфика SOAP — это спецификации формата обмена данными.

JSON

JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка программирования JavaScript, определенного в стандарте ECMA-262 3rd Edition - December 1999. JSON - текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других. Эти свойства делают JSON наиболее универсальным, можно сказать, наиболее подходящим во многих случаях средством для обмена данными.

JSON основан на двух структурах данных: Коллекция пар ключ/значение.

В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив. Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность.
https://json.org/json-ru.html

JPA

JPA - это технология, обеспечивающая объектно-реляционное отображение простых JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами. Чтобы использовать JPA нам требуется некоторая реализацию, при помощи которой мы будем пользоваться технологией. Реализации JPA ещё называют JPA Provider. Одной из самых заметных реализаций JPA является Hibernate.

JPA-это спецификация, описывающая отношение и управление реляционными данными с использованием объектной модели.

Hibernate — библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного отображения (ORM), самая популярная реализация спецификации JPA. Распространяется свободно на условиях GNU Lesser General Public License.

Данная библиотека позволяет сократить объёмы низкоуровневого программирования при работе с реляционными базами данных, а также может использоваться как в процессе проектирования системы классов и таблиц «с нуля», так и для работы с уже существующей базой.

Библиотека не только решает задачу связи классов Java с таблицами базы данных (и типов данных Java с типами данных SQL), но и также предоставляет средства для автоматической генерации и обновления набора таблиц, построения запросов и обработки полученных данных. Такая библиотека может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL- и JDBC-кода. Hibernate автоматизирует генерацию SQL-запросов, что освобождает разработчика от ручной обработки результирующего набора данных и преобразования объектов, максимально облегчая перенос (портирование) приложения на большинство баз данных SQL.

Hibernate обеспечивает прозрачную поддержку сохранности данных (persistence) для «POJO» (то есть для стандартных Java-объектов). Существует строгое требование для сохраняемого класса — наличие конструктора по умолчанию (без параметров). Для корректного поведения в некоторых приложениях требуется также уделить внимание методам equals() и hashCode().

Кроме Hibernate, существует еще несколько реализаций JPA: Eclipselink, OpenJPA, Criteria API.

Eclipselink

EclipseLink - разработка Eclipse Foundation, обеспечивает реализацию JPA с открытым исходным кодом. Кроме того, EclipseLink поддерживает ряд других стандартов персистентности, таких как архитектура Java для привязки XML (JAXB).

OpenJPA известен как Kodo. Коdо - это реализация JDO и JPA

JPA Criteria API

Criteria API - это актуальный API, используемый для определения запросов для сущностей. Запросы JPQL определяются как строки, аналогично SQL. Запросы критериев JPA, с другой стороны, определяются созданием экземпляров объектов Java, которые представляют элементы запроса. Основное преимущество использования API Criteria заключается в обнаружении ошибки во время компиляции, а не во время выполнения. С другой стороны, для многих разработчиков запросы JPQL на основе строк, которые очень похожи на запросы SQL, проще в использовании и понимании.

Следующий запроса «SELECT c FROM Country» с реализованного при помощи JPA criteria API:

CriteriaBuilder cb = em.getCriteriaBuilder();

CriteriaQuery q = cb.createQuery(Country.class);
Root c = q.from(Country.class);
q.select(c);

Apache Kafka

Apache Kafka — распределённый программный брокер сообщений, проект с открытым исходным кодом, разрабатываемый в рамках фонда Apache. Написан на языках программирования Java и Scala.

Распределённые системы, как правило, состоят из множества сервисов: одни генерируют события (метрики, логи, события мониторинга, служебные события и т. д.), другие предназначены для получения и обработки этих данных.

Kafka — гибрид распределённой базы данных и брокера сообщений с возможностью горизонтального масштабирования. Kafka собирает у приложений данные, хранит их в своем распределённом хранилище, группируя по темам, и отдаёт компонентам приложения по подписке. При этом сообщения хранятся на различных узлах-брокерах, что обеспечивает высокую доступность и отказоустойчивость.

Где применяется Kafka?

Основное назначение — это централизованный сбор, обработка, безопасное хранение и передача большого количества сообщений от отделённых друг от друга сервисов. Эта распределённая, горизонтально масштабируемая платформа обычно применяется там, где очень много больших неструктурированных данных.

Какие распределенные программные брокеры сообщений существуют кроме Kafka?
Ответ: RabbitMQ, AWS SNS/SQS

RabbitMQ — это еще один брокер сообщений с открытым кодом. Первоначальным разработчиком была компания Rabbit Technologies, но в результате ряда приобретений продукт перешел в собственность VMware.

Amazon Kinesis - AWS SNS/SQS - Amazon Web Services (AWS)

Amazon Web Services — коммерческое публичное облако, поддерживаемое и развиваемое компанией Amazon с 2006 года. Предоставляет подписчикам услуги как по инфраструктурной модели, так и платформенного уровня. Среди услуг класса связующего программного обеспечения — брокер сообщений Amazon Kinesis (близок по возможностям Apache Kafka),
служба очередей SQS и служба уведомлений SNS.

XML

XML (англ. eXtensible Markup Language — расширяемый язык разметки; произносится [экс-эм-э́л]). World Wide Web Consortium, W3C - язык разметки, выполняющий свод общих синтаксических правил.

XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки.
XML является упрощённым подмножеством языка SGML.

XMI — стандарт на основе XML, предназначенный для обмена моделями разных форматов.

WSDL: WSDL рассказывает о функциях, которые вы можете реализовать или предоставить клиенту. Например: добавить, удалить, вычесть и так далее.

WSDL: Когда мы идем в ресторан, мы видим пункты меню, это WSDL.

JDBC (англ. Java DataBase Connectivity — соединение с базами данных на Java) — платформенно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql, входящего в состав Java SE.

JDBC основан на концепции так называемых драйверов, позволяющих получать соединение с базой данных по специально описанному URL. Драйверы могут загружаться динамически (во время работы программы). Загрузившись, драйвер сам регистрирует себя и вызывается автоматически, когда программа требует URL, содержащий протокол, за который драйвер отвечает.

ORM — Object-Relational Mapping или в переводе на русский язык: объектно-реляционное отображение. Это технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования. Если упростить, то ORM это технология связи Java объектов и записей в БД.

Литература и материалы:

https://ru.wikipedia.org/
https://dic.academic.ru/
https://ru.wikipedia.org/
https://dic.academic.ru/dic.nsf/ruwiki/6161
https://github.com/dropwizard/dropwizard
https://elide.io/
https://eclipse-ee4j.github.io/jersey/
https://github.com/aol/micro-server
https://www.rapidoid.org/
https://resteasy.github.io/
https://json.org/json-ru.html
http://sparkjava.com/

Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика. — Вильямс, 2004, ISBN 5-8459-0558-3, ISBN 0-13-597444-5.

Мартин Р., Мартин М. Принципы, паттерны и методики гибкой разработки на языке C#.
— Символ-Плюс, 2011, ISBN 5-93286-197-5, ISBN 978-5-93286-197-4, ISBN 0-13-185725-8, ISBN 978-0-13-185725-4.

Мартин, Р. Чистая архитектура. Искусство разработки программного обеспечения. Clean architecture. A Craftsman’s Guide to Software Structure and Design. — Питер, 2018. — ISBN 978-5-4461-0772-8.

Со всем набором технологий, который часто указывают в вакансиях, вы возможно не работали. Те или иные знания могут пригодиться в работе, а могут быть не востребованы и применяться довольно редко. Дополнительные знания, и расширение кругозора всегда
полезно. Более глубокие знания вы приобретаете уже в процессе работы, непосредственно обращаясь к спецификациям, наборам требований и правил их реализации, работая с документацией. Вероятно вы даже использовали принципы описанные выше в своих проектах, но не знали их определений и некоторых спецификаций. Приведение чего-то к общим стандартам помогает в коммуникациях и лучшем понимании коллег в индустрии.

Благодарю за прочтение. Хорошего дня.