Руслан Мусагитов

Описание архитектуры приложения

К разработке приложения можно подойти по-разному. Можно сразу начать писать код, делать верстку, а структуру и архитектуру приложения придумывать по ходу работы. Этот подход не продуктивный, он позволяет быстро начать, но не дает сохранить нормальный темп разработки.

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

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

Руслан Мусагитов

Управляющий партнер, iOS-разработчик

График скорости разработки

красный - без предпроектного планирования и разработки архитектуры проекта,
синий - с подготовкой архитектуры на предпроектном этапе

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

Давайте отойдем немного в сторону и подумаем, что же такое "архитектура" и что под ней скрывается. На эту тему стоит почитать сборник материалов от Мартина Фаулера. В нем даются несколько определений:

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

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

Сразу встает вопрос, как лучше это делать? Описательно или схематично? До какого уровня абстракции опускаться.

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

Существует несколько основных схем:

диаграмма прецедентов;
диаграмма классов;
диаграмма объектов;
диаграмма последовательностей;
диаграмма взаимодействия;
диаграмма состояний;
диаграмма активности;
диаграмма развертывания.

Рассмотрев все варианты, мы остановились на двух из них:

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

Диаграмма активности позволяет понять алгоритм работы продукта.

А диаграмма классов помогает разработать детальное решение до этапа программирования. И что наиболее важно, это помогает в явной постановке задач в дальнейшем.

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

Заходим на сайт Slack, указываем название и workspace. Далее добавляем Incoming Webhooks, выбираем канал и получаем URL, который мы добавляем в конфигурацию fastlane.

Сначала мы разрабатываем диаграмму активностей.

Пример диаграммы активности

Далее разбиваем приложение на модули. И готовим диаграмму классов.

Пример диаграммы классов

Диаграмма классов может использоваться:

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

Какие плюсы мы получили:

алгоритм работы продукта
более предсказуемый процесс разработки продукта
улучшение в качестве продукта
дополнительная техническая документация проекта
добавить нового члена в команду стало легче

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

Спасибо за внимание!