В данной статье я коснусь вопроса порога входа в проект с устоявшейся архитектурой и дам несколько вариантов ответа на очень часто возникающий вопрос: почему так сложно?
Такой вопрос частенько возникает у новичков, которые приходят на проект. Или же бывают ситуации, когда проект уходит на поддержку и развитие в новые руки, и у нового разработчика также появляется этот вопрос. И редко кто из них пытается разобраться в реальных причинах, почему здесь так, а не иначе. Это может привести к печальным последствиям для бизнеса, например, новый разработчик может настоять на том, чтобы переписать все приложение с нуля.
Чтобы минимизировать такие риски, следует вместо вопроса почему так сложно? задаться такими вопросами:
Сначала разработчик должен вникнуть в систему процесса разработки, он должен задать такой вопрос:
Часто в заказной разработке на вход приходит проект с однозначными требованиями и фиксированным набором функционала. Насколько проработанными они могут быть — это уже тема другой статьи. И процесс разработки в таких проектах чаще всего выстроен по водопадной системе, потому как предполагает непосредственную обратную связь от пользователей продукта — после разработки всего функционала продукта, тогда как при итерационной модели обратную связь можно получить уже после первой итерации. У архитектора для таких проектов обычно уже припасена устоявшаяся архитектура, которая отвечает определенным требованиям к этому процессу. Какие же требования к такому процессу разработки закладывает архитектор?
1) Pipeline процесса разработки должен быть максимально сложным для разработчика. И отбраковывание кода, поступающего в репозиторий проекта, должно по максимуму происходить автоматически и, по возможности, без участия самого архитектора.
Т.е. в процессе должен быть настроен определенный pipeline. Код, который прошел весь этот pipeline — считается удовлетворяющим требованиям. Это очень важно, т.к. хорошему архитектору необходимо избавить его разработчиков от головной боли и ответственности за не рабочую сборку после попадания кода в репозиторий. Если такого pipeline нет — ваши разработчики будут страдать от постоянного стресса. Если код попал в репозиторий и pipeline его принял, и этот код сломал сборку или повредил уже работающий функционал — это уже проблема самого pipeline.
Поэтому в таком pipeline необходимо использовать:
Все эти пункты в совокупности и приводят к появлению у разработчика вопроса: почему так сложно?
Для примера попробуйте написать тесты для вот такого кода:
class SomeService(
private val restApi: SomeApi // SomeApi - не абстракция, а конкретный класс, который умеет ходить в сеть
) {
fun doSomething(): Single<SomeResult> = restApi.loadSomething()
.map { /*какая-то бизнес логика здесь*/ }
}
Вам придется запускать такие тесты на реальном android устройстве, либо на эмуляторе. И это сразу приведет к существенной просадке во втором требовании к процессу разработки:
2) Автоматизированные элементы Pipeline'а процесса разработки должны выполняться как можно с большей скоростью
Если вашим разработчикам приходится ждать выполнения тестов очень долго — это проблема вашего pipeline и если архитектура не позволяет ускорить этот процесс — это проблема вашей архитектуры
Давайте перепишем пример:
interface SomeApi {
fun loadSomething(): Single<NetworkResult>
}
class NetworkSomeApi : SomeApi {
override fun loadSomething(): Single<NetworkResult> { /*реализация, которая ходит в сеть*/ }
}
class SomeService(
private val restApi: SomeApi // SomeApi - уже абстракция, которую легко можно замокать в тестах
) {
/*CODE*/
}
Мы видим, что сложность кода увеличилась, но с точки зрения процесса разработки — мы сделали архитектуру более гибкой, теперь нам не обязательно запускать тесты бизнес логики для блока map
в эмуляторе или на устройстве, достаточно запустить их в быстрых тестах. Это уменьшит количество интеграционных тестов, которые нужно запускать в медленном окружении.
Уменьшить количество дорогих интеграционных тестов может правильно выбранный архитектором паттерн проектирования. Не поленитесь и разберитесь с популярными на сегодня паттернами: MVP, MVVM, MVI.
Давайте еще немного затронем тему навигации в приложении. Мы тоже хотим уметь тестировать ее, и тестировать в быстрых тестах. Опять получаем "усложнение" архитектуры, потому что нам придется прятать систему навигации в приложении за абстракцией.
А еще мы хотим уметь связывать компоненты нашей системы с помощью DI, выстраивать графы зависимостей и проверять их корректность на этапе компиляции проекта, а не в рантайме. Тут на сцене появляется Dagger 2 и его монструозные компоненты и сабкомпоненты с модулями, которые уже в конец запутывают бедного новичка.
И таких неочевидных моментов "усложнения" архитектуры для новичков накапливается очень много. Естественно, без понимания процессов разработки и требований к этим процессам, у них появляется тот самый вопрос — почему так сложно?
Чтобы оценить успешность выстроенного процесса разработки и, опосредованно, архитектуру проекта, необходимо проанализировать его результат. Как правило, результатом является продукт(приложение если мы говорим про мобильную разработку). И метрики успешности продукта у всех разные: у заказчика — одни метрики, у разработчика — свои метрики, у пользователя продукта — свои.
Как минимум, вам, как архитектору, создающему pipeline процесса разработки, следует учитывать при оценке эффективности процесса разработки метрики своей компании и метрики бизнеса.
Это непрерывный процесс: разработка -> сбор метрик -> анализ результата -> внесение необходимых модификаций в процесс разработки.
Таким образом результат влияет на формирование процесса разработки и уже процесс разработки влияет на изменение архитектуры проекта. Т.е. важная мысль, которую я хочу донести — архитектура вторична, первичны результат и процесс разработки.
В заключении еще раз проговорим:
Без понимания этих вещей у разработчика может возникнуть желание взять и все переписать с нуля. На мой взгляд, это оправдано только когда процесс и результат разработки абсолютно не удовлетворяют заказчика этой разработки.
Для новичков я советую попасть на проект с отточенным pipeline разработки. Порог входа в такие проекты высок, но перешагнув его, вы серьезно приблизитесь к пониманию того, как выстраиваются процессы разработки.
К сожалению, не доступен сервер mySQL