Журнал LinuxFormat - перейти на главную

LXF159:От­че­ты об ошиб­ках

Материал из Linuxformat
Версия от 12:21, 26 сентября 2018; Olkol (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Содержание

От­че­ты об ошиб­ках

Об­на­ру­же­ние про­блем в ра­бо­те про­грамм – это фан­та­сти­че­ский спо­соб со­дей­ст­вия со­об­ще­ст­ву от­кры­то­го ко­да. Джо­но Бэ­кон вво­дит в те­му.

Про­бле­мы есть у всех про­грамм. Воз­мож­но, вы на­шли та­кую, ко­то­рая ка­жет­ся вам са­мой на­деж­ной из когда-ли­бо су­ще­ст­во­вав­ших, но я га­ран­ти­рую, что в ее глу­би­нах все рав­но та­ят­ся про­бле­мы. Мы на­блю­да­ем это во всех бы­то­вых уст­рой­ст­вах — на­при­мер, вам на­по­ми­на­ют о необ­хо­ди­мо­сти об­но­вить бор­то­вые про­грам­мы ва­ше­го ав­то­мо­би­ля, не го­во­ря уже о мно­же­ст­ве об­нов­лений и улуч­шений, ко­то­рые мы ви­дим в про­грам­мах для ком­пь­ю­те­ра и мо­бильника.

По­че­му во всех про­грам­мах есть про­бле­мы? По­то­му что они на­пи­са­ны людь­ми. Про­грам­ма – это слож­ный на­бор под­виж­ных со­став­ляю­щих, при­чем мно­гие из этих со­став­ляю­щих дви­жут­ся с раз­ной ско­ро­стью и у них раз­ные ожи­дания. Да­же луч­шие про­грам­ми­сты со­вер­ша­ют ошиб­ки; но, к сча­стью, вмя­ти­ну в непро­би­вае­мой броне про­грам­мист­ско­го со­вер­шен­ст­ва мож­но уст­ранить бла­го­да­ря дру­гой осо­бен­но­сти про­грамм: про­бле­мы под­да­ют­ся от­лад­ке.

На язы­ке ком­пь­ю­те­ров эти про­бле­мы име­ну­ют ошиб­ка­ми, или ба­га­ми, и отлад­ка – неотъ­ем­ле­мая часть про­цес­са раз­ра­бот­ки про­грамм. Но нам по­вез­ло жить в чу­дес­ном ми­ре от­кры­то­го ко­да, где ка­ж­дый мо­жет по­мочь оты­скать ошиб­ку и соз­дать от­чет о ней, чтобы на­ши про­грам­ми­стам сде­лали про­грам­мы, ко­то­ры­ми они де­лят­ся, еще луч­ше. В ми­ре от­кры­то­го ко­да со­об­щения об ошиб­ках яв­ля­ют­ся очень важ­ной воз­мож­но­стью по­мочь со­об­ще­ст­ву и внести свой вклад в его ра­бо­ту.

Бы­ту­ет за­блу­ж­дение, что от­прав­лять от­че­ты об ошиб­ках – это невеж­ли­во и неува­жи­тель­но, т. к. при­вле­ка­ет внимание к недостат­кам и соз­да­ет лиш­нюю ра­бо­ту для про­грам­ми­стов. Это оп­ре­де­лен­но не так! Как раз­ра­бот­чик несколь­ких про­ек­тов, за­ве­ряю вас, что поль­зо­ва­те­ли – это на­ши гла­за и уши для об­на­ру­жения оши­бок в на­ших про­грам­мах. Не имея от­че­тов об ошиб­ках, мы не бу­дем знать о про­бле­мах с ка­че­­ст­вом. Как та­ко­вой, от­чет об ошиб­ках яв­ля­ет­ся де­лом ог­ром­ной цен­но­сти, в ко­то­ром мо­жет по­уча­ст­во­вать ка­ж­дый: для это­го не тре­бу­ет­ся ни особо­го техниче­­ско­­го на­вы­ка, ни про­грам­ми­ст­ских та­лан­тов. В нашей ста­тье мы не оста­нав­ли­ваем­ся под­роб­но на ка­ком-то конкрет­ном со­об­ще­ст­ве: все ска­зан­ное здесь мож­но сме­ло отнести к лю­бой груп­пе, в ко­то­рой вы бы хо­те­ли при­нять уча­стие. Пре­ж­де чем про­дол­жить, сто­ит разъ­яснить, как соз­да­ют­ся про­грам­мы в со­об­ще­ст­ве Linux, по­сколь­ку это понимание по­мо­га­ет соз­данию от­че­тов об ошиб­ках. В ми­ре Linux есть два основ­ных ти­па со­об­ществ:

» Upstream [Пред­ле­жа­щие] – неза­ви­си­мые про­ек­ты, соз­даю­щие про­грам­мы, ко­то­рые вы знае­те и лю­би­те: Libre­Office, 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, и раз­ра­бот­чи­кам нуж­но обес­пе­чить, что­бы во всей этой под­бор­ке оши­бок бо­лее вы­со­кий при­ори­тет при­сваи­вал­ся тем, ко­то­рые по-на­стоя­ще­му важ­ны. Это не оцен­ка ка­че­­ст­ва ва­ше­го от­че­та, а по­ка­за­тель важ­но­сти са­мой про­бле­мы.

Боль­ше ин­фор­ма­ции

Когда ваш от­чет об ошиб­ке пред­став­лен, с ва­ми, ве­ро­ят­но, свя­жет­ся один из раз­ра­бот­чи­ков, что­бы об­су­дить опи­сан­ную в от­че­те ошиб­ку. Ско­рее все­го, раз­ра­бот­чик по­про­сит вас пре­доста­вить боль­ше ин­фор­ма­ции, и, воз­мож­но, по­про­сит за­пустить несколь­ко команд и со­об­щить о ре­зуль­та­тах. Сле­ду­ет все­гда от­ве­чать на эти за­про­сы о бо­лее под­роб­ной ин­фор­ма­ции, по­сколь­ку они силь­но уве­ли­чи­ва­ют шан­сы на ис­прав­ление ошиб­ки.

Раз­ра­бот­чик мо­жет по­про­сить вас за­пустить бо­лее но­вую вер­сию про­грам­мы, что­бы про­ве­рить, уст­ранена ли ошиб­ка. В раз­ных сис­те­мах это мо­жет про­ис­хо­дить по-раз­но­му и иметь раз­ные уровни слож­но­сти. Раз­ра­бот­чик upstream мо­жет по­про­сить вас за­гру­зить но­вую вер­сию про­грам­мы, ском­пи­ли­ро­вать ее и за­пустить. Или вас мо­гут по­про­сить уста­но­вить но­вый па­кет, про­тес­ти­ро­вать и за­пустить его. Вам сле­ду­ет со­об­щить о том, как вы оценивае­те удоб­ст­во ис­поль­зо­вания этих но­вых вер­сий.

Со­став­ление от­че­тов об ошиб­ках, об­рат­ная связь по этим от­че­там, и то, что вы уз­нае­те из этой об­рат­ной свя­зи, по­мо­га­ет вам вно­сить бо­лее важ­ный вклад и по­мо­гать уст­ра­нять все боль­ше оши­бок. Уда­чи! |

«Бы­ту­ет за­блу­ж­де­ние, что от­че­ты об ошиб­ках – это не­ува­жи­тель­но?.»

Персональные инструменты
купить
подписаться
Яндекс.Метрика