LXF159:Отчеты об ошибках
|
|
|
Содержание |
Отчеты об ошибках
Обнаружение проблем в работе программ – это фантастический способ содействия сообществу открытого кода. Джоно Бэкон вводит в тему.
Проблемы есть у всех программ. Возможно, вы нашли такую, которая кажется вам самой надежной из когда-либо существовавших, но я гарантирую, что в ее глубинах все равно таятся проблемы. Мы наблюдаем это во всех бытовых устройствах — например, вам напоминают о необходимости обновить бортовые программы вашего автомобиля, не говоря уже о множестве обновлений и улучшений, которые мы видим в программах для компьютера и мобильника.
Почему во всех программах есть проблемы? Потому что они написаны людьми. Программа – это сложный набор подвижных составляющих, причем многие из этих составляющих движутся с разной скоростью и у них разные ожидания. Даже лучшие программисты совершают ошибки; но, к счастью, вмятину в непробиваемой броне программистского совершенства можно устранить благодаря другой особенности программ: проблемы поддаются отладке.
На языке компьютеров эти проблемы именуют ошибками, или багами, и отладка – неотъемлемая часть процесса разработки программ. Но нам повезло жить в чудесном мире открытого кода, где каждый может помочь отыскать ошибку и создать отчет о ней, чтобы наши программистам сделали программы, которыми они делятся, еще лучше. В мире открытого кода сообщения об ошибках являются очень важной возможностью помочь сообществу и внести свой вклад в его работу.
Бытует заблуждение, что отправлять отчеты об ошибках – это невежливо и неуважительно, т. к. привлекает внимание к недостаткам и создает лишнюю работу для программистов. Это определенно не так! Как разработчик нескольких проектов, заверяю вас, что пользователи – это наши глаза и уши для обнаружения ошибок в наших программах. Не имея отчетов об ошибках, мы не будем знать о проблемах с качеством. Как таковой, отчет об ошибках является делом огромной ценности, в котором может поучаствовать каждый: для этого не требуется ни особого технического навыка, ни программистских талантов. В нашей статье мы не останавливаемся подробно на каком-то конкретном сообществе: все сказанное здесь можно смело отнести к любой группе, в которой вы бы хотели принять участие. Прежде чем продолжить, стоит разъяснить, как создаются программы в сообществе Linux, поскольку это понимание помогает созданию отчетов об ошибках. В мире Linux есть два основных типа сообществ:
» Upstream [Предлежащие] – независимые проекты, создающие программы, которые вы знаете и любите: LibreOffice, OpenShot, GIMP и т. д.
» Downstream [Нижеследующие] – это дистрибутивы Linux, которые превращают в пакеты и поставляют программы upstream в интегрированной системе. Среди примеров – Ubuntu, Fedora и Debian.
Программа проходит примерно такой путь от компьютера программиста до вашего дистрибутива Linux:
» Программисты upstream создают функции в своей кодовой базе upstream (например, в OpenShot).
» Программисты upstream объединяют все свои функции в центральной кодовой базе. Пользователи, которых интересует эта подготовительная работа, тестируют функции по мере их появления в базе и сообщают о наличии в них ошибок. Затем программисты исправляют ошибки там, где считают уместным.
» Когда код upstream готов к релизу, снимок этого кода выпускается с номером релиза (например, OpenShot 1.0).
» С выходом нового релиза разработчики дистрибутивов создают пакеты и выпускают их в версии разработки своего дистрибутива (например, Ubuntu, Fedora). Пользователи, которым интересен этот дистрибутив, тестируют релиз и сообщают о наличии ошибок программе отслеживания ошибок дистрибутива. Разработчики дистрибутива решают эти проблемы на свое усмотрение и исправляют ошибки в дистрибутиве (часто извещая об этих ошибках тылы, upstream).
» Когда дистрибутив готов, он выходит под определенным номером релиза (например, Ubuntu 12.04). И здесь у нас имеется два типа ошибок:
> Ошибки, возникшие в проекте upstream.
> Ошибки, появляющиеся в процессе создания пакетов и интеграции программы в дистрибутив downstream.
В идеальном мире об ошибках, обнаруженных в дистрибутиве, сообщают его пользователи, и если подтверждается, что ошибки не по вине разработчиков дистрибутива, это доводится до сведения сообщества upstream. Более подробную информацию о том, как соединить эти разнообразные ошибки, см. во врезке Связь ошибок.
Наша цель – в том, чтобы разработчики upstream знали об ошибках, источником которых являются программы upstream, а разработчики дистрибутивов знали об ошибках, возникших в результате создания пакетов и интеграции этих программ.
Анатомия ошибки
Прежде чем сообщать об ошибке, мы должны знать, что такое ошибка, как она выглядит. Вкратце, ошибка – это непредвиденное или неточное поведение программы. Примеры могут включать такие:
» Вы щелкаете по кнопке в программе, а программа «падает» (этого не должно быть никогда).
» Вы складываете в калькуляторе два числа и получаете не тот результат (калькулятор должен выводить верные результаты).
» Перевод неправилен и выдает культурно некорректный термин (для перевода должны использоваться корректные определения).
Все приведенные примеры предполагают, что вам известно, каким должно быть правильное поведение, а значит, вы можете увидеть, когда это поведение становится неправильным. Иногда это более заметно, иногда менее.
Всегда стоит помнить, что ошибки относятся только к непредвиденным или неточным результатам, а вовсе не к дизайну или способу поведения, которые вас не устраивают. Например, если разработчики решили сменить цвет значка приложения на жуткий кислотно-зеленый, вас, возможно, это взбесит, но это не ошибка. Не засоряйте списки обнаруженных ошибок заявлениями о вашем неприятии принятого решения... для этого есть другие каналы связи.
Все ошибки имеют два важных атрибута:
» Симптомы Например, если вы нажали на кнопку, а приложение отказало, симптомы вполне очевидны: нажатие на кнопку вызывает сбой. Симптомы других ошибок могут быть не столь явными – например, постепенное разбалтывание приложения или проблемы со стабильностью.
» Причина Если вы нажали на кнопку, а в работе приложения произошел сбой, возникает вопрос, на какую кнопку вы нажали, и не пыталась ли она загрузить функцию, где содержалась ошибка, приведшая к сбою?
Большинство обнаруживших ошибку сначала видят симптомы, а затем начинают докапываться до причин.
Сбор улик
Обнаружив в программе ошибку, мы должны быть в состоянии предоставить разработчику максимум информации о ней, чтобы тот смог ее устранить.
Лучшим свидетельством, которое мы можем представить, называется воспроизведение ошибки. Здесь мы описываем набор действий, которые надо совершить разработчику, чтобы повторить ошибку в своей системе. Если ему это удастся, шанс исправить ее значительно увеличивается, поскольку разработчик сам увидит проблему и сможет в ней разобраться.
Некоторые ошибки воспроизвести легко: нужно только припомнить свои действия, приведшие к появлению ошибки. Если вы совершите те же действия и ошибка возникнет снова, перечислите разработчику эти действия. Проделайте их еще несколько раз, чтобы убедиться в надежности вашей информации. К сожалению, бывает, что действия, вызвавшие ошибку, трудновоспроизводимы. Для некоторых ошибок появление проблемы не ограничивается простым нажатием на определенные кнопки в определенной последовательности – к ошибке может привести нарушение хрупкого баланса данных, сетевых соединений и состояния. Если ваш компьютер периодически отказывается работать, выяснение причин отказа может быть непростой задачей.
В случаях, когда мы не знаем или не можем воспроизвести действия, приведшие к ошибке, наилучшим решением будет предоставить данные о том, когда произошла ошибка, чтобы разработчики могли ее идентифицировать. Скажем, если вы видите, что в приложении поврежден экран, или что видео, воспроизводимое приложением, пикселит, предоставьте визуальные свидетельства, способные оказаться полезными, например:
» Скриншоты Если имеется проблема с видео, сделайте экранный снимок-скриншот и предоставьте его в качестве примера имеющейся проблемы. Для изготовления скриншота можно использовать и другие приложения, например, GIMP.
» Скринкасты Если обнаруженную ошибку трудно описать, или вы хотите продемонстрировать ее с большими подробностями, воспользуйтесь инструментом для скринкастинга (например, RecordMyDesktop) для фиксации ошибки в динамике.
» Файлы журналов Многие приложения хранят информацию о своих действиях в лог-файлах. Эта информация может пригодиться разработчику, но знание о том, какие лог-файлы доступны, требует понимания проблемного приложения. В некоторых системах (например, в Ubuntu), лог-файлы обнаруживаются автоматически при сообщении об ошибке.
» Исходные материалы Если вы обнаружили, что определенные исходные материалы (скажем, видео, которое вы решили воспроизвести в видеоплейере) страдают от ошибок, было бы полезно дать на них ссылки (это можно сделать через сервис распределенного доступа к файлам, типа Dropbox или Ubuntu One). Конечно, у вас должны быть права на раздачу этой информации другим.
Еще одна полезная методика – включить режим отладки приложения [debugging mode]. Во многих приложениях имеется параметр, который вы можете включить, чтобы вас завалило лавиной информации, обычно остающейся за кулисами.
Не так давно я обнаружил ошибку в плейере Rhythmbox, которая приводила к отказу от работы. Чтобы было проще обнаружить проблему, я запустил его из терминала командной строки и использовал ключ -d, включив информацию по устранению ошибок. Для этого я ввел в терминале
rhythmbox -d
Программа запустилась, и я стал работать с ней в нормальном режиме. В терминале отобразилась масса отладочной информации, и через несколько часов после отказа программы я заметил, что часть этой информации относится к функции crossfading в Rhythmbox.
Я вырезал и вставил отладочную информацию в текстовый файл и сохранил его, а затем отключил функцию crossfading и стал использовать Rhythmbox в обычном режиме.
Дня через три бесперебойной работы я пришел к выводу, что проблема, очевидно, заключена в функции crossfading (поскольку ее отключение привело к намного более стабильной работе). Затем я сообщил об ошибке, описав свои действия и представив отладочную информацию, которую сохранил.
Процесс сбора этой информации является одним из самых ценных и полезных вкладов, поскольку вы помогаете не только выявить симптомы проблемы, но и обнаружить ее причину.
Начало обсуждения
Теперь у вас должна сформироваться подборка свидетельств, включающая список симптомов, скриншоты, скринкасты, лог-файлы, исходные материалы и многое другое. Следующий шаг – обсудить все это с разработчиками, чтобы они смогли это все просмотреть и решить проблему.
Часто говорится, что в сообществе Linux принято сообщать об ошибках, но описание процесса выглядит так, как будто все работает по принципу сообщил-и-забыл, где вы просто пишете об ошибке, а разработчики мчатся исправлять ее. В реальности сообщение об ошибке – это сигнал к началу обсуждения. Собирая материалы об ошибке, вы делаете первый шаг в этом обсуждении. Как правило, это несколько напоминает следующее:
1 Вы сообщаете об ошибке.
2 Разработчик отвечает вам, попросив предоставить более подробную информацию.
3 Вы присылаете подробности.
4 Шаги 2 и 3 могут повторяться, поскольку для выяснения источника ошибки нужна очень подробная информация.
5 Разработчик исправляет ошибку.
Концентрация на должном выполнении шага 1 очень важна, но важно также пройти весь процесс обсуждения и переписки, чтобы помочь разработчику обнаружить причину проблемы. Поскольку по природе своей этот процесс является обсуждением, у нас есть специальное место проведения подобных обсуждений: программа обнаружения ошибок. Именно в ней мы размещаем сообщения об ошибках и ведем последующие обсуждения, взаимодействуя с разработчиком.
Вы можете считать программу отслеживания ошибок своего рода дискуссионным форумом, снабженным разными шкалами и переключателями для отслеживания текущего статуса ошибки; ее приоритетности; того, была ли она исправлена; и кто над ней работает.
Огромное количество программ отслеживания ошибок являются сетевыми, и в них имеются шкалы состояния и переключатели в верхней части отчета об ошибке, а обсуждение проблемы располагается внизу. Почти во всех проектах открытого кода программы отслеживания ошибок открыты для просмотра сообществом и внесения предложений.
Примерами программ отслеживания ошибок являются Bugzilla, Launchpad, Trac и др. Все эти разные системы отслеживания ошибок представляет одну и ту же формулу для работы программы, но при этом отличаются друг от друга прочими функциями и способностями.
У разных сообществ открытого кода разные подходы к отслеживанию ошибок. Некоторые сообщества настраивают собственную программу отслеживания ошибок (часто на основе Bugzilla), тогда как другие используют существующий хостинг сервис разработки (например, Launchpad).
Единого набора шаблонов работы сообщества не существует, но, к счастью, освоившись с одной программой отслеживания ошибок, вы легко управитесь и с другими.
В проекте, над которым я сейчас работаю, я использую для отчетов об ошибках Launchpad, и вы можете увидеть список ошибок на https://bugs.launchpad.net/ubuntu-accomplishments-system.
Отдельно о программах отслеживания ошибок я говорить не буду: вместо этого я хочу обсудить общую практику предоставления полезных сообщений об ошибках. Вся эта информация по идее должна быть применима к любой программе отслеживания ошибок, используемой интересующим вас сообществом. Как я уже упоминал, программа отслеживания ошибок включает информацию о статусе самой ошибки (а также и ветку обсуждения). Так что давайте теперь рассмотрим наиболее обычные поля состояния. Когда вы составляете сообщение об ошибке, вас просят предоставить несколько важных подробностей:
» Компонент Обычно это приложение, содержащее ошибку, о которой вы сообщаете (например, Rhythmbox).
» Аннотация Это краткое – одной строкой – описание проблемы. Можете сравнить его со строкой Тема в сообщении электронной почты: оно должно описывать проблему в сжатой манере. Пусть оно будет предельно ясным, и не пытайтесь напирать здесь на важность проблемы (например, не стоит писать «Срочно исправьте ужасную ошибку в Rhythmbox!» – вместо этого напишите примерно так: «Периодические сбои из-за функции cross-fading»).
» Описание Более подробное определение проблемы, подобное телу письма в электронной почте. Здесь вы должны описать подробности ошибки и ее симптомов и поделиться своими соображениями по поводу того, как можно воспроизвести эту проблему. Главное здесь – быть точным, подробным и не отклоняться от темы.
Многие программы отслеживания ошибок заинтересованы только в этой информации, но есть и другие поля состояния, о которых я ранее упоминал – через них разработчики и другие члены сообщества получают более подробную информацию об ошибке. Среди них:
» Приоритет Важно ли исправить эту ошибку. Обычно здесь имеется несколько опций (например, Critical [Критичный], High [Высокий], Medium [Средний], Low [Низкий]), и разработчик выберет степень сложности ошибки и присвоит ей определенный приоритет. Ошибка, приводящая к потере данных и жестким сбоям, вероятнее всего, будет отнесена к Критичным, а той, которая приводит к возникновению некоторых неудобств в работе, присвоят Низкий приоритет.
» Статус Текущий статус ошибки в ее жизненном цикле. Среди обычных полей здесь New [Новая] (ошибка, которой пока не уделялось внимания), Confirmed [Подтвержденная] (разработчик подтвердил наличие ошибки), Incomplete [Незавершенная] (разработчик попросил прислать более подробную информацию, ранее не предоставленную), In Progress [В работе], Fix Committed [Внесены отладки] (отладка внесена в базу кода), Fix Released [Исправление вышло], и Invalid [Недействительная] (разработчик не счел проблему ошибкой).
» Assigned To Если разработчик взялся решить проблему, он может вписать себя в это поле, давая другим знать, что над решением ошибки ведется работа.
Некоторые заявители об ошибке чересчур чувствительны к присвоению ей определенного Приоритета и Статуса, и обижаются, если «их» ошибке присваивают статус Invalid (поскольку разработчики ее ошибкой не считают). Другой пример – когда человек, сообщивший об ошибке, полагает, что она имеет исключительную значимость, а Приоритет ей присваивается ниже, чем он ожидал.
Во всех подобных случаях помните, что разработчикам все же виднее. Приоритет – вещь относительная.
При наличии 100 отчетов об ошибках сложно ожидать, что им всем будет присвоен приоритет Critical и High, и разработчикам нужно обеспечить, чтобы во всей этой подборке ошибок более высокий приоритет присваивался тем, которые по-настоящему важны. Это не оценка качества вашего отчета, а показатель важности самой проблемы.
Больше информации
- Метамодернизм в позднем творчестве В.Г. Сорокина
- ЛитРПГ - последняя отрыжка постмодерна
- "Ричард III и семиотика"
- 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
- Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
- Литература
- Метамодерн
- Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
- Как избавиться от комаров? Лучшие типы ловушек.
- Что делать если роблокс вылетает на windows
- Что делать, если ребенок смотрит порно?
- Почему собака прыгает на людей при встрече?
- Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
- О чем может рассказать хвост вашей кошки?
- Верветки
- Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
- Срок исковой давности как правильно рассчитать
- Дмитрий Патрушев минсельхоз будет ли преемником Путина
- Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
- Как правильно выбрать машинное масло в Димитровграде?
- Как стать богатым и знаменитым в России?
- Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
- Как стать мудрецом?
- Как правильно установить FreeBSD
- Как стать таким как Путин?
- Где лучше жить - в Димитровграде или в Ульяновске?
- Почему город Димитровград так называется?
- Что такое метамодерн?
- ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
- Тарифы на электроэнергию для майнеров предложено повысить
Когда ваш отчет об ошибке представлен, с вами, вероятно, свяжется один из разработчиков, чтобы обсудить описанную в отчете ошибку. Скорее всего, разработчик попросит вас предоставить больше информации, и, возможно, попросит запустить несколько команд и сообщить о результатах. Следует всегда отвечать на эти запросы о более подробной информации, поскольку они сильно увеличивают шансы на исправление ошибки.
Разработчик может попросить вас запустить более новую версию программы, чтобы проверить, устранена ли ошибка. В разных системах это может происходить по-разному и иметь разные уровни сложности. Разработчик upstream может попросить вас загрузить новую версию программы, скомпилировать ее и запустить. Или вас могут попросить установить новый пакет, протестировать и запустить его. Вам следует сообщить о том, как вы оцениваете удобство использования этих новых версий.
Составление отчетов об ошибках, обратная связь по этим отчетам, и то, что вы узнаете из этой обратной связи, помогает вам вносить более важный вклад и помогать устранять все больше ошибок. Удачи! |
«Бытует заблуждение, что отчеты об ошибках – это неуважительно?.»