Разумные разработчики не пишут код, или Перестаньте изобретать вещи заново -6


AliExpress RU&CIS

Кое-что застряло у меня в голове очень давно, когда я был молодым младшим разработчиком. Я работал, пытаясь ускорить доступ к данным в веб-приложении. Первая итерация кода вызывала базу данных каждый раз, когда пользователь просматривал данные. В поисках оптимизации я решил кешировать исходные возвращённые данные, чтобы не возвращаться к базе. Это было разумно.

Итак, опустив голову, я целыми днями придумывал нечто, что было бы лучшим кеширующим кодом Java из всех, что я видел! Я придумал сложные алгоритмы вызова, хранения, пейджинга и удаления данных для одного юзкейса. После 5 дней и ночей тяжёлого труда я гордо встретил своего ведущего разработчика и познакомил его с моим кодом; я одурачил его великолепием алгоритмов.

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


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

Сначала он сказал мне, что мой код – излишняя инженерия, а затем, что я написал нечто, решающее проблему, для которой уже есть шаблоны и инструменты.

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

Один из самых ранних моих уроков в программной инженерии – решая проблему, не садиться сразу же за код.

Этот урок напомнил мне о недавнем разговоре с молодым разработчиком, представившим проблему с использованием кода в RedHat OpenShift (предупреждаю: я работаю в Red Hat). Во всех деталях он объяснил, что написал множество микросервисов, чтобы сидеть перед множеством API, которые читают данные из различных источников и манипулируют ими перед отправкой в различные конечные точки. Он был очень горд своим множеством микросервисов, которые разработал, чтобы решить проблему. Там были агрегаторы, трансляторы и другие паттерны.

Я выслушал и вздохнул

Я сказал ему, что решение выглядит действительно сложным и что он немного переусердствовал с инженерией. В вежливой форме я сказал ему, что люди решили все эти и другие проблемы много раз. Указал на Apache Camel и сказал, что не нужно разрабатывать микросервисы ради микросервисов.

Не стройте микросервисы ради микросервисов!

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

Apache Camel – один из великолепных примеров того, что не нужно заново изобретать велосипед

Я большой поклонник Apache Camel как в смысле интегратора, так и в смысле большого успеха сообщества Open Source. История утверждает, что Camel появился из разговора Грегори Хофа и Джеймса Стрейкена. Грегор написал библию интеграции Enterprise Integration Patterns, книгу с проектами общих задач интеграции в виде набора шаблонов… так что вам не нужно изобретать одни и те же архитектурные шаблоны.

Джеймс, разработчик Open Source и основатель языка Groovy, и Грегор беседовали на конференции, и Джеймс подумал, что было бы неплохо создать переиспользуемые реализации этих шаблонов на Java… так что вам не нужно продолжать писать один и тот же код, когда необходимо что-то сделать! Apache Camel родился из этой беседы как набор реализующих шаблоны интеграции библиотек.

Вернёмся к недавнему разговору с младшим разработчиком

Итак, мы взглянули на Red Hat Integration, которая представляет собой Apache Camel и кучу других вещей для развёртывания и запуска сервисов интеграции. Я сказал младшему разработчику, что он не только может делать всё, что ему нужно, но и подогнать всё в его архитектуру микросервисов и, глядя на некоторые новые разработки, такие как Camel K, он также может сервировать свои микросервисы… бессерверно… [have his microservices served…err, serverless! – заставить работать свои микросервисы с помощью технологии serverless, бессерверно].

Бессерверная интеграция микросервисов

Camel К – самая захватывающая вещь в интеграции на данный момент. Некоторые из самых больших проблем, с которыми сталкиваются специалисты по интеграции, всегда были связаны с тем, как с помощью архитектур интеграционных решений добиться доступности в больших масштабах. Такие инструменты, как Camel K и OpenShift, учитывают все аспекты развёртывания, запуска и масштабирования в этой задаче.

Apache Camel предоставляет реализацию шаблонов и сотни адаптеров. Глубокие знания нужны, только чтобы выяснить, какие коннекторы и шаблоны использовать, и, что важно, нужно знать о том, как компоненты развёртываются в масштабируемой и доступной архитектуре таким образом, чтобы поддерживать требования.

Такие проекты, как Camel K, – это новая порода нативных инструментов kubernetes, которые стремятся задействовать мощь Kubernetes, чтобы воспользоваться огромными масштабами и возможностями доступности этой платформы. Некоторые сложные вещи в определении и проектировании масштаба и доступности уже реализованы при помощи Kubernetes, так что мне не нужно заново изобретать масштабирование и доступность!

Что такое Apache Camel?

Ок, я расскажу быстро, если вы не сталкивались с Apache Camel, то это – инструмент потрясающей красоты, который по-настоящему упрощает интеграцию и соединение сотен разных вещей:

Бросим быстрый взгляд на Apache Camel.

  1. Он предоставляет более 50 паттернов интеграции.

  2. Имеет более 350 коннекторов.

  3. Он прекрасен.

Вот что лежит в основе каждой интеграции. Данные или вызов приходит из источника (FROM), затем идут в обработчик (PROCESSOR), в котором как-то обрабатываются, и затем направляются к (TO) месту назначения. 

Компоненты FROM и TO или адаптеры соединяют технологии от нативных сервисов AWS, файлов CSV и SAP до реактивных потоков и коннекторов Kafka… их больше трёхсот пятидесяти.

Эта история о том, что компоненты Camel – блестящий способ показать мощь сообществ и проектов с открытым исходным кодом. Много лет я был большим поклонником Camel и видел, как с каждым выпуском количество компонентов растёт.

Вот мощь Open Source

Вот что обычно происходит: разработчик использует Camel, и плагина, в котором он нуждается, в Camel ещё нет. Итак, разработчик пишет компонент, удовлетворяющий его требованиям. Будучи порядочным гражданином страны Open Source, разработчик радует сообщество Camel – вносит свой компонент в исходный код Camel, и этот компонент включается в следующий выпуск Camel. Теперь, когда компонент нужен вам, не нужно создавать его заново… это потрясающе!

Множество источников могут помочь вам с Camel. Один из лучших – книга Клауса Ибсона и Джонатана Энсти, Camel in Action – библия Camel. Джеймс Стрейкен часто говорил, что он изобрёл Camel, но Клаус заставил инструмент работать. Кроме того, взгляните на блестящие статьи Тома Донахью о Camel.

А как же Camel К?

Я быстро покажу что-нибудь удивительное (ладно, это будет удивительно для такого старого интеграционного писаки, как я). Я выполню довольно простую задачу интеграции всего в несколько строк кода.

Я собираюсь создать Telegram-бота, который будет отправлять комплименты в канал Telegram. У Telegram есть API загрузки, которым я могу воспользоваться, чтобы отправлять сообщения в каналы, которыми могу пользоваться.

А вот сервис комплиментов Grant Codes: complimentr.com, который возвращает приятные слова, чтобы поднять настроение.

Ух ты, потрясающие цветовые схемы Гранта!
Ух ты, потрясающие цветовые схемы Гранта!

Сейчас я хочу интегрировать эти два сервиса, чтобы отправлять комплименты моим друзьям в Telegram. Итак, я собираюсь погрузиться в код? Нет, чёрт возьми!

Взгляните на коннекторы Apache Camel – среди 350 компонентов, с помощью которых я могу соединить разные вещи, я нашёл Camel Telegram: кто-то, кто хотел пообщаться с Telegram, уже написал что-то для этого, так что я писать ничего не должен!

Стандартные компоненты Camel помогут с вызовом простого HTTP в моём сервисе комплиментов. Я легкомысленно говорю “стандартные”, потому что на самом деле есть HTTP-компонент, который работает со всем, что я мог бы написать, но мне он не нужен!

Итак, я собираюсь воспользоваться компонентом Camel Telegram, чтобы получить сообщение от бота, затем вызываю внешний сервис, чтобы получить комплимент, и отправляю его боту Telegram. Вещь не самая захватывающая, но немного забавная. Вот чего я хочу от бота: чтобы я отправил имя и в ответ получил комплимент.

У меня есть кластер kubernetes, поэтому я сделаю бота с помощью Camel K и воспользуюсь Red Hat OpenShift и Camel K Operator, чтобы всё настроить.

Вот, что нужно сделать:

1. Загрузить CLI Camel K.

2. Установить Camel K Operator.

3. Запустить мой код.

Загрузите Camel K CLI

Об этом есть много статей и документации, поэтому я не буду вдаваться в кучу подробностей, но Camel K CLI (или kamel) – это, по сути, CLI взаимодействия с вашей платформой Kubernetes (или, точнее, с пользовательскими ресурсами Camel K на платформе) для развёртывания интеграций (есть также плагины для VSCode).

CLI позволяет установить операторы Camel K, запустить интеграции в режиме интерактивной разработки (с обновлениями запущенного кода интеграции на лету) и т. д.

Установка Camel K Operator

В Camel K есть ряд операторов Kubernetes, чтобы создавать, развёртывать и запускать интеграции. Весь смысл операторов Kubernetes заключается в том, чтобы абстрагировать сложности всего того, что работает на платформе, и Camel K справляется великолепно! Так что просто возьмите и установите оператор из CLI, используя командную строку:

Или, если вы работаете в Openshift, откройте вкладку Operators, чтобы установить операторы.

Запускам мой код

После установки я могу отправить код интеграции на свою работающую платформу OpenShift из IDE или из командной строки.

Давайте посмотрим на код. Помните, что я работаю с компонентом Telegram. Мне нужно просто взять токен авторизации Telegram и передать его в компонент, который будет читать сообщения от бота.

from("telegram:bots?authorizationToken=[YOUR TOKEN]”)

Если я добавлю простое логирование, чтобы увидеть, как работает маршрут:

from("telegram:bots?authorizationToken=[YOUR TOKEN]")
.to("log:bots")

То на выходе всего пара строк кода. Сохранив их в файле hello.groovy, я получу скрипт groovy, им можно воспользоваться в качестве интеграции CamelK, которая подключится к моему telegram-боту и будет логировать всё, что я напечатаю!

Запуск hello.groovy

Здесь начинается нечто удивительное. Я хочу, чтобы мой двухстрочный скрипт groovy развёртывался и запускался как масштабируемый интеграционный компонент. Вот что такое Camel К! Из командной строки я запускаю простую команду:

С помощью команды run я превратил свой двухстрочный скрипт groovy в контейнер, развёрнутый и работающий как маршрут Apache Camel на моём кластере OpenShift.

Зачем флаг --dev

Добавив флаг --dev, я оказался в странном мире, где я могу изменить свой файл hello.groovy, и изменения отразятся в кластере OpenShift! Опция --dev сильно упрощает разработку.

Бот целиком

Вы уже видели, как работает Camel K, и вот оставшаяся часть моего скрипта с уклонением от кодирования:

from("telegram:bots?authorizationToken=[YOUR TOKEN]")
.setHeader("USER", body())
.to("https://complimentr.com/api?asGET=true")
.transform().jsonpath("\$.compliment")
.setBody(simple("\${body} \${in.header.USER}"))
.to("telegram:bots?authorizationToken=[YOUR TOKEN]")
  • Чтобы получить сообщения из канала Telegram, я использую компонент Camel Telegram.

  • Спрячьте имя в заголовок, передаваемый в теле сообщения Telegram.

  • Вызовите API комплиментов.

  • Обратитесь к пользователю по имени.

  • Верните комплимент в канал Telegram.

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

Есть несколько действительно блестящих шаблонов интеграции Camel, таких как агрегаторы, брокеры, динамическая маршрутизация, и даже более удивительные вещи в Camel K, например бессерверность или масштабирование до нуля [отключение, когда платформа не используется] по запросу, они помогут вам не писать код!

Разумные разработчики, которые не занимаются программированием, – давно уже не новость. Причины, по которым мы создаём фреймворки и инструменты, заключаются в желании абстрагироваться от рутины и работать продуктивнее. Иногда нужно понять, какие фреймворки и инструменты помогут вам не писать код. Надеюсь, я показал вам один из таких фреймворков!

Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодом HABR, который даст еще +10% скидки на обучение.

Другие профессии и курсы




Комментарии (3):

  1. fkthat
    /#22779094 / +5

    Зачем статью про какую-то интеграционную платформу (я и не стану сомневаться, что она хороша, хоть я её и в глаза не видел) называть "Как разумно писать код"? Назвали бы уж тогда, в стиле некоторых сайтов, как-нибудь, типа: "Шокирующие новости о жене Лужкова!"

  2. AYamangulov
    /#22779466

    Статья правильная и адекватная. Сам я только начал работать с этой платформой, но уже успел оценить ее достоинства. С названием «Как разумно писать код» полностью согласен — мы пишем код не для того, чтобы продемонстрировать, насколько круто мы умеем это делать, а по заказу бизнеса, для бизнеса и по его ТЗ, чтобы удовлетворять его нужды. Названием, как я понимаю, автор просто зашифровал давно известную парадигму «создание достаточно качественного работоспособного кода за адекватное для заказчика время».
    Спорить об этом — все равно, что спорить о том, что можно же писать код Spring без Spring Boot — можно, но, как правило, не нужно. Автору плюс в карму. Оценку ставить не могу, так как я здесь недавно и еще не имею полноправного аккаунта.

    • SpyzeR
      /#22779528 / +1

      Ну да, настолько правильная и нужная статья, что вы даже не поленились зарегистрироваться чтобы написать этот комментарий!


      По существу: такие решения, к сожалению, очень непредсказуемы. Сегодня есть и ты в этом мастер, а завтра уже другое решение в приоритете. Такая же история как и с фремворками получается. Хочешь не хочешь, а языки нужно знать, а чтобы знать нужно на них писать