Как стать кросс-функциональным разработчиком-полиглотом

Как стать разработчиком, готовым к производству?

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

Это может заставить разработчиков сойти с ума.

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

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

Каковы требования к разработке приложений и их развертыванию на производстве?

Каких концепций следует придерживаться?

Юнит-тесты (кодирование)

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

2. Доменно-ориентированное проектирование (архитектура)

Чтобы говорить на одном языке с бизнесменами, нам необходимо разработать язык. Также для создания расширяемого, тестируемого, понятного приложения нам нужны некоторые абстракции и правила. В DDD мы можем предоставить чистое решение для сложных бизнес-доменов.

Я рекомендую красную книгу Вона Вернона: «Implementing Domain Driven Design».

3. Практика чистого кода (кодирование)

Мы должны следовать практике чистого кода, чтобы писать чистый, понятный, читабельный код.

4. Интеграционные и автоматические тесты (Тестирование)

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

1. Тесты на основе потребительских контрактов (тестирование)

Как мы можем быть уверены, что наши потребители не пострадают, если мы изменим конечную точку в нашем rest api?

Что если мы случайно изменим имя поля, которое используется потребителем?

На помощь приходят CDC-тесты. Мы и наши потребители пишем CDC-тесты и запускаем эти тесты в конвейере, чтобы предотвратить развертывание любых ломающих изменений.

Посмотрите на проект pact: https://docs.pact.io.

6. Гексагональная архитектура & адаптеры портов & CQRS (архитектура)

Нам необходимо обеспечить расширяемость и хорошую абстракцию нашего проекта. Абстрагирование уровней приложения/домена/инфраструктуры/api нашего проекта гораздо важнее, чем то, какой фреймворк мы используем. Здесь на первый план выходит гексагональная архитектура и порты-адаптеры.

Также мы можем захотеть масштабировать части приложения для чтения и записи отдельно. Или мы хотим разделить/абстрагировать эту ответственность в коде. Вот что говорит нам CQRS.

Посмотрите для получения дополнительной информации: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

7. Контейнеры и Docker (Devops)

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

Также есть некоторые другие инструменты для создания контейнеров, такие как buildah & podman.

8. CI/CD Pipelines (Devops)

Нам необходимо автоматизировать этапы тестирования / сборки / развертывания наших приложений.

С помощью инструментов CI/CD (Jenkins, Gitlab и т.д.) мы можем добиться этого.

9. Kubernetes (Devops)

K8S является стандартом де-факто для оркестровки контейнеров. Мы можем запускать/масштабировать/обнаруживать наши сервисы с помощью kubernetes.

Как разработчик мы должны быть знакомы с ним, чтобы понимать, в какой среде работает наше приложение.

10. Логирование (мониторинг)

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

Существует множество различных технологий протоколирования, таких как ELK stack.

Например, мы пытаемся следовать стратегии 12-факторного приложения. Наши приложения не знают о базовых технологиях протоколирования. Все наши микросервисы выводят свои журналы в stdout, а мы собираем их с помощью fluentbit/fluentd в kubernetes. Таким образом мы абстрагируем технологию логирования от приложений. Мы можем менять хранилище журналов, не затрагивая приложения.

11. Мониторинг

Программное обеспечение — это живая система. За ними нужно постоянно наблюдать. Чтобы определить любую аномалию (например, высокое использование ресурсов, общее количество запросов, время отклика) и оптимизировать их, мы должны следить за ними.

Существуют такие инструменты, как NewRelic, Jaeger, Elastic APM, которые помогают нам отслеживать приложения.

12. IaC (Devops)

Инфраструктура как код помогает нам автоматизировать любой процесс предоставления машин и конфигурации. Такие инструменты, как terraform, ansible, chef, puppet, vagrant, docker, помогают нам достичь IaC. Мы можем написать нашу среду в terraform/ansible как код и автоматически запускать их в конвейере для загрузки среды.

13. Брокеры сообщений (архитектура)

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

Есть несколько популярных инструментов, таких как RabbitMQ, ActiveMQ, Kafka, Aws Sqs и т.д.

14. Базы данных и кэш (хранение данных)

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

Как хранить и извлекать данные? Есть ли более быстрый способ доступа к данным? Нужно ли постоянно выполнять вызовы db? Мы должны быть в состоянии ответить на эти вопросы.

Когда мы используем базу данных (sql/nosql), нам нужно посмотреть, как индексировать данные, как применить правильную схему, как получить их и т.д.

Нам также может понадобиться снять накладные расходы с базы данных и использовать кэш-решение. Мы можем кэшировать часто используемые данные.

На этом я заканчиваю и желаю вам приятного чтения.

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

Если у вас есть предложения/дополнения к списку, пишите их в комментариях.

You can follow me on:

Tweets by mstrYoda_

https://github.com/mstrYoda