Знакомая картина: открываешь проект, заходишь в
MainActivity или ProfileViewController, а там... 1500 строк кода. 😱Там и работа с сетью, и валидация полей, и анимации, и сохранение в базу, и даже форматирование даты. В мире разработки это называется God Object (или Massive View Controller).
Почему это плохо?
1. Невозможно тестировать. Как написать юнит-тест на класс, который делает всё?
2. Сложно менять. Поправил верстку — сломалась база данных.
3. Конфликты при слиянии. В команде двое разработчиков полезли в этот файл — здравствуй, merge conflict на полдня.
🚀 Как лечить (Гайд для перехода в Middle):
Если видишь класс больше 300-400 строк, начинай «резню»:
1. ✂️ Всю логику сети - в Repository.
Во View/Activity не должно быть
http-клиентов и JSON-парсинга. Она должна просто сказать: repository.getUsers() и показать спиннер.2. ✂️ Всю бизнес-логику - в UseCases (Интеракторы).
Валидация пароля, подсчет корзины, фильтрация списков - это чистая логика. Выносите её в отдельные классы (
PasswordValidator, CartCalculator).3. ✂️ Сложный UI - в Custom Views / Child ViewControllers.
Если у вас в адаптере списка 500 строк кода настройки ячеек - вынесите ячейку в отдельный класс с методом
bind(data).💡 Правило одной ответственности (SRP):
Класс должен иметь только одну причину для изменения.
🔵Если дизайнер поменял цвет кнопок - меняем только View.
🔵Если бэкенд поменял формат JSON, меняем только DTO/Repository.
🔵Если эти изменения заставляют вас править один и тот же файл, у вас архитектурная проблема.
🏁 Задание на неделю:
Найдите самый «жирный» класс в своем проекте и попытайтесь вынести из него хотя бы одну функцию в отдельный вспомогательный класс. Ваш код скажет вам спасибо.
Сколько строк в самом большом файле вашего текущего проекта? Пишите честно 👇
#architecture #cleanCode #refactoring #middle #android #ios
👉 @developer_mobila