Комментарии 4
Жиза. Я хоть и не в мобильной разработке, а больше по ИИ и автоматизации, но проблема 'синхронизации всего со всем' везде одинаковая))
Помню, как в одном своем проекте пытался руками костылить обновление данных — в итоге багов было больше, чем полезного кода.
Переход на 'Single Source of Truth', про который вы пишете — это ведь база. Мне как ленивому человеку проще один раз настроить реактивный поток, чтобы UI сам обновлялс от данных, чем потом бегать по всему коду и ловить, где я забыл прокинуть ивент.
Рефакторинг в этом плане — это не просто 'красота', а способ не сойти с ума от рутины. Автору плюс за честность про EventBus, это действительно 'грабли', через которые стоит пройти.
Спасибо за комент, рад что статья вам понравилась! Single Source of Truth - реально база, какого-то секретного знания по предметной части и самому рефакторинга в статье нет. Хотя довольно много чего пришлось переписать и в архитектуру плотно залезть.
Для меня было очень интересным опытом, инициировать и протащить такой базовый для разработки рефакторинг через бизнес процессы, для которых это черный ящик.
Могу предположить, что во многих компаниях, если прийти к бизнесу и просто сказать: я тут хочу кор фичу переписать, которая еще и много денег приносить (а как следствие возможно что-то этим сломать) будет тяжело такое провернуть.
Поэтому решил поделиться как правильно доносить свои идеи. А пример рефакторинга реально типовой
Как Вы верифицировали результат рефакторинга?
1) Собрал документацию по фиче
2) QA составил тест-кейсы по этой документации и проверили все в ручную
3) Прогнали код с рефакторингом на UI тестах, убедились что он их не сломал
4) Запустили раскатку под фича тоглом, который может переключать легаси версию и рефакторинг, сначала по городам потом на более масштабные зоны (на этом шаге уже нужно смотреть на FirebaseCrashlytics и логи в Kibana)
Пациент болен: как «продать» рефакторинг лиду и продакту