О чем и для кого статья

Привет всем! Данная статья адресована начинающим свой путь в системном анализе и призвана помочь ответить максимально просто на один из самых частых вопросов системному аналитику на собеседовании. Мне данный вопрос задали на 3х из 5ти технических интервью, а это значит, что в теме надо разобраться. Поехали!

Вопрос: на сайте есть форма с полем поиска чего-либо по названию и кнопка, при нажатии на которую должен быть выведен результат поиска. Проблема в том, что пользователь не помнит название. Как реализовать поиск?

Первый шаг к ответу - а что, собственно, хотят услышать?

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

Что надо понимать

При ответе на вопрос выше надо хотя бы примерно понимать "бизнес" процесс реализации поиска по введенной подстроке. Почему я говорю о бизнес-процессе, а не о технологии? Да, потому что создание сайтов (а вместе с ними внутренних порталов и CRM cистем) стандартизируется, а вместе с этим стандартизируется работа системных аналитиков. И когда им ставится задача выше они должны ее декомпозировать на вполне определенные блоки. А это уже бизнес-процесс самого системного аналитика, который спустя годы будет также автоматизирован.

Итого, чтобы получить таблицу с данными, найденными по подстроке, введенной пользователем, системного аналитику надо будет поставить задачи на вот такой набор работ как минимум:

Где искать подстроку в URL - кратко

Введенные параметры с указанием полей поиска идут сразу после вопросительного знака «?» и используется при передаче данных на сервер в случае GET запроса. Поля и введенные в них данные разделяются символом амперсанда («&» (а по-русски "и")). Никаких кавычек добавлять к введенной подстроке при формировании URL не надо.

Ниже на картинке на сайте с доменом discript.ru по безопасному протоколу HTTPS на странице blog запросили данные по введенных в полях name и topuc строкам. В первом ввели "struktura-uml", во втором - "seo".

Если бы в поле name ввели "struktura uml", то параметры запроса передали бы вместо пробела " " - знак "+".

А если бы в поле name ввели "struktura+uml", то параметры запроса передали бы вместо "+" - "%2B".

Как сформировать JSON или XML - кратко

JSON или XML запроса состоит из 3х блоков:

1. Метод + путь URL

   1. Метод. Ниже приведены наиболее часто используемые.

      1. GET Запрашивает получение данных с сервера.

      2. POST Создает новый ресурс или обновляет существующий на сервере.

      3. PUT Полностью заменяет указанный ресурс новыми данными.

      4. DELETE Удаляет указанный ресурс.

      5. PATCH Частично обновляет указанный ресурс.

   2. URL: /api/data?[параметр=значение] с указанием параметров запроса в случае открытой передачи данных или /api/data без параметров запроса, если данные передаются в теле запроса это путь к ресурсу на сервере.

2. Заголовки:
   Host: Указывает доменное имя сервера.
   Content-Type: тип содержимого, например, application/json, при необходимости.
   Content-Length: Указывает длину тела запроса в байтах, при необходимости.

3. Тело запроса с описанием объекта или массива в формате "ключ-значение"

Разница между JSON и ХML будет только в формате тела запроса. Ниже примеры.

Методы обмена данными между серверами - кратко

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

• FTP/SFTP: Протокол передачи файлов, используемый для загрузки и скачивания файлов с удаленного сервера.

• HTTP/HTTPS: Стандартный протокол для веб-коммуникаций, часто используется для передачи данных через API и RESTful сервисы.

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

• AMQP/MQTT/Kafka/RabbitMQ: Брокеры сообщений, обеспечивающие асинхронную передачу данных между приложениями. Используются для организации очередей сообщений и событийно ориентированной архитектуры.

• SOAP/XML-RPC: Старые стандарты обмена структурированными сообщениями, основанные на XML, используются реже, уступив место современным REST API.

• gRPC: Современный протокол RPC (Remote Procedure Call), использующий бинарный формат Protobuf для быстрого обмена большими объемами данных.

Варианты обработки запроса - кратко

После того как будет получено сообщение с данными, введенными пользователем, сервером - необходимо обработать это сообщение и извлечь данные из БД по подстроке. Ниже перечень возможных решений.

• Вариант 1: Простое SQL-подобное решение с использованием оператора LIKE
  Один из простейших способов реализовать поиск по подстроке – использование операторов сравнения строковых значений в базах данных, например LIKE.
  SELECT * FROM products WHERE name LIKE '%${userInput}%';

• Вариант 2: Использование полнотекстового поиска (Full-text search), встроенныго в большинство современных СУБД. Это позволит учитывать морфологию, стемминги и синонимы, обеспечивая более точный поиск.
  --Пример использования full-text index в MySQL:
CREATE FULLTEXT INDEX idx_name ON products(name); SELECT * FROM products WHERE MATCH(name) AGAINST('${userInput}' IN NATURAL LANGUAGE MODE);

• Вариант 3: Решение на стороне приложения с использованием регулярных выражений
  путем обработки запроса на уровне бизнес-логики. Например, на Python можно создать функцию для фильтрации объектов на основе регулярного выражения:
  def find_by_substring(data, substring): pattern = re.compile(substring, re.IGNORECASE) return list(filter(lambda x: bool(pattern.search(x['name'])), data))

• Вариант 4: Реализация автоподсказок (autocomplete) путем создания отдельного API-интерфейса, возвращающего список предложений по мере набора текста пользователем.

Послесловие

Казалось бы вопрос простой, а сколько за ним всего стоит. И еще пару лет назад было достаточно рассказать интервьюеру о том, что будет поставлено несколько задач: на создание полей и кнопок на UI и на обработку запроса BACK'ом. В большинстве своем программисты сами бы определили типы запросов, коды новых поле, способы извлечения данных из БД и т.д. Вопрос способа реализации передачи данных вообще бы не стоял при доработке для существующего функционала.

Почему интервью стали столь глубоки - мне не известно, но факт остается фактом. Собеседования аналитиков теперь проходят очень жестко по заранее подготовленным задачам без "бла-бла-бла "и "кем вы видите себя через 5 лет".