Что хотят услышать интервьюеры:

Важно показать, что поиск багов — это не «угадывание», а системный процесс: воспроизведение проблемы, локализация причины, проверка гипотез и подтверждение исправления. В Flutter ожидают уверенное использование логов, отладчика, hot reload, DevTools и чтения stack trace. Хорошо, если есть понимание, как быстро сузить область поиска и не ломать рабочую функциональность.

Определение:

Для поиска и устранения ошибок в Flutter обычно используют набор практик и инструментов: логи через print, debugPrint и logger, отладку в IDE, Flutter DevTools, просмотр stack trace, брейкпоинты, инспектор виджетов и тесты. Смысл в том, чтобы сначала воспроизвести ошибку, затем понять, где именно нарушается логика, и после этого проверить, что исправление не создало новых проблем.

Пример использования:

Допустим, экран не обновляется после нажатия кнопки. Сначала проверяют, вызывается ли обработчик, затем смотрят, изменяется ли состояние, и после этого — перестраивается ли нужный виджет.

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});

  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int count = 0;

  void _increment() {
    debugPrint('Button pressed');
    setState(() {
      count++;
    });
    debugPrint('Count updated: $count');
  }

  @override
  Widget build(BuildContext context) {
    debugPrint('Widget rebuilt');
    return Scaffold(
      body: Center(
        child: Text('$count'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _increment,
        child: const Icon(Icons.add),
      ),
    );
  }
}

Если Button pressed и Count updated есть в логах, но интерфейс не меняется, значит проблема не в обработчике, а в том, как и где хранится состояние или как устроен rebuild.

Пояснение кода:

В этом примере код помогает локализовать ошибку по шагам:

debugPrint('Button pressed') подтверждает, что событие нажатия дошло до метода.
setState(() { count++; }) меняет состояние и должен запустить перестройку интерфейса.
debugPrint('Count updated: $count') показывает, что значение действительно изменилось.
debugPrint('Widget rebuilt') в build() помогает понять, происходит ли новый рендер после изменения состояния.

Если бы Button pressed не появлялся, проблема была бы в обработчике кнопки. Если обработчик вызывается, но build() не вызывается повторно, нужно проверять, где хранится состояние и не теряется ли оно. Если интерфейс обновляется, но показывает не то значение, ошибка уже в привязке данных к виджету.

Ключевые моменты:

Начинать нужно с воспроизведения ошибки и минимального сценария.
Логи (debugPrint, print, структурированный logger) помогают быстро понять, где ломается поток выполнения.
Stack trace и сообщения Flutter/Dart часто прямо указывают на источник проблемы.
DevTools полезен для инспекции дерева виджетов, производительности, памяти и состояния.
Брейкпоинты и пошаговая отладка в IDE удобны, когда нужно проверить конкретную ветку логики.
После исправления важно проверить крайние случаи и прогнать тесты, чтобы не внести регрессию.

Какими методами и инструментами вы применяете для поиска и устранения ошибок в коде?