Не соглашусь, в рамках дебага мы не тыкаем по разным местам кода. Мы проходим флоу исполнения нашей программы и при этом можем видеть доп информацию : переменные окружения, трейс вызовов. Также у нас есть возможность проверить к чему приведет исполнение того или иного кода в рантайме через "evaluate expression". Так что я бы не назвал качественный дебаг - "тыканием в разные места кода".
спасибо вам за фидбэк)
По ощущениям sdui помогает ускорить разработку фичи или все таки его основной плюс в возможности релиза фичи без обновления приложения ?
В aosp забавных тудух очень много)
хорошая догадка
Классика)
Действительно всегда есть вероятность столкнуться с чем-то подобным))
Спасибо за фидбэк !)
Интересные мысли))
Но лучше все таки оставлять поменьше странных кусков кода :)
Очень знакомо))
Понимаю вас)
Примерчики подбирались из всего опыта overall)
Согласен с вами, системный подход при нахождении причины проблемы максимально важен
Интересная техника, спасибо, что подсветили !)
Не соглашусь, в рамках дебага мы не тыкаем по разным местам кода. Мы проходим флоу исполнения нашей программы и при этом можем видеть доп информацию : переменные окружения, трейс вызовов. Также у нас есть возможность проверить к чему приведет исполнение того или иного кода в рантайме через "evaluate expression". Так что я бы не назвал качественный дебаг - "тыканием в разные места кода".
Полностью с вами согласен, навык убирать все лишнее также максимально важен)
Спасибо за корректировку, там дейсвительно имелся в виду Layout Inspector
спасибо вам за фидбэк !)
буду улучшаться
Такой подход тоже вполне валиден)
Главное, чтобы в этих логах не проскакивали sensitive данные на релизных сборках)
Согласен, корректное описание в логах - это очень важная история)
Валидная идея)