Рубрика «архитектура приложений» - 12

В стандарте IEEE 1471 термин «архитектура» определен как базовая организация системы, описывающая связи между компонентами этой системы и внешней средой, а также определяющая принципы её проектирования и развития. В одной из предыдущих статей мы уже рассматривали несколько видов архитектур программного обеспечения. Сегодня мы обратим свой взор на набирающие популярность бессерверные архитектуры, поскольку это достаточно «горячая» тема в сфере software-решений: уже появляется специальная литература, фреймворки, организуются конференции.

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

«Архитектуры приложений»: немного о бессерверных архитектурах - 1

/ фото John Voo CC
Читать полностью »

image

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.
Читать полностью »

Пилим монолит - 1

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

Переход от монолита к микросервисам - 1

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

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

Построение Android приложений шаг за шагом, часть третья - 1

В первой и второй частях статьи мы создали приложение для работы с Github, внедрили Dagger 2 и покрыли код unit тестами. В заключительной части мы напишем интеграционные и функциональные тесты, рассмотрим технику TDD и напишем с ее применением новую функциональность, а также подскажем, что читать дальше.
Читать полностью »

Построение Android приложений шаг за шагом, часть вторая - 1

В первой части статьи мы разработали приложение для работы с github, состоящее из двух экранов, разделенное по слоям с применением паттерна MVP. Мы использовали RxJava для упрощения взаимодействия с сервером и две модели данных для разных слоев. Во второй части мы внедрим Dagger 2, напишем unit тесты, посмотрим на MockWebServer, JaCoCo и Robolectric.
Читать полностью »

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

Немного об архитектурах программного обеспечения - 1

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.Читать полностью »

Построение Android приложений шаг за шагом, часть первая - 1

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2, пишем тесты и размышляем о TDD в реалиях Android разработки. А на десерт — кеширование в Rx приложениях.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js