усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
без темы
усы2
tonsky
Меня наконец-то отпустило. Частично благодаря смене места работы (да, у них тестеры и фаза стабилизации есть!), частично благодаря этой записи. Просто я вещи лучше всего воспринимаю, когда они высказаны кем-то явно.

Когда речь заходит об отладке всегда говорят о неких технологических приемах, но редко вспоминают, что тут много завязано на психологию программиста. Самая основная проблема багфиксинга состоит в том, что чинить баги непрестижно. Чинить чужие баги - непрестижо вдвойне. Дальше - хуже. Баг в программе считается виной программиста. Такое мнение часто культивируется менеджментом. Программистов гнобят за баги. Ирония ситуации заключается в том, что баги - это естественное следствие написания кода. Программист пишет код - программист пишет баги. Программист модифицирует код - программист привносит баги. И если начать над программистом глумиться и всячески его унижать, то он быстро сообразит, что лучший способ избежать багов - писать как можно меньше кода. И еще - убеждать отдел тестирования, что тем показалось. Итого: производительность труда понижается, качество софта падает.

Следующей проблемой в борьбе с багами является Миф о Старании и Аккуратности. Удивительно живучая штука, и мне совсем непонятно откуда она взялась. Миф состоит в том, что если вы аккуратны, то багов у вас не будет. Вот так всё просто. Если у вас много багов, то это означает, что вы мало стараетесь. Это не так, баги не лечатся старанием. Поверьте, я очень аккуратный человек. Меня не раздражает монотонная работа, я могу по десять раз проверять одно и то же и это не вызывет приступ тихого бешенства. Но я не могу писать код без багов.

  • 1
Баг в общем случае -- это поведение, не соответствующее требованиям. Т.к. требования формулируются на естественном языке и с гораздо меньшей детализацией, по сравнению с кодом, который всё это реализует, то даже мега-гуру программист не обязательно поймёт требования так, как понимает аналитик и заказчик.

Поэтому баги неизбежны, и это не обязательно невнимательность (хотя и такое бывает).

По поводу непрестижности исправления багов. Я не согласен. Это не непрестижно. Это очень даже престижно и интересно. Исправление бага состоит из трёх этапов:

1) Научиться воспроизводить баг (иногда это удаётся тестерам, хотя не все баги они могут воспроизвести)
2) Найти что вызывает баг
3) Придумать, как изменить то, что вызывает баг
4) Внести изменения
5) Проверить, что вы преуспели и ничего другого не сломали (хотя бы грубая проверка)

Как-то так. Как минимум первые три пункта у меня вызывают восторг. 4-й -- это просто программирование, которое мне нравится, а пятое рутина, но её можно до определённого предела сократить unit/load/stress/integration тестами.

И ещё:

http://gaperton.livejournal.com/36790.html

Ну да, я в общем-то, хотел подчеркнуть, что баги — нормальное явление и не вина программиста. Но не подчеркнул.

А про несоответствие требованиям, большая часть багов все-таки из-за ошибок реализации, а не из-за недопонимания требований.

Ну несоответствие требованиям может принимать разные формы. Например, ты можешь использовать неверное предположение, которое было вроде как очевидно, но оказалось не верным. Может быть не рассмотрен какой-нибудь случай, который явно не описан в требованиях, но "вытекает". Либо это может быть какая-то особенность, вызванная наложением нескольких требований, которая не была рассмотрена тупо потому, что требования появились не одновременно.

В общем, может быть много разных ситуаций :)

Собственно и ошибки реализации часто появляются именно из-за невозможности держать все требования (в т.ч. те, что в тикетах issue tracker'а, а не изначальные) в голове и проверять их на совокупнуб непротиворечивость.

  • 1
?

Log in

No account? Create an account