В данной статье я коснусь вопроса порога входа в проект с устоявшейся архитектурой и дам несколько вариантов ответа на очень часто возникающий вопрос: почему так сложно? Такой вопрос частенько возникает у новичков, которые приходят на проект. Или же бывают ситуации, когда проект уходит на поддержку и развитие в новые руки, и у нового разработчика также появляется этот вопрос. И редко кто из них пытается разобраться в реальных причинах, почему здесь так, а не иначе. Это может привести к печальным последствиям для бизнеса, например, новый разработчик может настоять на том, чтобы переписать все приложение с нуля.
Чтобы минимизировать такие риски, следует вместо вопроса почему так сложно? задаться такими вопросами: Сначала разработчик должен вникнуть в систему процесса разработки, он должен задать такой вопрос: Часто в заказной разработке на вход приходит проект с однозначными требованиями и фиксированным набором функционала. Насколько проработанными они могут быть — это уже тема другой статьи. И процесс разработки в таких проектах чаще всего выстроен по водопадной системе, потому как предполагает непосредственную обратную связь от пользователей продукта — после разработки всего функционала продукта, тогда как при итерационной модели обратную связь можно получить уже после первой итерации. У архитектора для таких проектов обычно уже припасена устоявшаяся архитектура, которая отвечает определенным требованиям к этому процессу. Какие же требования к такому процессу разработки закладывает архитектор? 1) Pipeline процесса разработки должен быть максимально сложным для разработчика. И отбраковывание кода, поступающего в репозиторий проекта, должно по максимуму происходить автоматически и, по возможности, без участия самого архитектора. Т.е. в процессе должен быть настроен определенный pipeline. Код, который прошел весь этот pipeline — считается удовлетворяющим требованиям. Это очень важно, т.к. хорошему архитектору необходимо избавить его разработчиков от головной боли и ответственности за не рабочую сборку после попадания кода в репозиторий. Если такого pipeline нет — ваши разработчики будут страдать от постоянного стресса. Если код попал в репозиторий и pipeline его принял, и этот код сломал сборку или повредил уже работающий функционал — это уже проблема самого pipeline. Поэтому в таком pipeline необходимо использовать: Все эти пункты в совокупности и приводят к появлению у разработчика вопроса: почему так сложно? Для примера попробуйте написать тесты для вот такого кода: Вам придется запускать такие тесты на реальном android устройстве, либо на эмуляторе. И это сразу приведет к существенной просадке во втором требовании к процессу разработки: 2) Автоматизированные элементы Pipeline'а процесса разработки должны выполняться как можно с большей скоростью Если вашим разработчикам приходится ждать выполнения тестов очень долго — это проблема вашего pipeline и если архитектура не позволяет ускорить этот процесс — это проблема вашей архитектуры Давайте перепишем пример: Мы видим, что сложность кода увеличилась, но с точки зрения процесса разработки — мы сделали архитектуру более гибкой, теперь нам не обязательно запускать тесты бизнес логики для блока map в эмуляторе или на устройстве, достаточно запустить их в быстрых тестах. Это уменьшит количество интеграционных тестов, которые нужно запускать в медленном окружении. Уменьшить количество дорогих интеграционных тестов может правильно выбранный архитектором паттерн проектирования. Не поленитесь и разберитесь с популярными на сегодня паттернами: MVP, MVVM, MVI. Давайте еще немного затронем тему навигации в приложении. Мы тоже хотим уметь тестировать ее, и тестировать в быстрых тестах. Опять получаем "усложнение" архитектуры, потому что нам придется прятать систему навигации в приложении за абстракцией. А еще мы хотим уметь связывать компоненты нашей системы с помощью DI, выстраивать графы зависимостей и проверять их корректность на этапе компиляции проекта, а не в рантайме. Тут на сцене появляется Dagger 2 и его монструозные компоненты и сабкомпоненты с модулями, которые уже в конец запутывают бедного новичка. И таких неочевидных моментов "усложнения" архитектуры для новичков накапливается очень много. Естественно, без понимания процессов разработки и требований к этим процессам, у них появляется тот самый вопрос — почему так сложно? Чтобы оценить успешность выстроенного процесса разработки и, опосредованно, архитектуру проекта, необходимо проанализировать его результат. Как правило, результатом является продукт(приложение если мы говорим про мобильную разработку). И метрики успешности продукта у всех разные: у заказчика — одни метрики, у разработчика — свои метрики, у пользователя продукта — свои. Как минимум, вам, как архитектору, создающему pipeline процесса разработки, следует учитывать при оценке эффективности процесса разработки метрики своей компании и метрики бизнеса. Это непрерывный процесс: разработка -> сбор метрик -> анализ результата -> внесение необходимых модификаций в процесс разработки.  Таким образом результат влияет на формирование процесса разработки и уже процесс разработки влияет на изменение архитектуры проекта. Т.е. важная мысль, которую я хочу донести — архитектура вторична, первичны результат и процесс разработки. В заключении еще раз проговорим: Без понимания этих вещей у разработчика может возникнуть желание взять и все переписать с нуля. На мой взгляд, это оправдано только когда процесс и результат разработки абсолютно не удовлетворяют заказчика этой разработки. Для новичков я советую попасть на проект с отточенным pipeline разработки. Порог входа в такие проекты высок, но перешагнув его, вы серьезно приблизитесь к пониманию того, как выстраиваются процессы разработки. Android tech lead