Привет, Хабр!

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

Идея создания

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

Когда я только начинал заниматься разработкой, и до понятия «картины» мне было очень далеко, гораздо важнее было хотя бы найти холст, кисточки и вообще понимать, что с ними делать. При этом нельзя инвестировать свое время во что-то одно, крайне важно подходить к этому вопросу комплексно. Успех программных систем кроется не только в том, что они могут быть построены грамотно с технической точки зрения, гораздо важнее иметь комплексное видение процессов, чтобы обеспечивать развитие. И примерно с такой идеей в моей голове, судьба познакомила меня с Олегом Сивченко (@OlegSivchenko).

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

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

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

Оглавление

Вот список глав и их краткое описание:

1.Что такое бэкенд разработка

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

2. Сбор требований к системе

В этой главе рассказывается о бизнес аналитике, важности грамотного сбора бизнес требований, а также взаимодействие между командами разработки и бизнесом.

3. Семантика синхронных взаимодействий. REST

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

4. Масштабирование приложений.

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

5. Асинхронные взаимодействия.

В тех ситуациях, где семантика синхронных взаимодействий не позволяет достаточно эффективно решить поставленную задачу, на помощь могут прийти асинхронные подходы. В рамках данной главы читатель узнает про организацию очередей (AWS SQS), применение брокеров сообщений (Apache Kafka), а также использование иных средств, благодаря которым можно расширить количество сценариев взаимодействия на проекте. 

6. Кеширование.

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

7. Операционные данные приложения

Нередко ядром системы являются ее данные, поэтому их организация играет большую роль. Поэтому отдельная глава посвящена тому, как именно могут обрабатываться операционные данные в рамках бэкенд-проектов. Помимо подходов с применением реляционных баз данных (PostgresSQL, MySQL), также рассматриваются нереляционные решения (MongoDB, Redis, БД временных рядов), а также проводится их сравнение в тех или иных ситуациях, для того, чтобы подобрать наиболее эффективное решение, решающее поставленную бизнес задачу.

8. Сложная логика приложений.

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

9. Безопасность

Как показывает практика, за безопасность приложения нужно платить, а за ее отсутствие - расплачиваться. Поэтому при построении своего решения, пристальное внимание нужно уделять тем местам, которые могут быть эксплуатированы не по назначению. Для этого в рамках данной главы разбираются основные векторы атак, которым подвержены приложения, а также способы защиты от них. Например, разбирается применение JWT токенов, организация OAuth2 и OIDC, а также защита от SQL инъекций, XSS и CSRF атак. Отдельное внимание обеспечено организации аутентификации, прав и ролей доступа.

10. Этап эксплуатации и подготовка к ней

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

11. Проверка изменений

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

12. Доставка изменений

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

13. Мониторинг работы системы

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

Целевая аудитория

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

О чем эта книга?

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

Почему важно помнить про бизнес цель

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

Важность технологий

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

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

Архитектура и сложная логика приложений

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

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

Тестирование

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

Доставка изменений

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

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

Мониторинг

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

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

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

Вместо заключения

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

Книгу можно приобрести в интернет-магазине издательства БХВ по ссылке.