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

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

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

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

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

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

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

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

Традиционным способом проектирования приложения под iOS является использование шаблона MVC (модель-представление-контроллер). Использование MVC для архитектуры приложения, может натолкнуть Вас на мысль, что каждый класс представляет собой или модель, или представление, или контроллер. Поскольку значительная часть логики приложения не входит в модель или представление, она обычно оказывается в контроллере. Это приводит к проблеме, известной как Massive View Controllers, где контроллеры в конечном итоге делают слишком много. Если вся логика встроена в контроллер представления, это приводит к тестированию логики через UI, в свою очередь это является неправильным способом проектированиям логики. Также проще совмещать бизнес-логику и UI код в том же методе. Когда Вам будет нужно добавить новые функциональные возможности или исправить ошибку, то будет трудно определить, где внести изменение и при этом быть уверенным, что не будет непредсказуемых последствий в другом месте.

Введение в VIPER - 1
Читать полностью »

Излишняя сложность как причина дополнительных скрытых издержек - 1

Мы часто говорим кому-то фразы наподобие «Мне нужно всего лишь несколько часов, чтобы это сделать/реализовать/внедрить». Но спустя какое-то время после окончания работ вдруг осознаём, что нам приходится регулярно исправлять баги и ошибки, объяснять устройство и алгоритм работы другим инженерам и разработчикам, или помогать отвечать на вопросы клиентов. И получается, что объём времени, затраченного на поддержку вашего детища, многократно превышает те несколько часов, что ушли на его создание.

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

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

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

В публикации рассматриваются следующие темы:

  • Наследование VS компоненты
  • Сложные иерархии классов юнитов, предметов и прочего
  • Машины состояний, деревья поведений
  • Абстракции игровых объектов
  • Упрощение доступа к другим компонентам в объекте, сцене
  • Сложные составные игровые объекты
  • Характеристики объектов в игре
  • Модификаторы (баффы/дебаффы)
  • Сериализация данных

Читать полностью »

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Архитектурный дизайн мобильных приложений: часть 2 - 1


Привет!

Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI.

Добро пожаловать!Читать полностью »

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.
Читать полностью »

Архитектура мобильного клиент-серверного приложения - 1
К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».
Читать полностью »

Признак плохого дизайна N1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Архитектурный дизайн мобильных приложений - 1
Ведущий iOS-разработчик Redmadrobot Егор beptep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

Читать полностью »

В первой части статьи был высказан тезис о том, что виной низкого быстродействия создаваемого нами CRM-приложения была SPA-архитектура. Для кого-то такое предположение могло показаться, мягко говоря, неожиданным и даже оскорбительным, учитывая стремительно растущую популярность данного подхода в разработке WEB-приложений, да и мы, как и многие современные разработчики, тоже вполне успешно осваиваем новые технологии, однако на примере данного проекта нам удалось эмпирическим путём нащупать ту грань, где стоит дважды подумать, прежде чем делать ставку на новое, и как раз об этих деталях и пойдёт речь во второй части статьи.
Читать полностью »


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