Процесс отладки: отслеживание, командное общение и баланс между модульными и интеграционными тестами
19 сентября 2023 г.Отладка — неотъемлемая часть разработки программного обеспечения. Однако по мере увеличения размера и сложности проектов процесс отладки требует большей структуры и сотрудничества. Вероятно, вы уже занимаетесь этим процессом, поскольку этот процесс глубоко укоренился в большинстве команд.
https://www.youtube.com/watch?v=JaYaDOHtbyA&embedable=true
Это также основная часть академической теории отладки. Его цель — предотвратить регресс и улучшить сотрудничество в командной среде. Без этого процесса любая проблема, которую мы решаем, может преследовать нас в будущем. Этот процесс помогает разработчикам работать слаженно и эффективно.
Важность отслеживания проблем
Я уверен, что мы все пользуемся системой отслеживания проблем. В этом смысле мы все должны быть едины. Но бываете ли вы иногда «просто исправить ошибку»?
Не просматривая систему отслеживания проблем?
Честно говоря, я часто так делаю. В основном в хобби-проектах, но иногда и в профессиональных целях. Даже при работе в одиночку это может стать проблемой...
Как избежать параллельной работы над одной и той же ошибкой
При работе над более крупными проектами крайне важно избегать ситуаций, когда несколько разработчиков неосознанно решают одну и ту же проблему. Это может привести к напрасным усилиям и потенциальным конфликтам в кодовой базе. Чтобы предотвратить это:
* Всегда регистрируйте ошибки в своей системе отслеживания проблем. До начав работу над ошибкой, убедитесь, что она назначена вам и помечена как активная. Такая прозрачность позволяет менеджеру проекта и другим членам команды быть в курсе происходящего, уменьшая вероятность дублирования работы. * Будьте в курсе других проблем. Следя за проблемами, которые решают ваши товарищи по команде, вы сможете предвидеть потенциальные области конфликтов и соответствующим образом корректировать свой подход.
Предполагая, что у вас ежедневный или даже еженедельный сеанс синхронизации, важно обсуждать проблемы. Это предотвращает конфликты, когда товарищ по команде может услышать описание ошибки и может поднять флаг. В некоторых ситуациях это также помогает определить основную причину ошибки. Проблема может быть знакома, и общение по ней оставляет «бумажный след».
По мере роста проекта вы обнаружите, что ошибки продолжают возвращаться, несмотря на все наши усилия. История, оставленная в системе отслеживания проблем товарищами по команде, которые больше не входят в команду, может спасти вам жизнь. Кроме того, статистика, которую мы можем получить с помощью правильно классифицированного средства отслеживания проблем, может помочь нам определить проблемные области кода, которые могут нуждаться в дальнейшем тестировании и, возможно, рефакторинге.
Ценность проблемы перед запросами на включение
Иногда мы записываем комментарии и информацию непосредственно в запрос на включение, а не в систему отслеживания проблем. Это может работать в некоторых ситуациях, но не идеально в общем случае.
Проблемы в системе отслеживания часто более доступны, чем запросы на включение или конкретные фиксации. При решении проблемы регрессии жизненно важно связать запрос на включение с исходной проблемой. Это гарантирует, что все обсуждения и решения, связанные с ошибкой, централизованы и легко отслеживаются.
Коммуникация: отслеживание проблем и временные каналы
Я часто использую Slack. Это проблема; это удобно, но эфемерно, и не в одном случае важная информация, написанная в чате Slack, пропала. Электронная почта не приносит большого улучшения, особенно в долгосрочной перспективе. Переписка по электронной почте, которая у меня была с бывшим коллегой, была прервана, и я не знал, чем она закончилась.
Да, вести беседу в системе отслеживания проблем неудобно и неудобно, но у нас есть запись.
Почему мы иногда избегаем системы отслеживания проблем
Иногда разработчики могут избегать обсуждения проблем в трекере, потому что:
* Сложные обсуждения. Некоторые темы могут показаться слишком широкими или сложными для системы отслеживания проблем. * Страх публичной критики: Никто не хочет выглядеть невежественным или критиковать коллегу в постоянной записи. В результате некоторые обсуждения могут перейти в частные или временные каналы.
Однако, хотя сплоченность команды и взаимопонимание имеют решающее значение, важно регистрировать все соответствующие обсуждения в системе отслеживания проблем. Это гарантирует, что знания не будут потеряны, особенно если член команды уйдет.
Роль ежедневных встреч
Ежедневные встречи имеют неоценимое значение для команд, в которых несколько разработчиков работают над схожими задачами. Эти встречи предоставляют платформу для:
* Обмен обновлениями. Сообщите команде о своих текущих теориях и направлении. * Участие в обсуждениях. Если новость коллеги кажется вам знакомой, это возможность сотрудничать и избежать лишней работы.
Однако важно, чтобы эти встречи были краткими. Подробные обсуждения должны перейти в систему отслеживания проблем для всесторонней записи. Я предпочитаю проводить две встречи в неделю, поскольку считаю, что это оптимальное количество. Первый день недели обычно является днем наращивания производительности. Затем у нас есть первая встреча утром второго дня недели и вторая встреча через два дня. Это снижает нагрузку на ежедневные встречи, сохраняя при этом актуальность информации.
Роль тестирования в отладке
Мы все используем тесты при разработке (надеюсь), но в теории отладки тестам отведено особое место.
Начинаем с модульных тестов
Обычный подход к отладке — начать с создания модульного теста, воспроизводящего проблему. Однако это не всегда может быть осуществимо до понимания проблемы. Тем не менее, как только проблема будет понята, нам следует:
* Прежде чем устранять проблему, создайте тест. Этот тест должен быть частью запроса на включение, устраняющего ошибку. * Поддерживайте коэффициент покрытия. Стремитесь к тому, чтобы коэффициент покрытия составлял 60 % или выше на каждый запрос на включение, чтобы гарантировать адекватное тестирование изменений.
Тест служит защитой от регресса. Если ошибка появится снова, это будет немного другой вариант той же самой ошибки.
Юнит-тесты и интеграционные тесты
Хотя модульные тесты выполняются быстро и обеспечивают немедленную обратную связь, они в первую очередь предотвращают регрессии. Они могут оказаться не столь эффективными для проверки общего качества. С другой стороны, интеграционные тесты, хотя и потенциально более медленные, предлагают всестороннюю проверку качества. Иногда они могут быть единственным способом воспроизвести определенные проблемы. Большинство сложных ошибок, с которыми я столкнулся за свою карьеру, были связаны с областью взаимодействия между модулями. Это область, которую модульные тесты охватывают не очень хорошо. Вот почему интеграционные тесты гораздо важнее модульных тестов для общего качества приложения.
Чтобы обеспечить качество, сосредоточьтесь на покрытии интеграционными тестами. Полагаться исключительно на покрытие модульными тестами может ввести в заблуждение. Это может привести к неработающему коду и увеличению сложности системы. Однако в процессе отладки очень полезно иметь модульный тест, поскольку его гораздо проще и быстрее отлаживать.
Заключительное слово
структурированный подход к отладке , в сочетании с эффективной коммуникацией и надежной стратегией тестирования, может значительно повысить эффективность и качество разработки программного обеспечения. Речь идет не об удобстве; процесс, лежащий в основе отладки, похож на бумажный протокол процесса отладки.
Я начинаю каждый сеанс отладки с поиска в системе отслеживания проблем. Во многих случаях это дает золото, которое, возможно, не приведет меня напрямую к проблеме, но все же указывает мне правильное направление.
Возможность полагаться на модульный тест, зафиксированный при устранении аналогичной ошибки, неоценима. Это дает мне возможность решать подобные проблемы в дальнейшем.
Также опубликовано здесь.
Оригинал