Писать ли сразу чистый код с правильной архитектурой?

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

С моей же точки зрения, сложность архитектуры зависит от бизнес-задач. Если вы пишете простенький пет-проект, вам ни к чему нагружать его сложной архитектурой с идеальным разделением по слоям: репозиториями, юзкейсами, интеракторами, гейтвеями. А вот если у вас большое многомодульное приложение - не надо пытаться усидеть на одной Entity для всех модулей, запихивая в неё кучу нуллабельных полей.

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

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

И так далее. Хорошая архитектура должна решать ваши проблемы, а не создавать их. Появление бессмысленного проксирования и бойлерплейта - знак того, что надо задуматься над упрощением архитектуры. А вот появление дублирования/копирования/неудобства - сигнал к пересмотру архитектуры в пользу более сложной/более подходящей к вашей задаче.

#android #архитектура #лайфхаки